• Subscribe
  • 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
    I let the upstream Oauth provider handle passwords -- Google or Reddit are far better funded to handle it than I.
    Pavel Osadchuk
    Create HTML Form
    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.`
    Devanand Premkumar
    @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.
    Jacek W贸jcik
    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.
    Devanand Premkumar
    @jackhalabardnik That is a valid point. But the big question is how do we enforce 1 and 2 on our own applications?
    Matt O'Connell
    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...
    Devanand Premkumar
    @_mattoconnell How is your experience with password less authentication? Do you think the mainstream applications can migrate to password less authentication soon?
    Matt O'Connell
    @devaonbreaches I believe more and more will. Slack has been doing it with their Magic Link for a while now.
    Devanand Premkumar
    @_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!
    Al
    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.
    Devanand Premkumar
    @justfitnessguy I was wondering more on how do you handle the password requirements for JustFitness application?
    Al
    @devaonbreaches oops. It was 0100. I use firebase authentication. a-b: I accept whatever google accepts. c: Password recovery via email d: Not applicable
    Jes煤s Zorrilla
    @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)
    Al
    @devaonbreaches @jesus_zorrilla yeah, that file is huge. I wonder if I can get firebase auth via cdn and defer its loading.
    Perryn Biggs
    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
    Devanand Premkumar
    @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.
    Prabhat Sahu
    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.
    Devanand Premkumar
    @sawo_labs Congratulations Prabhat. Super curious to know more about your API and will be happy to check SAWO.