4 ms·

> 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

by 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.
- lolinder 4y ago
  Correct, but the recommendation in the article is still wrong. If I get a password that has four Unicode characters in it, it's possible that it's a strong password that chose truly randomly from the available Unicode characters, but it's much more likely that someone just picked four that they like. In the latter case, the bits per character is going to be much lower, but I can't tell the difference just looking at the password. The only good solution I can think of is to assume low bits per character and require a minimum password length.
  - zinekeller 4y ago
    > but it's much more likely that someone just picked four that they like Or as I would call it, the fallacy of uniformity. The author assumes that hackers would only try a dictionary attack using lower case letters, but this is no longer true since mid-2010s. Some dictionaries geared for international services also have non-Latin characters since not all countries restrict passwords to alphanumerics.
    - alanfranz 4y ago
      If it’s four random Unicode code points, it’s not a dictionary word.
  - Aeolun 4y ago
    You don’t have to assume this. You can check the length in bytes of the password.
  - alanfranz 4y ago
    The same problem can happen with eight-char passwords. I could pick the same eight chars I like all the time and reuse passwords. You cannot fix password reuse that way. I'm not advocating for emoji passwords, it was just a discussion about password strength vs length.
    - lolinder 4y ago
      Right, you can't force people to use good passwords, but you can set up requirements that try to maximize the chances that that's what you get. As others have mentioned, there's no way to fully evaluate password strength short of providing your own entropy, so while the distribution is an important one to know about there's not much we can do to apply it while retaining a traditional password model. NIST has some recommendations[0] that can detect when a password is not strong, such as checking a list of cracked passwords, but we can't prove that it is. [0] https://pages.nist.gov/800-63-3/sp800-63b.html#memsecret https://pages.nist.gov/800-63-3/sp800-63b.html#memsecret
the_af 4y ago
The author's point is not that you should use a short unicode password, but that the key thing to focus on is password strength, not length. That is, use a lib that enforces password strength -- he is arguing -- instead of focusing on arbitrary and possibly wrong constraints such as "password too short". Strength is going to take care of it if it really is too short, anyway. The author is also aware that we've known these things for a long time now -- he opens his article by complaining about this and how slow some websites and apps are at catching up, in fact.
- lucb1e 4y ago
  So what's the proposal, switching to requiring a different length when a unicode character is present? How do you know from what set of possible values (like thousands of possible unicode chars versus a-z) the user chose each character? While 68 bits entropy are secure in a case of good hashing, I think the statement is misleading. Anyone who uses a random generator will just use 16+ random alphanumerics (optionally with symbols) and call it a day; users aren't going to be able to input a unicode snowman with combination marker with orange skin on every keyboard without using the clipboard or other software. It's not more secure, it's just asking for trouble. A software tester can do this, but there is no practical reason to lower the length requirement to 4 characters because an ẍ might be entered. The author doesn't end up proposing such a thing, but the argument in this paragraph still doesn't sound practical to me.
  - the_af 4y ago
    I think the argument, aimed at the people making the website/app (but not the login, which should be a third party), is that they should ditch ad-hoc and ill-advised password constraints and instead go with a well vetted third party lib that just measures password "strength". A variant of "don't roll your own crypto (unless you work in the crypto space)".
lolinder 4y ago
> Security through obscurity. This is safe until everyone does it. If he's actually randomly selecting from the entire set of valid Unicode characters, then theoretically his four character password has orders of magnitude more entropy than an eight character alphanumeric password. The problem is that from the website's perspective there's no way to know what set of characters the user is choosing between. They could be dealing with someone who's picking truly at random, but more likely someone just thought they'd be cute and throw a few popular emoji at it. By just looking at a single password I can't tell the difference, so it's safer just to impose a minimum length requirement.
- alanfranz 4y ago
  > If he's actually randomly selecting from the entire set of valid Unicode characters, then theoretically his four character password has orders of magnitude more entropy than an eight character alphanumeric password. Exactly. > but more likely someone just thought they'd be cute and throw a few popular emoji at it That's entirely possible. Thanks, I'll update the article.
alanfranz 4y ago
> Security through obscurity It was a kind of joke. If you don't show the password, then it seems more secure because nobody can see it. I was in doubt whether to retain that naming.

by lucb1e 4y ago

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.

lolinder 4y ago
Correct, but the recommendation in the article is still wrong. If I get a password that has four Unicode characters in it, it's possible that it's a strong password that chose truly randomly from the available Unicode characters, but it's much more likely that someone just picked four that they like. In the latter case, the bits per character is going to be much lower, but I can't tell the difference just looking at the password. The only good solution I can think of is to assume low bits per character and require a minimum password length.
- zinekeller 4y ago
  > but it's much more likely that someone just picked four that they like Or as I would call it, the fallacy of uniformity. The author assumes that hackers would only try a dictionary attack using lower case letters, but this is no longer true since mid-2010s. Some dictionaries geared for international services also have non-Latin characters since not all countries restrict passwords to alphanumerics.
  - alanfranz 4y ago
    If it’s four random Unicode code points, it’s not a dictionary word.
- Aeolun 4y ago
  You don’t have to assume this. You can check the length in bytes of the password.
- alanfranz 4y ago
  The same problem can happen with eight-char passwords. I could pick the same eight chars I like all the time and reuse passwords. You cannot fix password reuse that way. I'm not advocating for emoji passwords, it was just a discussion about password strength vs length.
  - lolinder 4y ago
    Right, you can't force people to use good passwords, but you can set up requirements that try to maximize the chances that that's what you get. As others have mentioned, there's no way to fully evaluate password strength short of providing your own entropy, so while the distribution is an important one to know about there's not much we can do to apply it while retaining a traditional password model. NIST has some recommendations[0] that can detect when a password is not strong, such as checking a list of cracked passwords, but we can't prove that it is. [0] https://pages.nist.gov/800-63-3/sp800-63b.html#memsecret https://pages.nist.gov/800-63-3/sp800-63b.html#memsecret

the_af 4y ago

The author's point is not that you should use a short unicode password, but that the key thing to focus on is password strength, not length. That is, use a lib that enforces password strength -- he is arguing -- instead of focusing on arbitrary and possibly wrong constraints such as "password too short". Strength is going to take care of it if it really is too short, anyway. The author is also aware that we've known these things for a long time now -- he opens his article by complaining about this and how slow some websites and apps are at catching up, in fact.

lucb1e 4y ago
So what's the proposal, switching to requiring a different length when a unicode character is present? How do you know from what set of possible values (like thousands of possible unicode chars versus a-z) the user chose each character? While 68 bits entropy are secure in a case of good hashing, I think the statement is misleading. Anyone who uses a random generator will just use 16+ random alphanumerics (optionally with symbols) and call it a day; users aren't going to be able to input a unicode snowman with combination marker with orange skin on every keyboard without using the clipboard or other software. It's not more secure, it's just asking for trouble. A software tester can do this, but there is no practical reason to lower the length requirement to 4 characters because an ẍ might be entered. The author doesn't end up proposing such a thing, but the argument in this paragraph still doesn't sound practical to me.
- the_af 4y ago
  I think the argument, aimed at the people making the website/app (but not the login, which should be a third party), is that they should ditch ad-hoc and ill-advised password constraints and instead go with a well vetted third party lib that just measures password "strength". A variant of "don't roll your own crypto (unless you work in the crypto space)".

lolinder 4y ago

> Security through obscurity. This is safe until everyone does it. If he's actually randomly selecting from the entire set of valid Unicode characters, then theoretically his four character password has orders of magnitude more entropy than an eight character alphanumeric password. The problem is that from the website's perspective there's no way to know what set of characters the user is choosing between. They could be dealing with someone who's picking truly at random, but more likely someone just thought they'd be cute and throw a few popular emoji at it. By just looking at a single password I can't tell the difference, so it's safer just to impose a minimum length requirement.

alanfranz 4y ago
> If he's actually randomly selecting from the entire set of valid Unicode characters, then theoretically his four character password has orders of magnitude more entropy than an eight character alphanumeric password. Exactly. > but more likely someone just thought they'd be cute and throw a few popular emoji at it That's entirely possible. Thanks, I'll update the article.

alanfranz 4y ago

> Security through obscurity It was a kind of joke. If you don't show the password, then it seems more secure because nobody can see it. I was in doubt whether to retain that naming.