16 ms·

Password Requirements: Myths and Madness

283 points by alanfranz 4y ago

kube-system 4y ago
The best solution to password requirements is to eliminate passwords altogether. Passwords are the most problematic and weakest authentication factor we have. Instead, let’s authenticate with PKI. It works.
pvorb 4y ago
> Or maybe the keyboard layout isn't yet set when the password is entered (example: full disk encryption password at boot) and you risk that a user is entering a password at install time, but what they write at boot is actually different. This is a very good point, which already made me struggle when setting up new computers. For instance, the Ubuntu installer runs in a Gnome environment with my keyboard layout active. The disk encryption prompt runs shortly after the BIOS screen and will likely have some US keyboard layout. If you choose anything special for your password, you'll have a hard time figuring out how to type it in a different keyboard layout.
- SAI_Peregrinus 4y ago
  It's just another thing to remember to set. The keyboard layout CAN be set at boot (I do it), but it's separate from the keyboard layout in a graphical session.
- lucb1e 4y ago
  I work for a German company. You bet that I know to find most symbols on a German keyboard layout. Thankfully the base letters contain only one swap. For extra fun, one colleague in particular likes to set excessively long passwords of like 50 characters when it is not expected that anyone will ever have to type them. The number of times I had to type one of these because this sysadmin works remotely and I'm the hands in the office when needed...
- Avamander 4y ago
  Ubuntu and probably others set the correct keyboard layout for even GRUB itself, not to mention Linux, so it's fine. Windows is probably worse, it doesn't even let you remove other layouts.
galangalalgol 4y ago
For judging complexity I always thought large businesses should just set aside some compute to try to brute force passwords with the hash. If they get yours, you have to change it and get a talking to. If they can't get it, they give you $X where X is big enough to be a pleasant surprise.
- kccqzy 4y ago
  Idea: just run a standard compression algorithm on the password and measure its length.
anewguy9000 4y ago
yep, most of the discussion about passwords completely miss the point. a random word, like "dog" or "pingpong" is fine if the pqsswords are salted and hashed appropriately. how often have your accounts been hacked this way? if an adversary is really banging on the hash, and they want it, any password under around 50 characters is as good as "dog", and no "complexity" meter is gona cut it. that xkcd comic that says 550 years? no, that password its owned a lot a faster than that. all this talk of entropy and security but so obviously clueless about modern brute force techniques
- lucb1e 4y ago
  > most of the discussion about passwords completely miss the point. [...] any password under around 50 characters is as good as "dog" I think you've completely missed the point. After how long do you start to get annoyed when logging in? Most people probably at 2-5 seconds, but let's say ten full seconds of waiting for the computer to do the hashing. A word like dog is among the top few thousand words, let's say ten thousand, so after 10k×10s/(3600 seconds per hour) = ~28 hours your password is cracked on a single cpu. Probably more like 28 minutes on a couple GPUs, and this is using a complexity setting that literally nobody is going to use (I bet even the NSA isn't paranoid enough to wait 10 seconds for every login). Now compare that to "any other password under around 50 characters". If you want to use a passphrase, pick random words (at least five when using complex words; the number depends on your dictionary size). Not a single word that is also very common. That completely misses the point. This strategy would work if literally everyone uses a random words generator and yours, against all odds, comes up with a single common word. Then attackers would have no reason to crack in order of commonness and start with a single word. But that is not the reality we live in and attackers do start with simple passwords before complex ones. (Source: one of the things we do at work is crack passwords, most commonly when we get our hands on Windows password hashes.)
  - anewguy9000 4y ago
    im sorry, what point are you making? if its that "dog" is a weak password, i thought that was evident. but many people seem confused that "horseloverwhatever" is more secure, similarly that "dog23!Wog" is more secure. my point is they are equally trash so leave the user alone
janalsncm 4y ago
> A short password is easy to bruteforce. But, a website should aim at password strength, not at password length. Is there a standard metric for “strength” though? I built my own random password generator and considered adding a strength meter but all of the functions I could find online seemed like they had pretty arbitrary logic. Length is probably the most objective proxy for strength.
- chadlavi 4y ago
  The author links to a recommended library in the blog post https://github.com/dropbox/zxcvbn https://github.com/dropbox/zxcvbn
  - lucb1e 4y ago
    I was looking, last week, what to recommend to a customer and ended up at https://github.com/zxcvbn-ts/zxcvbn https://github.com/zxcvbn-ts/zxcvbn because the one from Dropbox seems to be completely abandoned and does not recognize e.g. 2020 as a year. Other alternatives are also welcome if there is an even better one I missed! This was the best password strength estimator I could find.
- cirrus3 4y ago
  Check out https://www.grc.com/haystack.htm https://www.grc.com/haystack.htm
  - LeoPanthera 4y ago
    This particular tool is misleading at best. It counts only characters, and so misleadingly overrates passwords which are strings of words. Compare it with this one, which actually identifies words and other patterns, for a more accurate guess of the search space: https://www.bennish.net/password-strength-checker/ https://www.bennish.net/password-strength-checker/
    - cirrus3 4y ago
      I only said check it out, there is a lot of content there useful to the wider topic and the page clearly states what it is and isn't. >>> IMPORTANT!!! What this calculator is NOT . . . It is NOT a “Password Strength Meter.” Since it could be easily confused for one, it is very important for you to understand what it is, and what it isn't: The #1 most commonly used password is “123456”, and the 4th most common is “Password.” So any password attacker and cracker would try those two passwords immediately. Yet the Search Space Calculator above shows the time to search for those two passwords online (assuming a very fast online rate of 1,000 guesses per second) as 18.52 minutes and 17.33 centuries respectively! If “123456” is the first password that's guessed, that wouldn't take 18.52 minutes. And no password cracker would wait 17.33 centuries before checking to see whether “Password” is the magic phrase. Okay. So what IS the “Search Space Calculator” ? This calculator is designed to help users understand how many passwords can be created from different combinations of character sets (lowercase only, mixed case, with or without digits and special characters, etc.) and password lengths. The calculator then puts the resulting large numbers (with lots of digits or large powers of ten) into a real world context of the time that would be required (assuming differing search speeds) to exhaustively search every password up through that length, assuming the use of the chosen alphabet. How can I apply this to my daily life? Answering that question is the reason this page exists. The whole point of using padded passwords is to adopt a much more you-friendly approach to password design. On June 1st, Leo Laporte and I recorded our weekly Security Now! podcast as part of Leo's TWiT.tv (This Week in Tech) audio and video podcasting network. You may download a shortened, 37-minute, excerpted version presenting the padded password and Haystack calculator concepts:
joezydeco 4y ago
My favorite is this transaction: I forgot my password. Can you send me a link? Sure, here you go. Pick a new password. Okay, CorrectHorseBatteryStaple. Sorry, you can't use an old password
- danrocks 4y ago
  Funny, sure. But you still can have the same transaction by hashing "CorrectHorseBatteryStaple" then comparing with the stored hash.
  - the_af 4y ago
    I think the OP is arguing you can guess a (possibly) current password this way.
    - qup 4y ago
      Only if you guess it on the first attempt.
    - joezydeco 4y ago
      I'm just amused by the irony of forgetting my password, going through the reset process, then realizing I did remember my password. Except now I can't use it any more.
      - zargon 4y ago
        Does it not let you log in with your old password after requesting a password change? That seems even more problematic, since anyone can request you password be changed.
        joezydeco 4y ago
        Sometimes it does, sometimes it doesn't. More annoyances.
- cirrus3 4y ago
regularjack 4y ago
Off-topic but not sure having a patronizing cookie banner is the best strategy.
- alanfranz 4y ago
  It’s a very old banner, I didn’t mean for it to be patronizing, just to mock the absurd cookie law which had just passed. I’m trying to go cookieless, actually, I hope to finish someday, Google Analytics was removed already. I’ll need to ask for explicit authorization for disqus commenting only.
- alanfranz 4y ago
  Cookies and banner have been removed!
lucb1e 4y ago
> A short password is easy to bruteforce. But, a website should aim at password strength, not at password length. If it is "easy to bruteforce" (guess without any prior knowledge), then it is not "strong". > If I use four unicode code points outside the [multi-language characters table], my password is probably very safe already. Security through obscurity. This is safe until everyone does it. It's not a strong password by virtue of being short, it's strong because this is impossible to input and so nobody uses it and so it doesn't make sense to guess. But you bet that if you ever log into a compromised system, use a phishing page, or a site stores and loses your password in plain text, the gig is up and it's known that cracking u/alanfranz's passwords is a matter of trying a few random unicode characters instead of letters. > You cannot show or copy this field [...] My verdict: Security through obscurity Security through obscurity is it being secure by being rare. It's not about it being literally invisible. I agree with the point but this is not what obscurity means. Most of this post makes sense (password expiry, maximum length, requiring special symbols, disallowing other symbols) but we've known these things for decades now. We keep putting it in reports and customers are slowly catching up. Recently saw the first customer who, in a retest, used a reasonably sized deny list of common passwords on an embedded device! I was definitely impressed. We're getting there, ever so slowly.
- alwayslikethis 4y ago
  > > If I use four unicode code points outside the [multi-language characters table], my password is probably very safe already. > Security through obscurity. This is safe until everyone does it. It's not a strong password by virtue of being short, it's strong because this is impossible to input and so nobody uses it and so it doesn't make sense to guess. But you bet that if you ever log into a compromised system, use a phishing page, or a site stores and loses your password in plain text, the gig is up and it's known that cracking u/alanfranz's passwords is a matter of trying a few random unicode characters instead of letters. This is plain wrong. The Basic Multilingual Plane consists of 65536 most commonly used codepoints. If your password contains a character outside of the BMP (e.g. an emoji), the attacker has to be bruteforcing over at least one other plane in addition to the BMP, which is 2*65536 characters = 17 bits of entropy per character. 4*17 = 68 bits of entropy is plenty. Even if everyone included an emoji in their passwords, this won't become any weaker.
chordalkeyboard 4y ago
there is also a disconnect between password requirements and automatically generated passwords, where often the auto-generated password contains prohibited characters.
cirrus3 4y ago
Password managers are "obviously" the solution - in my experience they generate good passwords that are accepted almost all the time now days. However, I still think 3rd-party password managers are too complex for many people, and those people are the ones who need them most. OS-level password management is a bit easier but not great. Browser native password managers are a terrible idea IMO, for people who can't handle a 3rd party manager, imagine their confusion when only a specific browser knows their password, and only when they signed into their browser vendor account.
- pontilanda 4y ago
  The interoperability boat has sailed. macOS has had an open Keychain for decades and Google eventually dropped support for it. I don't see them suddenly going back, sharing efforts and allowing cross compatibility. What we need is just passwords to come front and center anywhere they are: We need a Password.app that I can open and access all I need. Keychain Access was exactly that but its UI is stuck in 2000.
deleted 4y ago
[deleted]
_dan 4y ago
In the b2b world it's basically impossible to improve password policies. Most of the onerous examples only exist because some other entity (a customer, insurance company, parent company, etc) has demanded them. The problem is that the demand isn't being made by security professionals, it's being made by risk management people who are only interested in a simple way to mitigate risk - it's simply much easier for them to reach for an obvious and easily testable policy with character counts, expiry, no autocomplete, etc. Even if you manage to convince one of them to accept something a little more forward-thinking and less user-hostile, it's only a matter of time before Big Customer X comes along with their antiquated requirements and you have to choose between doing what they want or losing that business.
- patrickdward 4y ago
  sad but this is too true
- MaxGabriel 4y ago
  You might be able to appeal to NIST standards, which now recommend against some of the bad practices like special characters.
  - Obscurity4340 4y ago
    Why are special characters bad practice? Wouldn't they increase the entropy better than numbers?
  - BlueTemplar 4y ago
    I have had trouble convincing people before, would you happen to have a link ?
    - deleted 4y ago
      [deleted]
    - lelandfe 4y ago
      https://pages.nist.gov/800-63-3/sp800-63b.html#memsecret https://pages.nist.gov/800-63-3/sp800-63b.html#memsecret They refer to it as a “Memorized Secret“. The appendix, “Strength of Memorized Secrets” is informative rather than a guideline, but I would recommend quoting it too in such discussions: > composition rules, which require the user to choose passwords constructed using a mix of character types, such as at least one digit, uppercase letter, and symbol. However, analyses of breached password databases reveal that the benefit of such rules is not nearly as significant as initially thought… although the impact on usability and memorability is severe
Zamicol 4y ago
Passwords should just be random numbers, and services should provide a suggested password on the sign up pages. Here's a 128 bit password: CR4EOJ5ZYQRKCGQV4OLN2ZRFS. Better than all that is public key authentication.
- pontilanda 4y ago
  Unfortunately there are so many ideas that will "never" gain ground. People are still stuck with the user/password paradigm and it will take some serious push to move to something like Passkeys, which is obviously the best if implemented correctly (i.e. provide a fallback when using a non-own device) We need a push like it happened for HTTPS, which became widespread in less than a decade, but that basically means Google has to push for it.
lapcat 4y ago
> when trying to login, the "enter your password" field isn't got the same limitations, and you cannot login because you're using the wrong (too-long) password > You cannot paste into this field If I may self-promote, my web browser extension StopTheMadness solves both of these problems. https://underpassapp.com/StopTheMadness/ https://underpassapp.com/StopTheMadness/
aidenn0 4y ago
GPG just complained about my 40+ character passphrase because it didn't contain a number.
Zamicol 4y ago
Password strength is: Unknown entropy - known entropy = password strength Where "unknown" entropy is known only to the user and service and "known" entropy is any entropy known by a third party. Since this is an information problem, it should be treated with the tools of information theory, where security is measured by "unknown" entropy. Services have no way to know if a provided string is entropic, since it may be 100% "known" by others. The only way for a service to verify that a password is secure is for the password to include entropy provided by the service. If the user also wanted to validate entropy, it too could provide entropy for mixing in. This is just a special case of Kolmogorov complexity, and the highest algorithmic entropy for this problem is a random number.
- water-your-self 4y ago
  3 //chosen by dice roll
  - Tildey 4y ago
    “Your assigned password will be two random words and 2 random numbers” “Pass”, “word”, “12”, “34”
    - Dylan16807 4y ago
      It's worth getting a list of the most common passwords and rejecting them, regardless of whether the passwords are generated by machine or by the user. For four digit numbers there's barely any variation in what people use. Even 1234, the most common, is only twice as likely as hundreds of other PINs. Maybe block the top half a percent of most-guessed pins.
- quickthrower2 4y ago
  Some banks so this: you need an id (not your account number), a password you chose and a code the bank gave you when you signed up
water-your-self 4y ago
Rotating passwords is an old idea but mathematically it does reduce the probability of bring compromised. Otherwise I can know for certain when something is not your password each time I get it wrong.
- Someone1234 4y ago
  > Rotating passwords is an old idea but mathematically it does reduce the probability of bring compromised. Please can you show your work. Most websites limit the attempts per user per time, which should make direct request break-ins unrealistic to mathematically impossible. So now we move the needle to "Your user database has been stolen, someone is trying to break hashed + salted passwords" which is such a problematic scenario for so many other reasons (e.g. unencrypted password recovery information stolen, PII stolen, and social engineering information verification info stolen) that rotating user's passwords weeks-months later is such wishful thinking. Like, I legitimately don't get it. It was created in the late 1980s by people who just did what sounded right, and we've been stuck with it for over thirty years because change it hard.
  - pontilanda 4y ago
    Your assumption is that there's zero time between a leak and the abuse. If my password reaches the abuser after it expires, then I have been saved by the rotation. Also rotation + "no reuse" policy essentially guarantees that eventually the password will be unique and not reused across services. Side note: I despise rotation as much as the next guy, but I can see the value in it. If users used password managers, generated passwords and not reused passwords, then we wouldn't need such rules. But alas 1234567890 is a common password.
    - Someone1234 4y ago
      > Your assumption is that there's zero time between a leak and the abuse. If my password reaches the abuser after it expires, then I have been saved by the rotation. Nope, that wasn't my assumption. What I said above applies there equally. > Also rotation + "no reuse" policy essentially guarantees that eventually the password will be unique and not reused across services. No it doesn't, in fact it increases password reuse and results in pattern-style passwords.
niscocity35 4y ago
You can avoid brute force attacks by rate-limiting password guesses.
jamujamu 4y ago
There are only really two types of passwords: Passwords for online accounts and passwords used to encrypt things. Imagine the password for my Gmail is Watermelon45. Theory says that's super weak, but I'm not a watermelon farmer and I wasn't born in 1945 so nobody who knows me is ever going to guess it. I trust Google will effectively block against brute force attacks by rate limiting login attempts, and if Google is breached and the password cracked as long as I'm not reusing it somewhere else it doesn't matter. Now if I encrypt my portable SSD with the same password that is a problem. It would be trivial to brute force. So external storage, computer logins, ssh keys are perhaps examples of the very few situations where high entropy passwords are actually useful. For everything else which is 95% of passwords, easy to remember but unique is fine.
- alanfranz 4y ago
  > Now if I encrypt my portable SSD with the same password that is a problem. It would be trivial to brute force. Probably not so trivial. It's very likely (disclosure: I'd need to check, but I'd expect that to be true in 2022) that the actual encryption key of your storage is a randomly-generated key, which is then protected with your password and a very slow decryption algorithm, so that bruteforcing is not so fast. Still, single dictionary word + two ciphers won't be terribly hard to decrypt for a really interested party. But the point is that such attack requires physical access to your device (unless some other network hack is performed), which is a kind of 2FA.
bruce511 4y ago
The article is correct, most password policies are dumb. But it's arguing about one tree while standing in a forest. The real problem with passwords is not individual policies, but rather their shere volume. In my password manager I noticed I have got literally hundreds of the things. Clearly reusing a password on multiple systems is bad. Clearly memorizing more than a handful is impossible. Since I therefore am using a password manager anyway, I simply get it to generate long, random, strings. Which inevitably contain enough to satisfy most daft policies. There are some I still type. Basically the ones I use everyday, like machine login, but 99% are generated. I get the article, and for those everyday passwords I advocate the same - make it long, make it easy to type, don't change it. But if a Web-site wanted to be really secure, require a password manager. (how? I've no idea...)
- toomuchtodo 4y ago
  > But if a Web-site wanted to be really secure, require a password manager. (how? I've no idea...) https://passkeys.dev/ https://passkeys.dev/
- nigerianbrince 4y ago
  Our computers should have a specific port for a physical key which we would carry around in our keychain.
  - taeric 4y ago
    And what do you do when your key is broken or lost? Because that will happen.
    - quickthrower2 4y ago
      Backups! Copy of key at friends house.
      - mr_mitm 4y ago
        So that the friend, or someone who steals from the friend can impersonate me? Proving your identity when you lost your proof of identity is still an unsolved problem if you ask me. At least in general, it seems that there is no one solution that works for everyone.
vxNsr 4y ago
My understanding is that most password policies are set by validation orgs to get certs like ISO. Those orgs are notoriously bad at most things aside from making useless checklists.
JimDabell 4y ago
> There's no technical reason for restricting any character from appearing in any password. The usual approach for handling a password is: > - encode with a specific, well-defined encoding (e.g. utf-8) Heads up – this is not enough for reliable operation. The same character from an end-user’s perspective can be encoded in multiple ways in UTF-8. So they might register with one platform and then a while later log in with a different platform, and you might receive different string data for their password even though they typed the same thing in both cases. You might want to consider following RFC 5198 which has more specific requirements, such as encoding to normalisation form C to eliminate issues like this: https://www.rfc-editor.org/rfc/rfc5198 https://www.rfc-editor.org/rfc/rfc5198
- alanfranz 4y ago
  That’s correct. It’s quite a detail in this case, though; this high level description tries to explain why you should never forbid some “special” chars. Please note that it’s not the same char; it’s actually a different set of code points which happen to have the same representation. I’ll update the article nevertheless.
- cm2187 4y ago
  Likewise the hex of a 128bit key is unbreakable but will fail almost every password policy becuse of repeated characters and lack of upper case/special characters. Though for accentuated characters, I can think of some scenarios where it is not a good idea. Say your users may have to travel / use some terminals. If the keyboard doesn't have those characters, you locked them out of the system. That's why I think non ascii characters aren't a good idea. Also you make yourself more exposed to developers doing something silly like mixing string encoding between different interfaces.
teeray 4y ago
I have accepted that these sites aren’t going to change their ways. What I’d like though is direct integration with my password manager. Communicate whatever Byzantine password requirements you have via some standard hidden fields or meta tags so my password manager will generate only compliant passwords.
- gpmcadam 4y ago
  yep this is the way forward, ideally with something like the proposed passwordrules attribute https://github.com/whatwg/html/issues/3518 https://github.com/whatwg/html/issues/3518
deleted 4y ago
[deleted]
rspk 4y ago
Relevant: https://github.com/duffn/dumb-password-rules https://github.com/duffn/dumb-password-rules
zahma 4y ago
I often get irritated by formulaic instructions for "strong" passwords when creating an account. I use a respectable password manager, so everything is unique and at least 10-15 characters with some numbers and symbols mixed in. Occasionally I use DiceWare. God forbid I don't include a number or use upper case, lower case, one of five symbols, but not th#t one! The worst is when I cannot copy and paste in both text fields. I don't even know what the assumption is there about end user behavior, but it's quite frustrating. I know these practices must be reduced to the lowest common denominator, but perhaps websites need to allow minimum entropy and not force rules unless the minimum entropy isn't met. I don't know much about implementing, but people are so lazy that all these different rules and schemes are turn offs from better security practices.
johnnyApplePRNG 4y ago
I came across the most humorous password entry view blocking scenario on a firestick trying to login to netflix the other day. You are visually moving the cursor around a graphically displayed keyboard... pressing enter when you are on the letter or number desired, at which point the hidden password entry form immediately increases by 1 in length. Hrmmm... I wonder what that character was?!?
- TacticalCoder 4y ago
  > You are visually moving the cursor around a graphically displayed keyboard A bank in France, "Societe Generale de Banque" still shows me a little visual keyboard (with digits only). The digits are shuffled. Then it's similar: I need to hover the digit I want to pick, click, it blinks, then the hidden password entry increase by one. Repeat 5 more times. I can then wire up to 100 K EUR if I want. Insanity. Now, to be honest, all my other banks in Europe are using an actual hardware 2FA which they sent me.
lamontcg 4y ago
Where this came from is stuff like the DES crypt implementation where passwords were truncated at 8 characters and then 7 bits were extracted to form a 56 bit DES key. You simply couldn't have long passwords back then. The first widespread crypt implementation that could handle long passwords was probably PHKs MD5 based scheme in 1995 -- contemporaneously around the release of Netscape Navigator. If you only had 8 characters then you needed to include multiple different character types and needed to not use dictionary words. So for the early internet those became the standard recommendation until long-password-supporting crypt()s became standard in operating systems. Having gone through a decade-ish of those password standards in the 90s by the time all the operating systems had updated their crypt() standards a lot of people didn't really notice until the xkcd comic in 2010. And now you've just got to fight 30-ish years of inertia of those being considered the standard.
professorTuring 4y ago
I lead Security in a quite large bank. I love this article, I’ve been advocating for this line of thoughts for more time that I can remember. I have spoken to regulators hundreds of times, over this and a bunch other security topics that are definitely obsolete. Security policies that just don’t make sense… The most important thing for this kind of things to advance is to have the correct people in the correct places, and usually in this positions you have dinosaurs…
- TacticalCoder 4y ago
  > I lead Security in a quite large bank. In most of my banks in Europe, all but one, I cannot log without using an actual physical 2FA device the bank sent me. One of them, Deutsche Bank, sent me a specific hardware 2FA which works "by itself" (and is protected by a PIN). No password to log in: only the user account ID and that 2FA device. The others require my Java SmartCard / national ID card to be inserted in a 2FA reader they sent me (it's a standalone reader with its own display: it is not a Java SmartCard reader hooked to the computer). Do you guys hand out your customers physical 2FA devices?
  - professorTuring 4y ago
    Not anymore, we used to do that and maybe a bunch of customers still have that device to log in, but we have been replacing them (the “hard token”) with a “soft token”, kind of a Google Authenticator linked to your mobile. It is interesting how “yubi”things have moved in the opposite direction (back to the physical device) and it has its value, after all, leaving your home with all your savings in your pocket is a risk we need to address.
allarm 4y ago
> You cannot enter a password with more than X chars And this is the most infuriating thing, especially when the lowest limit is say 8 chars and the highest is something like 12. I get the point that there should be some limit - 64 chars for instance - but limiting the password length to anything less than that is just dumb.
jpalomaki 4y ago
Slightly related (funny, for me) thing I came across recently. I was looking into why some orgs prevent you from changing the Windows domain password if it has been changed less than 24h ago. Turns out there's a reason for this: "Setting the number of days to 0 allows immediate password changes. This setting isn't recommended. Combining immediate password changes with password history allows someone to change a password repeatedly until the password history requirement is met and re-establish the original password again." [1] [1] https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/minimum-password-age https://learn.microsoft.com/en-us/windows/security/threat-pr...
- rwmj 4y ago
  In other words, someone worked out a way to work around our user- and security-hostile password policy and we can't allow that.
makach 4y ago
Your passwords are safe as long as you have done your part, i.e. followed best practice on how to set up your passphrase for accessing your information. LastPass implemented a system that is durable, as long as your HW is not compromised or you are somehow duped into giving away your password you should expect your passwords to be safe. If you are worried, change your passphrase in accordance with best practice and you should be fine. Breaches will happen, their architecture saves your data - but that means we have to do our part and follow recommended process/practice.
- alanfranz 4y ago
  Did you just comment on the wrong article?
  - makach 4y ago
    Yes! My addiction so visible , how embarrasing!
rwmj 4y ago
It's a good article, but ... > You cannot use whitespace, accented letters, hyphens, [...] in your password When test-installing Fedora I use a password which contains some shift number key characters with my UK keyboard. It's a very good test of whether the keyboard encoding is set up correctly in all the places that take passwords. Usually at least one place is set to US keyboard, whatever the user preference. A password containing, for example @, could cause weird log-in issues later, assuming you're not using a password manager which of course you should be.
dspillett 4y ago
> You cannot enter a password with more than X chars I've seen this from banks, for access to my money & credit... Both FirstDirect and HSBC used to have a 9 character password for their "digital secure key"s (basically their apps on my phone, in the direct use use-case). 9. Just 9. Though at least alpha-numeric & case-sensitive, so some room for reasonable entropy. Worse: for some reason HSBC recently changed theirs to 6 numeric characters. 6. Numeric only. And while forcing me to change, they repeatedly assured me that this was just as secure as before… Luckily for me all I have with them currently is a mortgage that I'll be paying off in (checks calendar) a week and a half, at which point the whole lot gets closed and they can make it a two digit PIN for all it'll affect my financial security! (UK here, not sure if they have different restrictions in different territories but I suspect not)
- grishka 4y ago
  I'm absolutely sure banks store passwords in plaintext more often than not. But then one particular bank takes the cake. There, I have: - The usual login + password, the password length is limited of course - The "secret questions" to confirm some actions. In reality these are just three extra passwords - The code generator in the mobile app to confirm some other actions, for access to which you need a 4-digit pin code Another bank is much more sensible in this regard but requires me to change my password every year. I hate it with a burning passion when there's any time component at all in user authentication.
- _dain_ 4y ago
  >Worse: for some reason HSBC recently changed theirs to 6 numeric characters. 6. Numeric only. And while forcing me to change, they repeatedly assured me that this was just as secure as before… Luckily for me all I have with them currently is a mortgage that I'll be paying off in (checks calendar) a week and a half, at which point the whole lot gets closed and they can make it a two digit PIN for all it'll affect my financial security! I'll one-up you: Nationwide requires six numeric characters, which you have to enter via one 0-9 dropdown menu per digit, and you only have to enter three per login. i.e. if your "passcode" is 987654, then it will randomly choose only three of those for you to enter, like _?_??_ where you'd only have to put in 8, 6, and 5. So it's clearly stored in plaintext. And they have 2FA, but as you might expect, it's SMS only. And their online banking site is garbage, some links just always timeout and log me out. Is there a single UK bank that has the following two features: 1) lets me pick a sane password and has non-SMS 2FA, 2) has an online banking interface that works on desktop browsers. The second one is important to me because I never want to do banking on my phone. Last time I checked, the "challenger banks" like Monzo only have phone options.
davedx 4y ago
I stopped reading at the password length isn’t password strength part. This goes against NIST guidelines and is opinion. Just follow NIST password guidelines guys.
- alanfranz 4y ago
  This is an explanation and reasoning. It’s designed to make people think about policies and scenarios, and not to blindly apply random suggestions. What is against NIST guidelines? The length argument works both ways: just as a purely lowercase alphabetic password, if long enough, is safe, a very short (in term of code points) password with full unicode spectrum can be safe as well.
bigbacaloa 4y ago
I thought the one capital, one strange character, at least 8 characters, etc. policies were mainly so that whoever programs the web page can later claim to have taken proper measures when the site gets hacked.
TacticalCoder 4y ago
> The usual approach for handling a password is: take the password as a string, as the user typed it. Ah. That usual approach, where any rogue employee or anyone really snooping on either side of the connection before/after the TLS gets to see the plaintext password. Makes me wonder: is salted challenge response authentication (RFC5802 and 7804) getting any traction? Couchbase is (was?) using that. Is there a list of websites that went past what's basically the nineties' "plaintext password over SSL"?
- alanfranz 4y ago
  I didn’t know that rfc, but afaik the usual way is what I’ve written. Will take a look at that,btw. Looks interesting.
sandos 4y ago
My company recently switched to something probably inspired by the NIST standard. We are supposed to have a unique password, that never expires. The "problem" is that we are now required to use 2-factor basically every time we sign in instead, which is annoying, and the login also times out way too fast of course. Previously I could be logged in for days? Now its hours and I need to then use my phone to log in. (I only work remotely, but being a firm of contractors its what most of us do.)
gtirloni 4y ago
>You waste a lot of time at generating a "strong password" that complies with a website's policy I let my password manager do it and don't bother with it any time soon.
- alanfranz 4y ago
  But your generated password contains "-", and that's not accepted by the website. How can you not bother?
  - throwawaaarrgh 4y ago
    Password manager password generators have a simple UI you can click to select the password format required by the form. Or just click 'generate' again and try each until one works.
    - alanfranz 4y ago
      So, you need to bother, either to reverse-engineer the site requirements, or to try until it works. For no good reason, as explained in the article.
e12e 4y ago
I recall a talk at passwordcon by Per Thorsheim where he pointed out that not only does the password: "Password2022" meet most "strict" criteria (three different character classes, longer than eight characters) - and -it's amenable to yearly demands for changing (increase the year) - but in large organizations you're actually very likely to find a user or two with this password (as seen in audits that ran simple brute force against the user directory). PS: in the rare case it's not "secure" enough, add an exclamation point: "Password2022!"
- alanfranz 4y ago
  One good complexity check would be “contains a single dictionary word as the main content.” I don’t know if library does it, though.
  - deleted 4y ago
    [deleted]
  - throwoutway 4y ago
    Why is this a good complexity check?
    - alanfranz 4y ago
      Because dictionary attacks are easy on single words + small mutations, like some capitalizations and adding 1-2 digits.
satvikchoudhary 4y ago
I guess this post made an impact on me. Earlier I was using the policy of Upper, lower, special characters but now using zxcvbn. https://zxcvbn-ts.github.io/zxcvbn/ https://zxcvbn-ts.github.io/zxcvbn/ Much thanks to the creators and maintainers. It only took me 5 minutes for the whole thing.
throwawaaarrgh 4y ago
> please allow long passwords at least 64 chars long; even 256 should pose no DoS risk whatsoever With a very large user database, a 256 char entry field would really start to add up, wouldn't it? iirc the DB takes up that room whether it's fully used or not. Size affects not just disk but also bandwidth, memory, cpu, and has an overall effect on system performance
- ratboy666 4y ago
  Please do not store the password... store a hash.
- alanfranz 4y ago
  The hash is constant length regardless of input size. DoS is on processing power.

283 points by alanfranz 4y ago

The best solution to password requirements is to eliminate passwords altogether. Passwords are the most problematic and weakest authentication factor we have. Instead, let’s authenticate with PKI. It works.

pvorb 4y ago

> Or maybe the keyboard layout isn't yet set when the password is entered (example: full disk encryption password at boot) and you risk that a user is entering a password at install time, but what they write at boot is actually different. This is a very good point, which already made me struggle when setting up new computers. For instance, the Ubuntu installer runs in a Gnome environment with my keyboard layout active. The disk encryption prompt runs shortly after the BIOS screen and will likely have some US keyboard layout. If you choose anything special for your password, you'll have a hard time figuring out how to type it in a different keyboard layout.

SAI_Peregrinus 4y ago
It's just another thing to remember to set. The keyboard layout CAN be set at boot (I do it), but it's separate from the keyboard layout in a graphical session.
lucb1e 4y ago
I work for a German company. You bet that I know to find most symbols on a German keyboard layout. Thankfully the base letters contain only one swap. For extra fun, one colleague in particular likes to set excessively long passwords of like 50 characters when it is not expected that anyone will ever have to type them. The number of times I had to type one of these because this sysadmin works remotely and I'm the hands in the office when needed...
Avamander 4y ago
Ubuntu and probably others set the correct keyboard layout for even GRUB itself, not to mention Linux, so it's fine. Windows is probably worse, it doesn't even let you remove other layouts.

galangalalgol 4y ago

For judging complexity I always thought large businesses should just set aside some compute to try to brute force passwords with the hash. If they get yours, you have to change it and get a talking to. If they can't get it, they give you $X where X is big enough to be a pleasant surprise.

kccqzy 4y ago
Idea: just run a standard compression algorithm on the password and measure its length.

anewguy9000 4y ago

yep, most of the discussion about passwords completely miss the point. a random word, like "dog" or "pingpong" is fine if the pqsswords are salted and hashed appropriately. how often have your accounts been hacked this way? if an adversary is really banging on the hash, and they want it, any password under around 50 characters is as good as "dog", and no "complexity" meter is gona cut it. that xkcd comic that says 550 years? no, that password its owned a lot a faster than that. all this talk of entropy and security but so obviously clueless about modern brute force techniques

lucb1e 4y ago
> most of the discussion about passwords completely miss the point. [...] any password under around 50 characters is as good as "dog" I think you've completely missed the point. After how long do you start to get annoyed when logging in? Most people probably at 2-5 seconds, but let's say ten full seconds of waiting for the computer to do the hashing. A word like dog is among the top few thousand words, let's say ten thousand, so after 10k×10s/(3600 seconds per hour) = ~28 hours your password is cracked on a single cpu. Probably more like 28 minutes on a couple GPUs, and this is using a complexity setting that literally nobody is going to use (I bet even the NSA isn't paranoid enough to wait 10 seconds for every login). Now compare that to "any other password under around 50 characters". If you want to use a passphrase, pick random words (at least five when using complex words; the number depends on your dictionary size). Not a single word that is also very common. That completely misses the point. This strategy would work if literally everyone uses a random words generator and yours, against all odds, comes up with a single common word. Then attackers would have no reason to crack in order of commonness and start with a single word. But that is not the reality we live in and attackers do start with simple passwords before complex ones. (Source: one of the things we do at work is crack passwords, most commonly when we get our hands on Windows password hashes.)
- anewguy9000 4y ago
  im sorry, what point are you making? if its that "dog" is a weak password, i thought that was evident. but many people seem confused that "horseloverwhatever" is more secure, similarly that "dog23!Wog" is more secure. my point is they are equally trash so leave the user alone

janalsncm 4y ago

> A short password is easy to bruteforce. But, a website should aim at password strength, not at password length. Is there a standard metric for “strength” though? I built my own random password generator and considered adding a strength meter but all of the functions I could find online seemed like they had pretty arbitrary logic. Length is probably the most objective proxy for strength.

chadlavi 4y ago
The author links to a recommended library in the blog post https://github.com/dropbox/zxcvbn https://github.com/dropbox/zxcvbn
- lucb1e 4y ago
  I was looking, last week, what to recommend to a customer and ended up at https://github.com/zxcvbn-ts/zxcvbn https://github.com/zxcvbn-ts/zxcvbn because the one from Dropbox seems to be completely abandoned and does not recognize e.g. 2020 as a year. Other alternatives are also welcome if there is an even better one I missed! This was the best password strength estimator I could find.
cirrus3 4y ago
Check out https://www.grc.com/haystack.htm https://www.grc.com/haystack.htm
- LeoPanthera 4y ago
  This particular tool is misleading at best. It counts only characters, and so misleadingly overrates passwords which are strings of words. Compare it with this one, which actually identifies words and other patterns, for a more accurate guess of the search space: https://www.bennish.net/password-strength-checker/ https://www.bennish.net/password-strength-checker/
  - cirrus3 4y ago
    I only said check it out, there is a lot of content there useful to the wider topic and the page clearly states what it is and isn't. >>> IMPORTANT!!! What this calculator is NOT . . . It is NOT a “Password Strength Meter.” Since it could be easily confused for one, it is very important for you to understand what it is, and what it isn't: The #1 most commonly used password is “123456”, and the 4th most common is “Password.” So any password attacker and cracker would try those two passwords immediately. Yet the Search Space Calculator above shows the time to search for those two passwords online (assuming a very fast online rate of 1,000 guesses per second) as 18.52 minutes and 17.33 centuries respectively! If “123456” is the first password that's guessed, that wouldn't take 18.52 minutes. And no password cracker would wait 17.33 centuries before checking to see whether “Password” is the magic phrase. Okay. So what IS the “Search Space Calculator” ? This calculator is designed to help users understand how many passwords can be created from different combinations of character sets (lowercase only, mixed case, with or without digits and special characters, etc.) and password lengths. The calculator then puts the resulting large numbers (with lots of digits or large powers of ten) into a real world context of the time that would be required (assuming differing search speeds) to exhaustively search every password up through that length, assuming the use of the chosen alphabet. How can I apply this to my daily life? Answering that question is the reason this page exists. The whole point of using padded passwords is to adopt a much more you-friendly approach to password design. On June 1st, Leo Laporte and I recorded our weekly Security Now! podcast as part of Leo's TWiT.tv (This Week in Tech) audio and video podcasting network. You may download a shortened, 37-minute, excerpted version presenting the padded password and Haystack calculator concepts:

joezydeco 4y ago

My favorite is this transaction: I forgot my password. Can you send me a link? Sure, here you go. Pick a new password. Okay, CorrectHorseBatteryStaple. Sorry, you can't use an old password

danrocks 4y ago
Funny, sure. But you still can have the same transaction by hashing "CorrectHorseBatteryStaple" then comparing with the stored hash.
- the_af 4y ago
  I think the OP is arguing you can guess a (possibly) current password this way.
  - qup 4y ago
    Only if you guess it on the first attempt.
  - joezydeco 4y ago
    I'm just amused by the irony of forgetting my password, going through the reset process, then realizing I did remember my password. Except now I can't use it any more.
    - zargon 4y ago
      Does it not let you log in with your old password after requesting a password change? That seems even more problematic, since anyone can request you password be changed.
      - joezydeco 4y ago
        Sometimes it does, sometimes it doesn't. More annoyances.
cirrus3 4y ago

regularjack 4y ago

Off-topic but not sure having a patronizing cookie banner is the best strategy.

alanfranz 4y ago
It’s a very old banner, I didn’t mean for it to be patronizing, just to mock the absurd cookie law which had just passed. I’m trying to go cookieless, actually, I hope to finish someday, Google Analytics was removed already. I’ll need to ask for explicit authorization for disqus commenting only.
alanfranz 4y ago
Cookies and banner have been removed!

lucb1e 4y ago

> A short password is easy to bruteforce. But, a website should aim at password strength, not at password length. If it is "easy to bruteforce" (guess without any prior knowledge), then it is not "strong". > If I use four unicode code points outside the [multi-language characters table], my password is probably very safe already. Security through obscurity. This is safe until everyone does it. It's not a strong password by virtue of being short, it's strong because this is impossible to input and so nobody uses it and so it doesn't make sense to guess. But you bet that if you ever log into a compromised system, use a phishing page, or a site stores and loses your password in plain text, the gig is up and it's known that cracking u/alanfranz's passwords is a matter of trying a few random unicode characters instead of letters. > You cannot show or copy this field [...] My verdict: Security through obscurity Security through obscurity is it being secure by being rare. It's not about it being literally invisible. I agree with the point but this is not what obscurity means. Most of this post makes sense (password expiry, maximum length, requiring special symbols, disallowing other symbols) but we've known these things for decades now. We keep putting it in reports and customers are slowly catching up. Recently saw the first customer who, in a retest, used a reasonably sized deny list of common passwords on an embedded device! I was definitely impressed. We're getting there, ever so slowly.

alwayslikethis 4y ago
> > If I use four unicode code points outside the [multi-language characters table], my password is probably very safe already. > Security through obscurity. This is safe until everyone does it. It's not a strong password by virtue of being short, it's strong because this is impossible to input and so nobody uses it and so it doesn't make sense to guess. But you bet that if you ever log into a compromised system, use a phishing page, or a site stores and loses your password in plain text, the gig is up and it's known that cracking u/alanfranz's passwords is a matter of trying a few random unicode characters instead of letters. This is plain wrong. The Basic Multilingual Plane consists of 65536 most commonly used codepoints. If your password contains a character outside of the BMP (e.g. an emoji), the attacker has to be bruteforcing over at least one other plane in addition to the BMP, which is 2*65536 characters = 17 bits of entropy per character. 4*17 = 68 bits of entropy is plenty. Even if everyone included an emoji in their passwords, this won't become any weaker.

chordalkeyboard 4y ago

there is also a disconnect between password requirements and automatically generated passwords, where often the auto-generated password contains prohibited characters.

cirrus3 4y ago

Password managers are "obviously" the solution - in my experience they generate good passwords that are accepted almost all the time now days. However, I still think 3rd-party password managers are too complex for many people, and those people are the ones who need them most. OS-level password management is a bit easier but not great. Browser native password managers are a terrible idea IMO, for people who can't handle a 3rd party manager, imagine their confusion when only a specific browser knows their password, and only when they signed into their browser vendor account.

pontilanda 4y ago
The interoperability boat has sailed. macOS has had an open Keychain for decades and Google eventually dropped support for it. I don't see them suddenly going back, sharing efforts and allowing cross compatibility. What we need is just passwords to come front and center anywhere they are: We need a Password.app that I can open and access all I need. Keychain Access was exactly that but its UI is stuck in 2000.

deleted 4y ago

[deleted]

_dan 4y ago

In the b2b world it's basically impossible to improve password policies. Most of the onerous examples only exist because some other entity (a customer, insurance company, parent company, etc) has demanded them. The problem is that the demand isn't being made by security professionals, it's being made by risk management people who are only interested in a simple way to mitigate risk - it's simply much easier for them to reach for an obvious and easily testable policy with character counts, expiry, no autocomplete, etc. Even if you manage to convince one of them to accept something a little more forward-thinking and less user-hostile, it's only a matter of time before Big Customer X comes along with their antiquated requirements and you have to choose between doing what they want or losing that business.

patrickdward 4y ago
sad but this is too true
MaxGabriel 4y ago
You might be able to appeal to NIST standards, which now recommend against some of the bad practices like special characters.
- Obscurity4340 4y ago
  Why are special characters bad practice? Wouldn't they increase the entropy better than numbers?
- BlueTemplar 4y ago
  I have had trouble convincing people before, would you happen to have a link ?
  - deleted 4y ago
    [deleted]
  - lelandfe 4y ago
    https://pages.nist.gov/800-63-3/sp800-63b.html#memsecret https://pages.nist.gov/800-63-3/sp800-63b.html#memsecret They refer to it as a “Memorized Secret“. The appendix, “Strength of Memorized Secrets” is informative rather than a guideline, but I would recommend quoting it too in such discussions: > composition rules, which require the user to choose passwords constructed using a mix of character types, such as at least one digit, uppercase letter, and symbol. However, analyses of breached password databases reveal that the benefit of such rules is not nearly as significant as initially thought… although the impact on usability and memorability is severe

Zamicol 4y ago

Passwords should just be random numbers, and services should provide a suggested password on the sign up pages. Here's a 128 bit password: CR4EOJ5ZYQRKCGQV4OLN2ZRFS. Better than all that is public key authentication.

pontilanda 4y ago
Unfortunately there are so many ideas that will "never" gain ground. People are still stuck with the user/password paradigm and it will take some serious push to move to something like Passkeys, which is obviously the best if implemented correctly (i.e. provide a fallback when using a non-own device) We need a push like it happened for HTTPS, which became widespread in less than a decade, but that basically means Google has to push for it.

lapcat 4y ago

> when trying to login, the "enter your password" field isn't got the same limitations, and you cannot login because you're using the wrong (too-long) password > You cannot paste into this field If I may self-promote, my web browser extension StopTheMadness solves both of these problems. https://underpassapp.com/StopTheMadness/ https://underpassapp.com/StopTheMadness/

aidenn0 4y ago

GPG just complained about my 40+ character passphrase because it didn't contain a number.

Zamicol 4y ago

Password strength is: Unknown entropy - known entropy = password strength Where "unknown" entropy is known only to the user and service and "known" entropy is any entropy known by a third party. Since this is an information problem, it should be treated with the tools of information theory, where security is measured by "unknown" entropy. Services have no way to know if a provided string is entropic, since it may be 100% "known" by others. The only way for a service to verify that a password is secure is for the password to include entropy provided by the service. If the user also wanted to validate entropy, it too could provide entropy for mixing in. This is just a special case of Kolmogorov complexity, and the highest algorithmic entropy for this problem is a random number.

water-your-self 4y ago
3 //chosen by dice roll
- Tildey 4y ago
  “Your assigned password will be two random words and 2 random numbers” “Pass”, “word”, “12”, “34”
  - Dylan16807 4y ago
    It's worth getting a list of the most common passwords and rejecting them, regardless of whether the passwords are generated by machine or by the user. For four digit numbers there's barely any variation in what people use. Even 1234, the most common, is only twice as likely as hundreds of other PINs. Maybe block the top half a percent of most-guessed pins.
quickthrower2 4y ago
Some banks so this: you need an id (not your account number), a password you chose and a code the bank gave you when you signed up

water-your-self 4y ago

Rotating passwords is an old idea but mathematically it does reduce the probability of bring compromised. Otherwise I can know for certain when something is not your password each time I get it wrong.

Someone1234 4y ago
> Rotating passwords is an old idea but mathematically it does reduce the probability of bring compromised. Please can you show your work. Most websites limit the attempts per user per time, which should make direct request break-ins unrealistic to mathematically impossible. So now we move the needle to "Your user database has been stolen, someone is trying to break hashed + salted passwords" which is such a problematic scenario for so many other reasons (e.g. unencrypted password recovery information stolen, PII stolen, and social engineering information verification info stolen) that rotating user's passwords weeks-months later is such wishful thinking. Like, I legitimately don't get it. It was created in the late 1980s by people who just did what sounded right, and we've been stuck with it for over thirty years because change it hard.
- pontilanda 4y ago
  Your assumption is that there's zero time between a leak and the abuse. If my password reaches the abuser after it expires, then I have been saved by the rotation. Also rotation + "no reuse" policy essentially guarantees that eventually the password will be unique and not reused across services. Side note: I despise rotation as much as the next guy, but I can see the value in it. If users used password managers, generated passwords and not reused passwords, then we wouldn't need such rules. But alas 1234567890 is a common password.
  - Someone1234 4y ago
    > Your assumption is that there's zero time between a leak and the abuse. If my password reaches the abuser after it expires, then I have been saved by the rotation. Nope, that wasn't my assumption. What I said above applies there equally. > Also rotation + "no reuse" policy essentially guarantees that eventually the password will be unique and not reused across services. No it doesn't, in fact it increases password reuse and results in pattern-style passwords.

niscocity35 4y ago

You can avoid brute force attacks by rate-limiting password guesses.

jamujamu 4y ago

There are only really two types of passwords: Passwords for online accounts and passwords used to encrypt things. Imagine the password for my Gmail is Watermelon45. Theory says that's super weak, but I'm not a watermelon farmer and I wasn't born in 1945 so nobody who knows me is ever going to guess it. I trust Google will effectively block against brute force attacks by rate limiting login attempts, and if Google is breached and the password cracked as long as I'm not reusing it somewhere else it doesn't matter. Now if I encrypt my portable SSD with the same password that is a problem. It would be trivial to brute force. So external storage, computer logins, ssh keys are perhaps examples of the very few situations where high entropy passwords are actually useful. For everything else which is 95% of passwords, easy to remember but unique is fine.

alanfranz 4y ago
> Now if I encrypt my portable SSD with the same password that is a problem. It would be trivial to brute force. Probably not so trivial. It's very likely (disclosure: I'd need to check, but I'd expect that to be true in 2022) that the actual encryption key of your storage is a randomly-generated key, which is then protected with your password and a very slow decryption algorithm, so that bruteforcing is not so fast. Still, single dictionary word + two ciphers won't be terribly hard to decrypt for a really interested party. But the point is that such attack requires physical access to your device (unless some other network hack is performed), which is a kind of 2FA.

bruce511 4y ago

The article is correct, most password policies are dumb. But it's arguing about one tree while standing in a forest. The real problem with passwords is not individual policies, but rather their shere volume. In my password manager I noticed I have got literally hundreds of the things. Clearly reusing a password on multiple systems is bad. Clearly memorizing more than a handful is impossible. Since I therefore am using a password manager anyway, I simply get it to generate long, random, strings. Which inevitably contain enough to satisfy most daft policies. There are some I still type. Basically the ones I use everyday, like machine login, but 99% are generated. I get the article, and for those everyday passwords I advocate the same - make it long, make it easy to type, don't change it. But if a Web-site wanted to be really secure, require a password manager. (how? I've no idea...)

toomuchtodo 4y ago
> But if a Web-site wanted to be really secure, require a password manager. (how? I've no idea...) https://passkeys.dev/ https://passkeys.dev/
nigerianbrince 4y ago
Our computers should have a specific port for a physical key which we would carry around in our keychain.
- taeric 4y ago
  And what do you do when your key is broken or lost? Because that will happen.
  - quickthrower2 4y ago
    Backups! Copy of key at friends house.
    - mr_mitm 4y ago
      So that the friend, or someone who steals from the friend can impersonate me? Proving your identity when you lost your proof of identity is still an unsolved problem if you ask me. At least in general, it seems that there is no one solution that works for everyone.

vxNsr 4y ago

My understanding is that most password policies are set by validation orgs to get certs like ISO. Those orgs are notoriously bad at most things aside from making useless checklists.

JimDabell 4y ago

> There's no technical reason for restricting any character from appearing in any password. The usual approach for handling a password is: > - encode with a specific, well-defined encoding (e.g. utf-8) Heads up – this is not enough for reliable operation. The same character from an end-user’s perspective can be encoded in multiple ways in UTF-8. So they might register with one platform and then a while later log in with a different platform, and you might receive different string data for their password even though they typed the same thing in both cases. You might want to consider following RFC 5198 which has more specific requirements, such as encoding to normalisation form C to eliminate issues like this: https://www.rfc-editor.org/rfc/rfc5198 https://www.rfc-editor.org/rfc/rfc5198

alanfranz 4y ago
That’s correct. It’s quite a detail in this case, though; this high level description tries to explain why you should never forbid some “special” chars. Please note that it’s not the same char; it’s actually a different set of code points which happen to have the same representation. I’ll update the article nevertheless.
cm2187 4y ago
Likewise the hex of a 128bit key is unbreakable but will fail almost every password policy becuse of repeated characters and lack of upper case/special characters. Though for accentuated characters, I can think of some scenarios where it is not a good idea. Say your users may have to travel / use some terminals. If the keyboard doesn't have those characters, you locked them out of the system. That's why I think non ascii characters aren't a good idea. Also you make yourself more exposed to developers doing something silly like mixing string encoding between different interfaces.

teeray 4y ago

I have accepted that these sites aren’t going to change their ways. What I’d like though is direct integration with my password manager. Communicate whatever Byzantine password requirements you have via some standard hidden fields or meta tags so my password manager will generate only compliant passwords.

gpmcadam 4y ago
yep this is the way forward, ideally with something like the proposed passwordrules attribute https://github.com/whatwg/html/issues/3518 https://github.com/whatwg/html/issues/3518

deleted 4y ago

[deleted]

rspk 4y ago

Relevant: https://github.com/duffn/dumb-password-rules https://github.com/duffn/dumb-password-rules

zahma 4y ago

I often get irritated by formulaic instructions for "strong" passwords when creating an account. I use a respectable password manager, so everything is unique and at least 10-15 characters with some numbers and symbols mixed in. Occasionally I use DiceWare. God forbid I don't include a number or use upper case, lower case, one of five symbols, but not th#t one! The worst is when I cannot copy and paste in both text fields. I don't even know what the assumption is there about end user behavior, but it's quite frustrating. I know these practices must be reduced to the lowest common denominator, but perhaps websites need to allow minimum entropy and not force rules unless the minimum entropy isn't met. I don't know much about implementing, but people are so lazy that all these different rules and schemes are turn offs from better security practices.

johnnyApplePRNG 4y ago

I came across the most humorous password entry view blocking scenario on a firestick trying to login to netflix the other day. You are visually moving the cursor around a graphically displayed keyboard... pressing enter when you are on the letter or number desired, at which point the hidden password entry form immediately increases by 1 in length. Hrmmm... I wonder what that character was?!?

TacticalCoder 4y ago
> You are visually moving the cursor around a graphically displayed keyboard A bank in France, "Societe Generale de Banque" still shows me a little visual keyboard (with digits only). The digits are shuffled. Then it's similar: I need to hover the digit I want to pick, click, it blinks, then the hidden password entry increase by one. Repeat 5 more times. I can then wire up to 100 K EUR if I want. Insanity. Now, to be honest, all my other banks in Europe are using an actual hardware 2FA which they sent me.

lamontcg 4y ago

Where this came from is stuff like the DES crypt implementation where passwords were truncated at 8 characters and then 7 bits were extracted to form a 56 bit DES key. You simply couldn't have long passwords back then. The first widespread crypt implementation that could handle long passwords was probably PHKs MD5 based scheme in 1995 -- contemporaneously around the release of Netscape Navigator. If you only had 8 characters then you needed to include multiple different character types and needed to not use dictionary words. So for the early internet those became the standard recommendation until long-password-supporting crypt()s became standard in operating systems. Having gone through a decade-ish of those password standards in the 90s by the time all the operating systems had updated their crypt() standards a lot of people didn't really notice until the xkcd comic in 2010. And now you've just got to fight 30-ish years of inertia of those being considered the standard.

professorTuring 4y ago

I lead Security in a quite large bank. I love this article, I’ve been advocating for this line of thoughts for more time that I can remember. I have spoken to regulators hundreds of times, over this and a bunch other security topics that are definitely obsolete. Security policies that just don’t make sense… The most important thing for this kind of things to advance is to have the correct people in the correct places, and usually in this positions you have dinosaurs…

TacticalCoder 4y ago
> I lead Security in a quite large bank. In most of my banks in Europe, all but one, I cannot log without using an actual physical 2FA device the bank sent me. One of them, Deutsche Bank, sent me a specific hardware 2FA which works "by itself" (and is protected by a PIN). No password to log in: only the user account ID and that 2FA device. The others require my Java SmartCard / national ID card to be inserted in a 2FA reader they sent me (it's a standalone reader with its own display: it is not a Java SmartCard reader hooked to the computer). Do you guys hand out your customers physical 2FA devices?
- professorTuring 4y ago
  Not anymore, we used to do that and maybe a bunch of customers still have that device to log in, but we have been replacing them (the “hard token”) with a “soft token”, kind of a Google Authenticator linked to your mobile. It is interesting how “yubi”things have moved in the opposite direction (back to the physical device) and it has its value, after all, leaving your home with all your savings in your pocket is a risk we need to address.

allarm 4y ago

> You cannot enter a password with more than X chars And this is the most infuriating thing, especially when the lowest limit is say 8 chars and the highest is something like 12. I get the point that there should be some limit - 64 chars for instance - but limiting the password length to anything less than that is just dumb.

jpalomaki 4y ago

Slightly related (funny, for me) thing I came across recently. I was looking into why some orgs prevent you from changing the Windows domain password if it has been changed less than 24h ago. Turns out there's a reason for this: "Setting the number of days to 0 allows immediate password changes. This setting isn't recommended. Combining immediate password changes with password history allows someone to change a password repeatedly until the password history requirement is met and re-establish the original password again." [1] [1] https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/minimum-password-age https://learn.microsoft.com/en-us/windows/security/threat-pr...

rwmj 4y ago
In other words, someone worked out a way to work around our user- and security-hostile password policy and we can't allow that.

makach 4y ago

Your passwords are safe as long as you have done your part, i.e. followed best practice on how to set up your passphrase for accessing your information. LastPass implemented a system that is durable, as long as your HW is not compromised or you are somehow duped into giving away your password you should expect your passwords to be safe. If you are worried, change your passphrase in accordance with best practice and you should be fine. Breaches will happen, their architecture saves your data - but that means we have to do our part and follow recommended process/practice.

alanfranz 4y ago
Did you just comment on the wrong article?
- makach 4y ago
  Yes! My addiction so visible , how embarrasing!

rwmj 4y ago

It's a good article, but ... > You cannot use whitespace, accented letters, hyphens, [...] in your password When test-installing Fedora I use a password which contains some shift number key characters with my UK keyboard. It's a very good test of whether the keyboard encoding is set up correctly in all the places that take passwords. Usually at least one place is set to US keyboard, whatever the user preference. A password containing, for example @, could cause weird log-in issues later, assuming you're not using a password manager which of course you should be.

dspillett 4y ago

> You cannot enter a password with more than X chars I've seen this from banks, for access to my money & credit... Both FirstDirect and HSBC used to have a 9 character password for their "digital secure key"s (basically their apps on my phone, in the direct use use-case). 9. Just 9. Though at least alpha-numeric & case-sensitive, so some room for reasonable entropy. Worse: for some reason HSBC recently changed theirs to 6 numeric characters. 6. Numeric only. And while forcing me to change, they repeatedly assured me that this was just as secure as before… Luckily for me all I have with them currently is a mortgage that I'll be paying off in (checks calendar) a week and a half, at which point the whole lot gets closed and they can make it a two digit PIN for all it'll affect my financial security! (UK here, not sure if they have different restrictions in different territories but I suspect not)

grishka 4y ago
I'm absolutely sure banks store passwords in plaintext more often than not. But then one particular bank takes the cake. There, I have: - The usual login + password, the password length is limited of course - The "secret questions" to confirm some actions. In reality these are just three extra passwords - The code generator in the mobile app to confirm some other actions, for access to which you need a 4-digit pin code Another bank is much more sensible in this regard but requires me to change my password every year. I hate it with a burning passion when there's any time component at all in user authentication.
_dain_ 4y ago
>Worse: for some reason HSBC recently changed theirs to 6 numeric characters. 6. Numeric only. And while forcing me to change, they repeatedly assured me that this was just as secure as before… Luckily for me all I have with them currently is a mortgage that I'll be paying off in (checks calendar) a week and a half, at which point the whole lot gets closed and they can make it a two digit PIN for all it'll affect my financial security! I'll one-up you: Nationwide requires six numeric characters, which you have to enter via one 0-9 dropdown menu per digit, and you only have to enter three per login. i.e. if your "passcode" is 987654, then it will randomly choose only three of those for you to enter, like _?_??_ where you'd only have to put in 8, 6, and 5. So it's clearly stored in plaintext. And they have 2FA, but as you might expect, it's SMS only. And their online banking site is garbage, some links just always timeout and log me out. Is there a single UK bank that has the following two features: 1) lets me pick a sane password and has non-SMS 2FA, 2) has an online banking interface that works on desktop browsers. The second one is important to me because I never want to do banking on my phone. Last time I checked, the "challenger banks" like Monzo only have phone options.

davedx 4y ago

I stopped reading at the password length isn’t password strength part. This goes against NIST guidelines and is opinion. Just follow NIST password guidelines guys.

alanfranz 4y ago
This is an explanation and reasoning. It’s designed to make people think about policies and scenarios, and not to blindly apply random suggestions. What is against NIST guidelines? The length argument works both ways: just as a purely lowercase alphabetic password, if long enough, is safe, a very short (in term of code points) password with full unicode spectrum can be safe as well.

bigbacaloa 4y ago

I thought the one capital, one strange character, at least 8 characters, etc. policies were mainly so that whoever programs the web page can later claim to have taken proper measures when the site gets hacked.

TacticalCoder 4y ago

> The usual approach for handling a password is: take the password as a string, as the user typed it. Ah. That usual approach, where any rogue employee or anyone really snooping on either side of the connection before/after the TLS gets to see the plaintext password. Makes me wonder: is salted challenge response authentication (RFC5802 and 7804) getting any traction? Couchbase is (was?) using that. Is there a list of websites that went past what's basically the nineties' "plaintext password over SSL"?

alanfranz 4y ago
I didn’t know that rfc, but afaik the usual way is what I’ve written. Will take a look at that,btw. Looks interesting.

sandos 4y ago

My company recently switched to something probably inspired by the NIST standard. We are supposed to have a unique password, that never expires. The "problem" is that we are now required to use 2-factor basically every time we sign in instead, which is annoying, and the login also times out way too fast of course. Previously I could be logged in for days? Now its hours and I need to then use my phone to log in. (I only work remotely, but being a firm of contractors its what most of us do.)

gtirloni 4y ago

>You waste a lot of time at generating a "strong password" that complies with a website's policy I let my password manager do it and don't bother with it any time soon.

alanfranz 4y ago
But your generated password contains "-", and that's not accepted by the website. How can you not bother?
- throwawaaarrgh 4y ago
  Password manager password generators have a simple UI you can click to select the password format required by the form. Or just click 'generate' again and try each until one works.
  - alanfranz 4y ago
    So, you need to bother, either to reverse-engineer the site requirements, or to try until it works. For no good reason, as explained in the article.

e12e 4y ago

I recall a talk at passwordcon by Per Thorsheim where he pointed out that not only does the password: "Password2022" meet most "strict" criteria (three different character classes, longer than eight characters) - and -it's amenable to yearly demands for changing (increase the year) - but in large organizations you're actually very likely to find a user or two with this password (as seen in audits that ran simple brute force against the user directory). PS: in the rare case it's not "secure" enough, add an exclamation point: "Password2022!"

alanfranz 4y ago
One good complexity check would be “contains a single dictionary word as the main content.” I don’t know if library does it, though.
- deleted 4y ago
  [deleted]
- throwoutway 4y ago
  Why is this a good complexity check?
  - alanfranz 4y ago
    Because dictionary attacks are easy on single words + small mutations, like some capitalizations and adding 1-2 digits.

satvikchoudhary 4y ago

I guess this post made an impact on me. Earlier I was using the policy of Upper, lower, special characters but now using zxcvbn. https://zxcvbn-ts.github.io/zxcvbn/ https://zxcvbn-ts.github.io/zxcvbn/ Much thanks to the creators and maintainers. It only took me 5 minutes for the whole thing.

throwawaaarrgh 4y ago

> please allow long passwords at least 64 chars long; even 256 should pose no DoS risk whatsoever With a very large user database, a 256 char entry field would really start to add up, wouldn't it? iirc the DB takes up that room whether it's fully used or not. Size affects not just disk but also bandwidth, memory, cpu, and has an overall effect on system performance

ratboy666 4y ago
Please do not store the password... store a hash.
alanfranz 4y ago
The hash is constant length regardless of input size. DoS is on processing power.