Sublime Ads - Password logic and design choices
Last week I worked on finalising the password section for the web app. I thought I'll share some thought process behind the way I'm doing things.
When your first register for an account, on Sublime Ads, you will have a choice if you either want a magic link login or if you'd like to set your own password:
Magic links are one time links, sent to your registered email address that allow you to log into the site. They're only valid for 15 minutes and expire immediately once you've logged in.
Alternatively, if you don't want magic links, you can create a password of your choosing. Simple enough.
Password enforcement with a little bit of magic
When you create a password, you'll notice a lack of "this passwords needs to be at least 8 characters or longer, needs to contain a letter" blah blah blah.
No, you can't choose "password" or anything deemed insecure.
In fact, what I do, is check against the "have i been pwned" database to see if your password is secure.
"have i been pwned" (HIBP) is a popular service that allows you to look up any passwords that have previously been exposed in big hacks. It's a great indicator to see if your password is secure or not.
When you submit your password, the password is hashed. For example, the password "password" looks like this as a hash: 5f4dcc3b5aa765d61d8327deb882cf99
Now, I take the first five characters of the hash: 5f4dc
This hash is then sent to the HIBP API. The API then returns a number of entries with hashes that start with that exact hash.
With that list of entries I can now check, locally within the app itself, if the password you entered matches any of the items returned. In the case of the password "password" it will of course return results.
Just as a note, as you can see above, your password is never ever sent to HIBP.
So, if you try and enter a password that seems insecure and is in the HIBP database, the web app will tell you to choose another one.
I personally think that's a great compromise between strict enforcement and ease of use.
One-time passcodes
For anything going forward, I will make two-factor authentication mandatory for all my web apps that contain data of my users. This is for your and my protection.
On successful password create, either using magic links or a password, you will come up on the OTP screen - where you have to scan the code displayed on the screen.
Then I'll ask you to enter that code to proceed.
Your OTP code is used in various places throughout the app, for an extra layer of authentication.
Modern apps like 1Password all have this built in.
Password options after registration
In your settings, you'll be able to find the password module. It's quite simple and hopefully informative enough.
Human readable with clear options. In the screenshot above you can see that I'm using a password login on my local machine. That gives me several options. I can use magic links, or I can change my password.
If you have magic links enabled, you'll see the below:
One consistent option is to view your OTP QR code; the one you registered with. That's a special link, that will trigger an email to your verified email address. I didn't want to allow you to just get in that section without some sort of extra security step. Again this is a one-time link and expires within 15 minutes if not used.
Of note, the password section is disabled when your email address is not verified. That's most likely the case when you have just registered... and didn't click/tap on the verification email.
Changing or creating a password is similar to what you find when going through the registration steps.
Again I'll check against the HIBP database, as mentioned above. One extra step is to also enter your OTP code as I deem that a good security compromise.
Wording and design
In general I decided to use a bit more wording within the UI just to explain, clearly, what you have enabled or not. That includes any other aspects of the app too.
I'm constantly tweaking the wording too... I'm never happy.
On a side note again, the app can be localised easily as I've set it up correctly from the start, so I should be able to copy it across for any other language down the line.
On the design front, I kept away from too much clutter... not to cause too much eye strain. I think it's working so far and I'm happy with the results.
Closing thoughts
I understand that sometimes you may loose access to your devices and other things that include your authentication app.
I am planning on adding the ability to set up a recovery token, just in case you do loose access to your OTP code. Not 100% sure how I'll go about it yet as I need to make sure it's secure enough without my intervention.
However, I don't deem this necessary until after launch.