How are you handling password management in your application?
Devanand Premkumar
22 replies
Still using old and outdated password management requirements like the following:
a. Passwords should be minimum of 8 characters in length.
b. Passwords should have a lower case, upper case, numbers, and special characters.
c. Set your secret question and answer for password recovery.
d. Force password reset after defined number of days
Curious to know your thoughts on the same.
Replies
Hasan Diwan@hasan_diwan
I let the upstream Oauth provider handle passwords -- Google or Reddit are far better funded to handle it than I.
Share
@hasan_diwan Sure looks like an easy way out :)
Create HTML Form
I put this on a third party user management service, which is Azure AD B2C in my case. It provides several grades of password complexity, right now it's
`Minimum 8 characters and maximum 64 characters in length 3 of 4 character classes - uppercase, lowercase, number, symbol. The error message for password validation is updated when a requirement is met.`
@xakpc IMHO passwords maximum length should not be restricted as long as the storage is not plain text. This restriction was enforced historically to save space and now with password hashing algorithms widely used, this should no longer be needed.
Adding to that, the minimum length of 8 is an absolute low value considering the current computing power every common man has these days.
I'd say that b) is not that necessary - of course if we will make user to type in a longer (and weird) password.
A simple math example:
Password with 8 characters including all possible ASCII codes that we can type using standard keyboard gives us 96^8 = around 10^15
Password with 16 characters using only lower case, upper case and numbers gives us 62^16 = around 10^28
Password with 16 characters using only lower and upper case gives us 56^16 = around 10^27
So, by using e.g. "SofedByBorrosed" - random English-sounding words (still easier to remember than "Q52G{96g)") not only we have a higher chance that our user will make a new password just for our app and won't use this one phrase he uses everywhere, but also we made sure that he may have a stronger password.
Of course, I know that in a fair competition 96^16 is around 10^31 and somebody can just type in "I love my mom", but we can deal with that in at least two ways:
1. We can encourage users to type in such weird phrases, showing examples (and checking if users aren't copying them)
2. We can establish a service that will check if password can be easily broken by dictionary attack - and we can inform user that he has to be more creative.
@jackhalabardnik That is a valid point. But the big question is how do we enforce 1 and 2 on our own applications?
I use, AWS Cognito for user pool management. On a through d - I've recently jumped on the passwordless authentication train because of UX friction, and terrible end user security practices. This is one example workflow https://aws.amazon.com/blogs/mob...
@_mattoconnell I was reading about this Magic Link and it a very simple email link shared for login authentication compared to password. Simple for users and every one of them would be happy to type in their email to get the Magic Link. Cool!
@_mattoconnell How is your experience with password less authentication? Do you think the mainstream applications can migrate to password less authentication soon?
@devaonbreaches I believe more and more will. Slack has been doing it with their Magic Link for a while now.
I just use a password generator or whatever Firefox recommends.
For sites that should be used with higher security practices, I have a spreadsheet that tells me when to update.
@justfitnessguy I was wondering more on how do you handle the password requirements for JustFitness application?
@devaonbreaches
oops. It was 0100.
I use firebase authentication.
a-b: I accept whatever google accepts.
c: Password recovery via email
d: Not applicable
@devaonbreaches @justfitnessguy
Same, save for web where I usually try Google sign in url without firebase, and nodejs webtoken sessions... Why? Because of library filesize of firebase. (edited, I don't now how size was missed from last post)
@devaonbreaches @jesus_zorrilla
yeah, that file is huge.
I wonder if I can get firebase auth via cdn and defer its loading.
@justfitnessguy Makes sense now :)
What about s Pin I have a log on ID and security number then 5 digit PIN to use my bank account. The 5 digit PIN is brilliant on a app because it's easier that typing a password each time
@windridge PINS are more common on mobile apps for sure. But I was asking more on traditional applications with a web interface or a thick client.
Sawo Labs
I'm working on an API tool which will make this question redundant, the whole goal is to help website/app owners to signup/singin users without any password requirements. This way user on-boarding is much more fast, flawless and secure. You can check it out on (https://sawolabs.com) Any feedback is really appreciated.
@sawo_labs Congratulations Prabhat. Super curious to know more about your API and will be happy to check SAWO.