5 ms·

Yesterday I had a good example of this. Website: "Please choose a complex password of at least 8 characters including special characters and numbers" Me: Fire

• thedanbob 2y ago
  Maybe we need a corollary to "don't roll your own crypto": "don't roll your own password scheme".
  • lazide 2y ago
    So what is the ‘standard’ then that doesn’t suck?
    • Morpholemew 2y ago
      https://pages.nist.gov/800-63-3/sp800-63b.html#memsecret https://pages.nist.gov/800-63-3/sp800-63b.html#memsecret Basically, 8 characters or more, but prevent the user from picking a password that appears on any of the leaked password lists. Store in pbkdf2 or better; use argon2id per https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html https://cheatsheetseries.owasp.org/cheatsheets/Password_Stor... That's it. Simple. No mandatory symbols. No mandatory changes after a period of time. A password strength estimation meter is optional. If it needs to be more secure, I might require more minimum characters, but no other restrictions.
      • lazide 2y ago
        Ah, yet another standard. How many years do you think before it’s obsolete? Also, the ‘no previously leaked passwords’ are gonna piss off a lot of customers.
        • smrq 2y ago
          I think you just picked up the goalposts and brought them home with you. Why ask for a standard in the first place?
          • lazide 2y ago
            Because this is what, the third NIST standard on it?
            • a_dabbler 2y ago
              Things can change? The newer standards improve upon the errors of the old ones and presumably make the old ones deprecated
      • kevin_thibedeau 2y ago
        8 chars is not sufficient. The Hive strength estimates switched to Bcrypt this year but there are still weak systems out there and you should set passwords assuming MD5 which currently demands at least 12 chars for typical users.
      • compootr 2y ago
        What's your opinion on zxcvbn[0]? It dynamically analyzes a password's cracking time, score, and gives feedback based on the password. imo it's a pretty good ux if used right [0]: https://github.com/dropbox/zxcvbn https://github.com/dropbox/zxcvbn
        • lynndotpy 2y ago
          Misused, zxcvbn offers its own security issues. First, it's not either-or. You can match against zxcvbn strength and some passwordlist. Second, think of the output of zxcvbn as a very weak hash with a low collision rate. E.g. 'correct-battery-horse-staple' maps to an estimated 213811968952000000000 guesses. In addition to being potentially algorithmically reversible, attackers can simply perform an offline attack against the value 213811968952000000000. So, this metric should never be exposed (e.g. in log files, on screen, etc.) Third, having the estimated entropy helps a lot when password cracking. If you have the password hash digest and the zxcvbn metrics, then it makes the cracker's job much easier by reducing the search space. (Think, going from checking each molecule of an apple to checking only each molecule on the peel of an apple.) Further, it's not perfect. The zxcvbn library I used suggests 'correct-battery-horse-staple' is a very strong password!
          • maratc 2y ago
            It indeed is. The bad password you're thinking of is "correct-horse-battery-staple".
            • lynndotpy 2y ago
              Both are bad passwords, and zxcvbn states both are good. Try it here: https://lowe.github.io/tryzxcvbn/ https://lowe.github.io/tryzxcvbn/ Zxcvbn is imperfect by design. It's a tradeoff it makes for being fast and small.
              • maratc 2y ago
                You might want to re-read the introductory article [0] where the authors themselves look at that specific password. [0]: https://dropbox.tech/security/zxcvbn-realistic-password-strength-estimation https://dropbox.tech/security/zxcvbn-realistic-password-stre...
  • xyst 2y ago
    Better yet, don’t use passwords at all. I’m personally fond of the magic link sent to email method of authN
    • monooso 2y ago
      I'm the opposite. I deliberately avoid checking my email outside of predefined times, and hate it when a website assumes that everyone is happily living in their inbox.
    • bobbylarrybobby 2y ago
      This doesn't work well if you aren't working in your default browser and if the link expires after a single use. For instance, if you're trying to log into an app (not a website) and the redirect to the app doesn't work when you tap the link in your email. I suppose an alternative approach would be to open a websocket in the post login page, and if you open the link in your email the server sends your browser a cookie or something, and then you're in. But I've never seen that approach.
• Seanambers 2y ago
  Ran into the same thing with Santander Bank in Poland. I have been online since the 90s never seen that password scheme ever anyplace else. It´s like who comes up with this insane shit.
  • high_na_euv 2y ago
    https://security.stackexchange.com/questions/7467/how-secure-is-asking-for-specific-characters-of-passwords-instead-of-the-entire https://security.stackexchange.com/questions/7467/how-secure... 12 years old post talking about polish banks and the reasoning :)
• deepsquirrelnet 2y ago
  Until recently, treasurydirect made you login using your mouse by pressing a keyboard laid out on a screen. This is a government website in the US for buying treasury bonds. I didn’t know this when I made my account and fired up keepass per usual to create a massive random password. It takes me nearly 5 minutes of carefully pressing buttons on the screen and trying to keep my location in the password (you can’t see what you entered) just to get in.
  • salil999 2y ago
    I got around this by just editing the HTML. Worked like a charm
    • ericd 2y ago
      Yeah, you could just delete "readonly" from the input, then try the password manager autofill again. Thankfully no longer necessary.
    • Someone1234 2y ago
      Also demonstrates how pointless that theater was. A lot of GOOD malware don't "sniff keys" because that gives them random stream of garbage that has little value. No human is going to sit there and hand-decipher that garbage. Instead, they either inject browser extensions, intercept at the Win32 layer, or intercept the HTTP traffic upstream of the browser giving them the raw form-fields with URL which can be packaged and sold. So all TreasuryDirect was doing, when they were doing this, was inconveniencing real people while the malware didn't even notice. Utterly insane. Glad someone had them quit it.
      • Grimblewald 2y ago
        a lot of efforts to prevent malpractice are like this. Anti-piracy software only really hurts paying customers for example.
    • Intralexical 2y ago
      These days I'd be scared that fails some biometric spyware and gets your entire account instantly banned+deleted with no recourse.
• kevin_nisbet 2y ago
  That's a good one. One of my personal favorites was a device that truncated long passwords in the set password function. Didn't take too long to figure out what happened but I was worried for a moment I wouldn't be able to unbrick that device.
• xyst 2y ago
  > “Please enter the characters in the 31, 98, 102 position…” I think this is a “the password game” requirement.
• MrJohz 2y ago
  > Edit: It's now dawned on me that they're storing this plain text so that they can do this... or at least encrypting rather than hashing, meaning that they can always decrypt the password. It could well be that they're doing the encrypt/decrypt thing, but you can also get the same affect by pre-calculating the slices of password and hashing those slices. For example, when you create the new user entry, you could take the password, pick three random characters from it, and store the indexes and the hash together in a table row (in your case, something like ("31,98,102","salt$hashfgtd")). You do that two or three times, and then, every time you ask the user to log in, you randomly choose one of these entries, ask the user to enter the character positions, and check the hash of the result against the hash in the row. The Student Finance England website used to have a similar setup about asking for letters X, Y, and Z, but it rotated between only a handful of combinations, so I think it probably used something like this. That said, a few years ago gov.uk took over the SFE login form and modernised it, including replacing the XYZ system with a version where you just enter the whole string, so presumably either they also had hashed the whole string, or they were storing it in a format that was retrievable. Or I guess they still only store the XYZ tuples but do the indexing and comparison logic internally.
• high_na_euv 2y ago
  >It's now dawned on me that they're storing this plain text so that they can do this... https://en.m.wikipedia.org/wiki/Shamir%27s_secret_sharing https://en.m.wikipedia.org/wiki/Shamir%27s_secret_sharing
  • kevincox 2y ago
    How would you securely implement this scheme with SSS?
• tengwar2 2y ago
  Sometimes passwords are stored in plain text to improve security. An example is K in mobile telephony, a number shared between the home network and the USIM. This is used for mutual authentication and establishing a cryptographic session key. There is no concept of a certification authority (which can be subverted) or a signature - there is just a shared secret, stored in plain text, so there are minimal trust requirements. But stored in a secure piece of hardware with write-only access for K. You pass a challenge in, and get back a number which can be used to prove identity, and a number which can be used to establish a crypto context (here I am simplifying by not describing the mutual authentication). Ok, so in the context of your mortgage website, they may be doing the same thing. The motivation may be to stop keyloggers or anyone who is "inside" HTTPS getting the password. The implementation may be a hardware security module which is write-only for the password and which gives a yes/no answer when asked to check a character.