User Authentication

Discussions about creating CAPI applications to run on Android devices
Forum rules
New release: CSPro 8.0
Post Reply
sergiofurtado
Posts: 29
Joined: October 5th, 2019, 1:43 pm

User Authentication

Post by sergiofurtado »

Hello,

I would like to consult with you if a CAPI application can create a user list (with login and password) on the server and when synchronization is performed download this list on the mobile device so that only a specific user has access (with login and password) to the application to enter the collected information, that is, would be a way to authenticate the user to have access to the application.

Thanks for any help / ideas!
htuser
Posts: 631
Joined: December 19th, 2011, 6:26 pm
Location: Silver Spring Area, MD, USA

Re: User Authentication

Post by htuser »

Dear Sergio,
Yes. I'm using authentification since years.
1.- You need an array (in CSPro Logic) with username and password. This can be stored in external dictionary also, but right now, CSDB file isn't secure
so, it's preferred to have it in an array defined in logic.
2.- If you're using CSWeb, you must upload this array, from any csv file to register username and password;
3.- You must use prompt function with password as parameter to ask users to authenticate. And finally, a loop through array in CSPro logic will validate password for specific user.

Note that this way is used for authentification for both, CSWeb and the application with the same password.
Note that also, password stored in plain text in CSPro logic isn't secure and can be read by others. So, i also recommend you to write an encryption/decryption function for your password.

About theses functions, Gregory Martin shared one with me years ago, but you can search through the Web for one you think is more adapted, advanced.
Usually C examples can be ported more easily in CSPro Logic. For example you can ask the Developer Team if they can help us to port this: http://www.trytoprogram.com/c-examples/ ... pt-string/ to CSPro Logic.

Please let me know if i'm clear with explanations.
Regards,
G.VOLNY, a CSProuser from Haiti, since 2004
sergiofurtado
Posts: 29
Joined: October 5th, 2019, 1:43 pm

Re: User Authentication

Post by sergiofurtado »

Dear Htuser,

The information was quite enlightening.

I will implement the instructions given and finding some difficulty in the encryption process, I will contact the group again.

Thank you!
josh
Posts: 2399
Joined: May 5th, 2014, 12:49 pm
Location: Washington DC

Re: User Authentication

Post by josh »

Just to add to what @htuser said. It really depends on how secure you want your login to be.

For many surveys, the password is there mostly just to prevent an interviewer from working on cases assigned to another interviewer. In such cases it is fine to store the passwords as plain text in a lookup file. You would create an Excel spreadsheet with columns for the user name and password and use CSPro2Excel to convert it to a data file. You can then use the data file as a lookup file in your application. When the user enters their username and password you use loadcase() to load the password for the user name that was entered and compare it to the password that was entered. You can see an example of this in the CAPI Census example in the CSPro examples directory. In that example the staff dictionary has a PIN code that works like a password. That example doesn't download the staff file from the server but you could do that easily using the syncdata() function.

Of course, storing the password as plain text is not very secure. A very determined interviewer can copy the lookup file from the device to a PC that has CSPro on it and open the file in DataViewer and see the passwords. As @htuser says, it would be better to store an encrypted version of the password instead of the plain text password. This is usually done with a password hashing function. That is a function that takes the plain text password and generates an encrypted version known as a password hash. You then store the hash in the lookup file instead of the plain text. When checking the password instead of comparing the password entered to the password in the lookup file you run the password that they enter through the same hash function and compare the result with the hash in the lookup file. The challenge here is writing a secure hash function. The recommended ones like bcrypt are going to be pretty tricky to write in CSPro. However, the CSPro diagnostics() function supports getting the MD5 of a file so you could write the password out to a text file using filewrite, use diagnostics("MD5", pathToFile) to get the MD5 and then delete the file using filedelete. MD5 is not the most secure hash function but only a determined hacker will be able to crack it. To make it more secure you can add "salt" to it before you hash it (A Google search can tell you more about salting passwords). This takes a decent amount of CSPro logic to pull off.

Using hashing makes it pretty hard for anyone to get the passwords that are stored on the tablet. Of course that just protects your password file. The actual data entered from your survey is still just stored in a file that someone can copy from the tablet and view. So it isn't worth spending a lot of effort protecting your passwords if your data is not protected. The best way to protect both the password file and the data file is use set up a password, pin code or fingerprint in the Android settings. When you do this Android encrypts all the files on the tablet using hardware encryption which is must stronger than anything that you can do in CSPro.

If your interviewers will have access to the internet whenever they log in you have another option. Instead of storing the passwords on the phone/tablet you could use the CSWeb username/password to control access to your application. Whenever the interviewer logs in you would call syncconnect() with the username and password. If the function succeeds then they entered the password correctly, otherwise they did not. This avoids having a password file on the tablet so you don't have to worry about protecting the passwords but of course you need internet access.

Another option is instead of storing the passwords in a lookup file you could store them using the savesetting() function and retreive() them using loadsetting(). You would still use a lookup file to get the passwords from the server the first time you start the application. Then you would loop through the password file that you downloaded and call savesetting() on each one to store it in the settings. Once you did that you could then delete the password file that you downloaded. The settings() are stored are in a secure area of the tablet so it would be pretty hard for anyone to get to them (if someone is able to root the Android device and they know where to look they could probably read them but that is no easy task).

One consideration is who are you trying to protect you passwords and data from. If you are worried about some random person picking up a tablet and getting to the data then the best solution is to use the device encryption in the Android settings and not worry about protecting the password file since that random person won't know the password/pin code for the device. However, some people (@htuser included) want to protect the data from the interviewers themselves. In that case the Android level encryption won't help so you need to consider how clever your interviewers to decide if you need to password hashing, settings, an array in the pen file or take some other approach to prevent interviewers from getting to the passwords.

We are planning to create a password protected version of the csdb file in a future release which will eventually simplify all of this.
htuser
Posts: 631
Joined: December 19th, 2011, 6:26 pm
Location: Silver Spring Area, MD, USA

Re: User Authentication

Post by htuser »

Hi Josh,
Thank you for given us this very exhaustive course about the topic. Usually i store password in an array in logic, but right now, i will use lookup file(external dictionary) and download only the one regarding specific user, the first time they are using applications and store it in the devices (tablet or other computer).

(A parenthesis, when you introduced CSDB format, one of your goal was to reduce the number of files, it's why i'm asking myself why we can't have a CSDB supporting also main data and external dictionaries data...I'm more at ease with managing less data file).

Right now, without strong password protection (encryption) with best available methods, whatever non skilled person can connect to CSWeb and steal a whole survey/census database in minutes and disseminate it...
The best way to protect both the password file and the data file is use set up a password, pin code or fingerprint in the Android settings. When you do this Android encrypts all the files on the tablet using hardware encryption which is must stronger than anything that you can do in CSPro.
Right now, this can't protect any data file or password file since an enumerators having the pin code/password etc can copy or transfer over internet whatever file and open them on another computer. So, i never seeing the importance of this way.
The settings() are stored are in a secure area of the tablet so it would be pretty hard for anyone to get to them (if someone is able to root the Android device and they know where to look they could probably read them but that is no easy task).
It was very easy for me to see theses settings and modify them in the past. I don't know if you changed the way you stored them in recent versions.
We are planning to create a password protected version of the csdb file in a future release which will eventually simplify all of this.
This is a solution who will facilitate password management and data security. So I would like that you encrypt the settings() database, cslog database not only the CSDB.
And also, it would be always very urgent to protect the CSDBE password with hashing, salt and other proved way.
So passwords used to:
a) Sync data to server;
b) User access of applications and right to add, modify, verify data;
will be stored in the encrypted CSDB file protected with password who must be secured by best proved way.

Best Regards,
G.VOLNY, a CSProuser from Haiti, since 2004
josh
Posts: 2399
Joined: May 5th, 2014, 12:49 pm
Location: Washington DC

Re: User Authentication

Post by josh »

Right now, without strong password protection (encryption) with best available methods, whatever non skilled person can connect to CSWeb and steal a whole survey/census database in minutes and disseminate it..
a bit of an exaggeration!
Right now, this can't protect any data file or password file since an enumerators having the pin code/password etc can copy or transfer over internet whatever file and open them on another computer. So, i never seeing the importance of this way.
Like I said above, it depends if you are protecting data from your enumerators or from strangers. Most operations we have worked on there is a basic level of trust of the enumerators since they are seeing the data already during the interview. If your own staff is trying to steal the data then data security is quite a challenge.
It was very easy for me to see theses settings and modify them in the past. I don't know if you changed the way you stored them in recent versions.
Good point, I should clarify this. On Windows you can view these fairly easily. On Android if you use savesetting() with the default settings file you cannot read the file outside CSEntry unless you root the device.

Note that saved passwords from sync are already stored in secure storage on Android and with Dropbox and CSWeb we only store an oauth token and not the plain text password.
htuser
Posts: 631
Joined: December 19th, 2011, 6:26 pm
Location: Silver Spring Area, MD, USA

Re: User Authentication

Post by htuser »

Hi Josh,
Right now, without strong password protection (encryption) with best available methods, whatever non skilled person can connect to CSWeb and steal a whole survey/census database in minutes and disseminate it..
a bit of an exaggeration!
I don't think the forum is the best place to discuss securities issues. In french it's "Se tirer une balle dans le pied"... I already write you about on
CSPro@lists.census.gov and we can continue to discuss about.

Right now, this can't protect any data file or password file since an enumerators having the pin code/password etc can copy or transfer over internet whatever file and open them on another computer. So, i never seeing the importance of this way.
Like I said above, it depends if you are protecting data from your enumerators or from strangers. Most operations we have worked on there is a basic level of trust of the enumerators since they are seeing the data already during the interview. If your own staff is trying to steal the data then data security is quite a challenge.
Rather than relying on the confidence of enumerators, i prefer finding technical solution to prevent.

Best Regards,
G.VOLNY, a CSProuser from Haiti, since 2004
Post Reply