Best practices for getting/storing passwords
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
-
- VIP Livecode Opensource Backer
- Posts: 931
- Joined: Thu Nov 13, 2008 6:48 am
Best practices for getting/storing passwords
Hi, I'm developing an iOS application that needs to protect the data (stored in an SQLite file). If the application asks for a password before opening, what is the best place and format to store the password in? I understand you can't store the pw in the stack of the application, since iOS won't let you write to that. Where would you suggest storing the password, and do you think having it in encrypted form makes a difference?
Thanks
-- Mark
Thanks
-- Mark
macOS 12.6.5 (Monterey), Xcode 14.2, LC 10.0.0, iOS 15.6.1
Targets: Mac, iOS
Targets: Mac, iOS
Re: Best practices for getting/storing passwords
Hi Mark,
If all data are stored on the phone itself, then you only need to remind the user of the possibility to lock the phone with a password and to store backups encrypted (see the backup options in iTunes). It would be user-unfriendly to put yet another password between the user and the data.
If the password is for accessing data on a server (which doesn't seem the case), you can use mcEncrypt to store the password in a non-reversible way. Just mcEncrypt the password entered by the user before checking it against the stored password. You can store this password in specialFolderpath(documents).
As long as a phone isn't jailbroken and the password is stored somewhere in an application-specific directory, i.e. not in the shared files directory, it shouldn't matter if the password is encrypted or not, but since it is easy to use mcEncrypt, I'd just offer this little bit of extra safety if you decide to use an extra password.
Is there a special reason why you want to use an additional password?
Kind regards,
Mark
If all data are stored on the phone itself, then you only need to remind the user of the possibility to lock the phone with a password and to store backups encrypted (see the backup options in iTunes). It would be user-unfriendly to put yet another password between the user and the data.
If the password is for accessing data on a server (which doesn't seem the case), you can use mcEncrypt to store the password in a non-reversible way. Just mcEncrypt the password entered by the user before checking it against the stored password. You can store this password in specialFolderpath(documents).
As long as a phone isn't jailbroken and the password is stored somewhere in an application-specific directory, i.e. not in the shared files directory, it shouldn't matter if the password is encrypted or not, but since it is easy to use mcEncrypt, I'd just offer this little bit of extra safety if you decide to use an extra password.
Is there a special reason why you want to use an additional password?
Kind regards,
Mark
The biggest LiveCode group on Facebook: https://www.facebook.com/groups/livecode.developers
The book "Programming LiveCode for the Real Beginner"! Get it here! http://tinyurl.com/book-livecode
The book "Programming LiveCode for the Real Beginner"! Get it here! http://tinyurl.com/book-livecode
Re: Best practices for getting/storing passwords
I would also wonder about Apple's response. They do not allow custom licensing schemes, so if you do this then it would be good to make extensive notes to the reviewers explaining how your password is not a licensing method. Otherwise they may misunderstand and reject the app.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
-
- VIP Livecode Opensource Backer
- Posts: 931
- Joined: Thu Nov 13, 2008 6:48 am
Re: Best practices for getting/storing passwords
Thanks Mark. I was going to use the password to also encrypt/decrypt the sqlite file. I guess what I am really after is the most secure method to create an encryption key for the purpose I stated (encrypting/decrypting the file). This, I suppose, does not have to be a password. Any suggestions?Mark wrote:Is there a special reason why you want to use an additional password?
Mark
-- Mark
macOS 12.6.5 (Monterey), Xcode 14.2, LC 10.0.0, iOS 15.6.1
Targets: Mac, iOS
Targets: Mac, iOS
Re: Best practices for getting/storing passwords
Hi Mark,
If you decrypt the file on an iOS device and store the decrypted file temporarily and the device crashes, you will have an unencrypted file that might be copied off your phone or backed up unencrypted. The best way still is to tell the user to put a lock on his phone and to encrypt backups in iTunes.
About those backups: it seems to be better not to encrypt using the iTunes feature (I was wrong in my previous post) and you can always set the iphoneSetDoNotBackupFile command for your database file.
Sometimes, you might want to include files that the user shouldn't have access to. In that case, you can store a file in a(n encrypted) custom property and decrypt it in memory only. Unfortunately, a sqlite database is exactly the type of file you shouldn't do this with, because you'd still have to store it in unencrypted form in a directory.
You could ask someone to write a new sqlite external for you, which includes the encryption extension. That would allow you to create an encrypted database file. Another option is to write your own database engine in LiveCode.
Apple might frown if additional encryption is used, but Apple is very unpredictable in this respect. A good example of a programme using additional encryption is 1Password, which Apple allowed.
Kind regards,
Mark
If you decrypt the file on an iOS device and store the decrypted file temporarily and the device crashes, you will have an unencrypted file that might be copied off your phone or backed up unencrypted. The best way still is to tell the user to put a lock on his phone and to encrypt backups in iTunes.
About those backups: it seems to be better not to encrypt using the iTunes feature (I was wrong in my previous post) and you can always set the iphoneSetDoNotBackupFile command for your database file.
Sometimes, you might want to include files that the user shouldn't have access to. In that case, you can store a file in a(n encrypted) custom property and decrypt it in memory only. Unfortunately, a sqlite database is exactly the type of file you shouldn't do this with, because you'd still have to store it in unencrypted form in a directory.
You could ask someone to write a new sqlite external for you, which includes the encryption extension. That would allow you to create an encrypted database file. Another option is to write your own database engine in LiveCode.
Apple might frown if additional encryption is used, but Apple is very unpredictable in this respect. A good example of a programme using additional encryption is 1Password, which Apple allowed.
Kind regards,
Mark
The biggest LiveCode group on Facebook: https://www.facebook.com/groups/livecode.developers
The book "Programming LiveCode for the Real Beginner"! Get it here! http://tinyurl.com/book-livecode
The book "Programming LiveCode for the Real Beginner"! Get it here! http://tinyurl.com/book-livecode
-
- VIP Livecode Opensource Backer
- Posts: 931
- Joined: Thu Nov 13, 2008 6:48 am
Re: Best practices for getting/storing passwords
You make a good point I had not considered. Back to the drawing board... (or, that external that handles SQLite encryption is sounding more and more appealing by the minute...)Mark wrote: If you decrypt the file on an iOS device and store the decrypted file temporarily and the device crashes, you will have an unencrypted file that might be copied off your phone or backed up unencrypted. The best way still is to tell the user to put a lock on his phone and to encrypt backups in iTunes.
Why so? BTW, I've been looking around for mcEncrypt and could not find much. Is that just the name for the encrypt/decrypt commands in lc?Mark wrote: About those backups: it seems to be better not to encrypt using the iTunes feature (I was wrong in my previous post) and you can always set the iphoneSetDoNotBackupFile command for your database file.
-- Mark
macOS 12.6.5 (Monterey), Xcode 14.2, LC 10.0.0, iOS 15.6.1
Targets: Mac, iOS
Targets: Mac, iOS
Re: Best practices for getting/storing passwords
Hi Mark,
Read this: http://qery.us/3bn
McEncrypt is used by the ask password command to encrypt the user input. It is a one-way hash, which makes it a suitable for everything password-related in LiveCode. Just try it in the message box:
If you enter "Hello world" as a password, LC will show the message "You got it".
Of course, you could also use md5Digest, which will sound more familiar to Apple's reviewers but can't be considered safe anymore.
Kind regards,
Mark
Read this: http://qery.us/3bn
McEncrypt is used by the ask password command to encrypt the user input. It is a one-way hash, which makes it a suitable for everything password-related in LiveCode. Just try it in the message box:
Code: Select all
put "hello world"
ask password "Enter a password"
if it is "+b,%$6xx+I:" then answer "You go it"
else answer "Wrong password"
Of course, you could also use md5Digest, which will sound more familiar to Apple's reviewers but can't be considered safe anymore.
Kind regards,
Mark
The biggest LiveCode group on Facebook: https://www.facebook.com/groups/livecode.developers
The book "Programming LiveCode for the Real Beginner"! Get it here! http://tinyurl.com/book-livecode
The book "Programming LiveCode for the Real Beginner"! Get it here! http://tinyurl.com/book-livecode
-
- VIP Livecode Opensource Backer
- Posts: 931
- Joined: Thu Nov 13, 2008 6:48 am
Re: Best practices for getting/storing passwords
Many thanks!Mark wrote:Read this: http://qery.us/3bn
McEncrypt is used by the ask password command to encrypt the user input. It is a one-way hash, which makes it a suitable for everything password-related in LiveCode. Just try it in the message box:
macOS 12.6.5 (Monterey), Xcode 14.2, LC 10.0.0, iOS 15.6.1
Targets: Mac, iOS
Targets: Mac, iOS