6 ms·

I second the "hex encode it" solution, 256 bit of generated hex looks something like this: 232e2252b8d5a294dd8564020f0cf609f511b3d196ed83030ce9615c6737f578 Th

by eterm 11y ago

I second the "hex encode it" solution, 256 bit of generated hex looks something like this: 232e2252b8d5a294dd8564020f0cf609f511b3d196ed83030ce9615c6737f578 That's readable, typable, copy-pastable. Not very memorable but 256 bits is rarely memorable. It's still short enough to send around by normal messaging. This is specifically about randomly generated passwords, this is not about dealing with human generated "must have capitals, not start or end with a number" etc rules.

delinka 11y ago
I argue with 'typable.' If I'm reading this from my smartphone and typing it on my computer (or vice versa), I'm going to lose my place. Maybe formatting could fix that, but it's still a pretty long chunk of text to get lost in.
- Gracana 11y ago
  Two bytes at a time is not so bad, especially with some friendly newlines: 232e 2252 b8d5 a294 dd85 6402 0f0c f609 f511 b3d1 96ed 8303 0ce9 615c 6737 f578 Of course, it's still a lot of characters.
  - jobigoud 11y ago
    In fact I find it MUCH more typable than my usual generated password, which are like ,X,=a&ny.Qz{?Uif@0q( and are a real pain to type on mobile due to the special characters.
    - ThrustVectoring 11y ago
      That might be ameliorated by choosing a touch keyboard optimized for character-by-character input rather than english text. MessagEase works well for me for that.
Spooky23 11y ago
Remember on windows you are effectively stuck with a maximum password length of 15 characters in many scenarios. And before you Google and say "No! It changed to 127 in Windows XP!", remember: - Somewhere on your network, NTLM is being used. - Office 365 supports 16 max. - Lots of random apps won't work.
- monochromatic 11y ago
  I've been using 20+ character Windows passwords for years and have literally never had a single problem with it.
  - CiPHPerCoder 11y ago
    Try logging in with only the first 16 characters of your password rather than the full password.
    - dsp1234 11y ago
      "the username or password is incorrect."
  - cbhl 11y ago
    Silent password truncation isn't a problem that reveals itself until someone cracks the shorter NTLM hash.
    - dsp1234 11y ago
      someone cracks the shorter NTLM hash. There are only two possible hashes stored in the SAM database. You mention the 'shorter' one, which would be the 'LM hash' which is restricted to 14 character passwords. However, LM hash storage has been disabled by default for all windows system since Vista / Windows Server 2008 (and ability to not store them was available, but not disabled by default since at least Windows 2000). Even Samba has had the ability to not generate or store the LM hash since at least 2002 (earliest search reference I could find).
jsprogrammer 11y ago
Why not base64? Even shorter, readable, typable, copy-pastable (why are you copy-pastung passwords?), and pehaps even memorable.
- falcolas 11y ago
  Indeed. $ dd if=/dev/random bs=1 count=32 | base64 ca2ktYYvppr1/HwwGYrg01udQX1cP4Ek5VmyzQydT+8=
  - yoo1I 11y ago
    My mother was a saint!! ... when I just still wet behind the ears I was studying the codebase of my first job, and came across a quite extensive badwords.txt . On asking why we had a the dictionary of cussing in our project, I found out that the randomly generated passwords that we sent to our clients, apparently managed to get a customer quite angry when one of the words produced started with a slur, and this was a filter to prevent that from happening again Generating random passwords isn't quite as straightforward as it would seem to be...
    - vog 11y ago
      This approach requires that your badwords.txt is not just extensive, but supports all languages. Isn't it easier to just generate words without vowels? This is the more common solution to that problem, IIRC.
      - yoo1I 11y ago
        Yeah I thought about that as well when I wrote down the above. Doing general localization is really hard if you want to do it well. If you know your approximate audience, you probably have to tailor your localization to them, instead of everybody. Case in point: Not all scripts even have vowels.
    - falcolas 11y ago
      > randomly generated passwords > we sent to our clients I'm making the assumption that these are one-time passwords for initial account setup. But no, no one scheme will work for everything, obviously. The hex version will fail for schemes which have an upper limit, or when there's a requirement for upper/lower/symbols. The base64 encoding will fail other validations due to the '/' character, or for particularly restrictive upper size limits. I wish all of them would simply accept a string and put in an upper limit of 1k to limit DOS by password. Call it good.
matt_wulfeck 11y ago
I always loved hex encoding because you can always click it twice to highlight the entire string. It's a simple thing, but always saves time and reduces errors. Different systems have different characters that will be included/discluded from "twice click highlighting" (I have no idea what the term is called). Hex works on virtually all systems. The article does mention it's not very space efficient.

by eterm 11y ago

delinka 11y ago

I argue with 'typable.' If I'm reading this from my smartphone and typing it on my computer (or vice versa), I'm going to lose my place. Maybe formatting could fix that, but it's still a pretty long chunk of text to get lost in.

Gracana 11y ago
Two bytes at a time is not so bad, especially with some friendly newlines: 232e 2252 b8d5 a294 dd85 6402 0f0c f609 f511 b3d1 96ed 8303 0ce9 615c 6737 f578 Of course, it's still a lot of characters.
- jobigoud 11y ago
  In fact I find it MUCH more typable than my usual generated password, which are like ,X,=a&ny.Qz{?Uif@0q( and are a real pain to type on mobile due to the special characters.
  - ThrustVectoring 11y ago
    That might be ameliorated by choosing a touch keyboard optimized for character-by-character input rather than english text. MessagEase works well for me for that.

Spooky23 11y ago

Remember on windows you are effectively stuck with a maximum password length of 15 characters in many scenarios. And before you Google and say "No! It changed to 127 in Windows XP!", remember: - Somewhere on your network, NTLM is being used. - Office 365 supports 16 max. - Lots of random apps won't work.

monochromatic 11y ago
I've been using 20+ character Windows passwords for years and have literally never had a single problem with it.
- CiPHPerCoder 11y ago
  Try logging in with only the first 16 characters of your password rather than the full password.
  - dsp1234 11y ago
    "the username or password is incorrect."
- cbhl 11y ago
  Silent password truncation isn't a problem that reveals itself until someone cracks the shorter NTLM hash.
  - dsp1234 11y ago
    someone cracks the shorter NTLM hash. There are only two possible hashes stored in the SAM database. You mention the 'shorter' one, which would be the 'LM hash' which is restricted to 14 character passwords. However, LM hash storage has been disabled by default for all windows system since Vista / Windows Server 2008 (and ability to not store them was available, but not disabled by default since at least Windows 2000). Even Samba has had the ability to not generate or store the LM hash since at least 2002 (earliest search reference I could find).

jsprogrammer 11y ago

Why not base64? Even shorter, readable, typable, copy-pastable (why are you copy-pastung passwords?), and pehaps even memorable.

falcolas 11y ago
Indeed. $ dd if=/dev/random bs=1 count=32 | base64 ca2ktYYvppr1/HwwGYrg01udQX1cP4Ek5VmyzQydT+8=
- yoo1I 11y ago
  My mother was a saint!! ... when I just still wet behind the ears I was studying the codebase of my first job, and came across a quite extensive badwords.txt . On asking why we had a the dictionary of cussing in our project, I found out that the randomly generated passwords that we sent to our clients, apparently managed to get a customer quite angry when one of the words produced started with a slur, and this was a filter to prevent that from happening again Generating random passwords isn't quite as straightforward as it would seem to be...
  - vog 11y ago
    This approach requires that your badwords.txt is not just extensive, but supports all languages. Isn't it easier to just generate words without vowels? This is the more common solution to that problem, IIRC.
    - yoo1I 11y ago
      Yeah I thought about that as well when I wrote down the above. Doing general localization is really hard if you want to do it well. If you know your approximate audience, you probably have to tailor your localization to them, instead of everybody. Case in point: Not all scripts even have vowels.
  - falcolas 11y ago
    > randomly generated passwords > we sent to our clients I'm making the assumption that these are one-time passwords for initial account setup. But no, no one scheme will work for everything, obviously. The hex version will fail for schemes which have an upper limit, or when there's a requirement for upper/lower/symbols. The base64 encoding will fail other validations due to the '/' character, or for particularly restrictive upper size limits. I wish all of them would simply accept a string and put in an upper limit of 1k to limit DOS by password. Call it good.

matt_wulfeck 11y ago

I always loved hex encoding because you can always click it twice to highlight the entire string. It's a simple thing, but always saves time and reduces errors. Different systems have different characters that will be included/discluded from "twice click highlighting" (I have no idea what the term is called). Hex works on virtually all systems. The article does mention it's not very space efficient.