User authentication: customize verification email?

[mark_talluto]

Security is essential to everyone. The CanelaDB libraries do not have passwords in them. Also, your user's passwords are not stored locally.

This solution provides the ultimate security for local data. But, it is inconvenient at the same time because we can not decrypt local data without user participation.

There are three solutions that we can offer. I am reasonably sure that we will end up building all three options, so everyone will have what they want. All apps are different and have varying needs.

1. Provide a universal password option. All local data is stored using the same password. The positive is that the local data is encrypted, and you can use a forgot password option that does not require internet access. The negative is that all apps that use this option would have their local data encrypted with the same password.

2. Provide an option where the local data is not encrypted. The positive is that the forgot password option would not need to deal with local data. The negative is that the local data is stored insecurely.

3. Provide an option that relies upon the user password being in the cloud. The database would automatically retrieve the password and decrypt the user's data. The positive is that this is the most secure option. The negative is that it requires internet connectivity.

If anyone wants to chime in, I am curious which options you find interesting.

[Bizbuzz]

Hi! I tested to download the default verify user template, changed some parameters, uploaded a new one, but the default template is still used when receiving verification emails.
And the same goes for Landing page link.
What could be wrong?

Hi BizBuzz,

You will need to re-export your toolkit for the app to use your email preference changes. You can consider putting a cdb_sdk() when your app opens so the app downloads the current toolkit automatically. (Note: cdb_sdk() will not download libraries, it only downloads the config file. You will still need to manually re-export new libraries manually when necessary)

I am re-replying this as I’m afraid it disappears with the other password recovery Issue:

And regarding password recovery options I opt for Nr 3 in the short term as many of us are using LiveCloud for the purpose of having databases in the cloud and thus making apps that requires internet connection in any case. The other options are interesting as well in future releases.

....
Hi! OK. Still doesn\t work for me. I've re-exported toolkit after updating (uploading new e-mail template), and putting a link to my landing page. And also used the get cdb_sdk() which successfully downloaded the config file ("Your SDK has been downloaded."), but when registering a new user I still get the default templates... Also did all usual stuff like restarting LiveCode etc..Any ideas?

[mark_talluto]

Security is essential to everyone. The CanelaDB libraries do not have passwords in them. Also, your user's passwords are not stored locally.

This solution provides the ultimate security for local data. But, it is inconvenient at the same time because we can not decrypt local data without user participation.

There are three solutions that we can offer. I am reasonably sure that we will end up building all three options, so everyone will have what they want. All apps are different and have varying needs.

1. Provide a universal password option. All local data is stored using the same password. The positive is that the local data is encrypted, and you can use a forgot password option that does not require internet access. The negative is that all apps that use this option would have their local data encrypted with the same password.  

2. Provide an option where the local data is not encrypted. The positive is that the forgot password option would not need to deal with local data. The negative is that the local data is stored insecurely.

3. Provide an option that relies upon the user password being in the cloud.  The database would automatically retrieve the password and decrypt the user's data. The positive is that this is the most secure option. The negative is that it requires internet connectivity.

If anyone wants to chime in, I am curious which options you find interesting.

An improvement to option #1 would be for LCM to generate a unique key for each project. This would remove the need for storing a key in the libraries. Each project would be encrypted with its own key. The key would be fixed, not visible to developers, and could never be changed. This makes option #1 more enticing because it improves its security and allows for easy change password options.

[mark_talluto]

It's good that there's now an email and landing page customization feature. 
I see it also covers password reset requests and temporary password. 
However, I can't find anywhere in the documentation what code to use to actually trigger the password reset request? Could you please explain?

Hi WhenInSpace,

The API for resetting passwords is not available at the moment. There has to be more thought put into it. Currently, a hash of the user's password is used to encrypt the local data on disk. If a user were to forget their password and change it, all of that local data would no longer be accessible. Unfortunately, we found this out the hard way in one of our apps. This is why there is no documentation on how to trigger a password reset. We will make the API available once we resolve this issue.

OK, this is interesting and a bit worrying. We have developed our own password reset/change features, as every app with a user login function must have one. People will always forget passwords, and in any case, changing your password from time to time is encouraged security behavior. 
But what you're saying then is that each time a user changes the password, the local data will become inaccessible?

This is less of a problem for my main project, as cloud will be master data and can always be sync:ed again. But what happens to the inaccessible local data then? Is it wiped and replaced by the new cloud -> local sync or would we get a build-up of abandoned garbage data, if users change their password often?

When we have solved the forgot password issue by providing the 3 suggested models, we will then remove files that are orphaned.

[clarencemartin]

Hi Mark.
I find that CanelaDB is a good database. I have gotten so used to your database that I am not considering using anything else. I like the idea of being able to have data that is available locally as well as having cloud availability along with versatility and encrypted security.
The security is essential especially these days.
I also want to be able to create applications that only have local access. Still, security is not something to be forgotten. Local password is essential, just to limit access from intruders.
I foresee the option of distributing a stand-alone application that is single-user exclusively but must still give the user the security of a user password. Everyone does not necessarily need cloud storage. In this case, a default user id would be "user "with a default password of" password". this is, of course, local data only. The user has the option to change the user id and the password. If the user forgets or loses or needs change the application will default to the default information. and then a new user id and password can be applied.
The existing default user options (cloud) work for other multi-user or cloud/local applications.

Kind of quick, lengthy and maybe over-explained! Sorry.

[mark_talluto]

Hi Mark.
I find that CanelaDB is a good database. I have gotten so used to your database that I am not considering using anything else. I like the idea of being able to have data that is available locally as well as having cloud availability along with versatility and encrypted security.
The security is essential especially these days.
I also want to be able to create applications that only have local access. Still, security is not something to be forgotten. Local password is essential, just to limit access from intruders.
I foresee the option of distributing a stand-alone application that is single-user exclusively but must still give the user the security of a user password. Everyone does not necessarily need cloud storage. In this case, a default user id would be "user "with a default password of" password".  this is, of course, local data only.  The user has the option to change the user id and the password. If the user forgets or loses or needs change the application will default to the default information. and then a new user id and password can be applied.
The existing default user options (cloud) work for other multi-user or cloud/local applications.

Kind of quick, lengthy and maybe over-explained! Sorry.

Hi Clarence,

Thank you for this feedback. Extra happy about your enjoying our database. We will continue to be sensitive to the need for security and simplicity. It is sometimes very hard to get both to align, but we will continue to hack at it until it feels native to the spirit of what we are trying to accomplish here.

[clarencemartin]

In the CanelaDB, is the password actually encrypted or is the UUID assigned just the reference to the password stored elsewhere?
If the password is actually encrypted rather then just referenced, the need for changing passwords for just GP becomes unnecessary, because CanelaDB cis the only way to read it. Am I correct with this assumption?

[mark_talluto]

In the CanelaDB, is the password actually encrypted or is the UUID assigned just the reference to the password stored elsewhere?
If the password is actually encrypted rather then just referenced, the need for changing passwords for just GP becomes unnecessary, because CanelaDB cis the only way to read it. Am I correct with this assumption?

Your user's password is not stored locally. The hash of their password is stored in the cloud as part of a record. That cloud record is stored encrypted to disk.

The next part is a bit long but important. Get a cup of coffee and continue on if you are interested.

-When the client is online
When you call cdb_auth(), we are checking with the stored data on the cloud to make sure the email and password combination match. A nonse value is sent back to the client. The auth routine continues to protect you from middle-man attacks by sending the secret nonse value back to the cloud. The cloud verifies that you sent the proper value and then returns with a thumbs up along with an API access key to allow the user to continue with your app. The cloud network, including all the data instances, user instances, and other related access points are updated with the temporary API access key. All subsequent calls will pass the API access key with every call so the various parts of the cloud know you have been authenticated. The instances will verify your API key for every call. Should it fail the match, your access to the cloud will cease and return an error that you can use to return the user to the login screen.

-When the client is offline
When you call cdb_auth(), the routine attempts to decrypt the local data which has been encrypted using a hash of the email and password. If the routine is successful, we give your app the thumbs up for local auth.

Should the user go online after local authentication, the cloud calls will require cloud authentication. You will need to have the user authenticate as explained above to gain access to the cloud data.

Thus, when your user sign's into your app, the password is only in the brain of the user. This makes things very secure as far as the tech is concerned. People are the weak point in the process as they do things that can make a secure process insecure. For example, they put passwords in a written form that may not be secure. Taking all that aside, the method we have chosen is pretty good. The next step would be to offer 2FA (two-factor authentication) for authentication as an option. We use 2FA when you do a forgot password as one example of 2FA already being in CanelaDB and LiveCloud.

I think it is important everyone understands how this works so you can decisions or at least have an opinion on the security provided in CanelaDB and LiveCloud.

[clarencemartin]

Got it, thanks.