10 ms·

Randomly-generated passwords still have to be legal strings

69 points by ikeboy 11y ago

adzm 11y ago
Ascii85 is a great compromise between binary and base64, which works well for passwords.
alyandon 11y ago
Is there really any need to generate non-alphanumeric passwords as long as they are of sufficient length? Sticking with plain old A-Za-z0-9 seems like it avoids a lot of interop issues.
- Cthulhu_ 11y ago
  True, but I'm also pretty sure that there's no brute force password guess-o-matic that tries every possible UTF-16 character; they too will stick to the default keyboard-entered combinations because there's very few passwords outside of those.
- deleted 11y ago
  [deleted]
- jfoutz 11y ago
  Every extra supported character makes the solution space much bigger. with 2 character passwords, your set is 3844 combinations. If you can manage to add in "!@#$%^&*()", that goes up to 5184, a 16% increase in options leads to a 34% increase in search space. No, it's not necessary, unbounded length is probably better. But it's pretty nice to have a lot more characters, and ought to be an easy win.
  - Retric 11y ago
    Every required charter type makes the search space dramatically smaller. https://xkcd.com/936/ https://xkcd.com/936/ The goal should be long easy to type and remember passwords, adding an extra few digit is worth far more than forcing passwords to look like: 2K#@1j* Compare say a 20 digit numeric password vs an 9 digit [0-9] [a-z] [A-Z] and special.
    - jfoutz 11y ago
      I'm not saying require *, I'm saying allow the option.
    - tgb 11y ago
      > Every required charter type makes the search space dramatically smaller. That is neither what the parent suggested nor really true. The space of, say, 8 character passwords A-Za-z0-9 that DO have at least one digit is very similar in size to the space of passwords maybe not containing digits. (The latter is 36^8 the former is 36^8-26^8, a reduction by less than 8% of the password space. The difference is even less important for longer passwords)
      - Retric 11y ago
        People have a huge bias to add digits and special Characters at the end of a password and start a password with an upper case letter. 1! is also really common. So, the rules often end up with something like a ~90% reduction in search space. PS: You also forgot about the special character.
        tgb 11y ago
        For requiring both a number and a special character (out of 10 possibilities): reduces passwords from 46^8 to 46^8 - (36^8 + 36^8-26^8) which is a 27% reduction in password space. I wouldn't call that dramatic and it reduces in importance as the password length grows and, as you bring up biases, it eliminates the most abused password types. I don't understand your comments about adding digits and special characters at the end of the password. password + digit + special character is strictly harder to guess than just password (we've added two extra characters, after all). Do you mean that people routinely delete the last two letters of their alphabetic password and replace them with 1! ? I find that implausible. The key point is that if you don't require numbers and special characters then no one uses them at all so the possibility space becomes 26^8.
        Retric 11y ago
        > (we've added two extra characters, after all) No, the same length just with more restrictions. Your suggesting you replace a min 8 digit password with a minimum 10 digit password but the gain is from adding length not restrictions. Sadly plenty of passwords are fixed at 8 digits and they reduce the search space below that. So you go from 26^8 to 26^1 x 26^5 and 1! which effectively is just 26^6. IMO it's reasonable to remove the top 100 or so passwords. But, after that your just reducing the search space.
  - ghayes 11y ago
    Easy is relative to the experience. If we're talking (26+26+10)^100 versus (26+26+10+10)^100, the difference is moot in terms of brute-forcing the password. However, the inability to double click select, to paste in to chat rooms, etc may change based on which characters are allowed. These properties may be desired (or not) for your organization.
  - lmm 11y ago
    It's not an easy win compared to just adding more length. Yes adding those characters to the set would increase the search space by 34%, but going from 2 characters to 3 (with the original set) would increase it by 6100%.
- ajuc 11y ago
  A-Za-z0-9 != alphanumeric. My alphabet last letter is "ż" not "z". \w = alphanumeric Some people don't even have latin letters on their keyboards by default. And "latin letters" aren't well defined anyway. For one thing technicaly "w" isn't a latin letter. I'm of the opinion that all restrictions on character set in password are unnesessary and harmful. You shouldn't store plain passwords anyway. You shouldn't even pass the plain password from client to server. Why do you care what character set your customer uses? IMHO the main reason to restrict passwords' character set is to annoy users by forcing them to make another variation of their favorite throwaway password for your criticaly important blog comment section.
  - falsedan 11y ago
    > For one thing technicaly "w" isn't a latin letter. Don't be silly. Yes, I know how Romans pronounced 'ave'.
- sugarfactory 11y ago
  I quite agree. However I have seen a great many registration forms that only accept a short password. If passwords are handled properly there's no reason to limit password length because a password will get converted to a fixed-length string due to hashing before storing it to a database. So I suspect many people prefer storing passwords in plaintext.
JoeAltmaier 11y ago
Another solution is to treat every password as binary. Text works. UUIDs work. Everything works. But folks went down the text-password road a long time ago, so we're stuck with this for now.
- dchest 11y ago
  Passwords-based systems assume input, and most UI frameworks use text strings for inputs. Binary password is usually not called a password, it's a key.
  - smsm42 11y ago
    Exactly, so if they are not meant to be input, as the article claims, why are they passwords and not keys? Why they are even checked to be valid unicode strings? I know of no encryption algorithm that cares about key being a valid unicode string. Looks like just laziness in distinguishing which data should be binary and which should be Unicode string.
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.
13of40 11y ago
Throw in the complexity requirements a Windows domain imposes on the password, and this turns into even more of a headache. Of course you can just append A1! to an otherwise sufficiently complex password to meet the requirements, but it will make people freak out in the code review.
teraflop 11y ago
> We generate our password from a cryptographically secure random number generator. ... We found that sometimes (no predictable pattern), we have interoperability problems between systems. If there was a predictable pattern, that would be even worse!
- thecatspaw 11y ago
  well, no. a predictable pattern would be "every time the password starts with 0100101 they are not compatible". its not about the number having a pattern
lyle_nel 11y ago
By just looking at the title and before reading the article, I though they meant that they are checking for illegal strings that are illegal to transmit. https://en.wikipedia.org/wiki/Illegal_number https://en.wikipedia.org/wiki/Illegal_number
pmontra 11y ago
I hope the developers of those sites that insist that passwords must be, let's say, between 6 and 18 characters are reading this.
DenisM 11y ago
It has occurred to me recently that 12 random words from a 2000 word dictionary will give you 132 bits on entropy. More that you will ever need. There's a number of advantages to this scheme: - It's easy to write down and put in a safe. - No funny characters required. - Not case-sensitive. - If a user makes a spelling error, we can correct it for him without any compromise in security. - Guaranteed to be free from offensive words, unlike a randomly generated password. - People are using words anyways, misspelled if necessary, whether we like it or not. We can also make it even more user-friendly by carefully degrading security, such as trying common word substitutions for the forgetful users, or doing some kind of middle-ground "remember me" that does not let you straight in, but only demands first three words (to keep the family members at bay). Like I said, this required careful calculations as to how much security is sacrificed when we do that.
- oniony 11y ago
  This was made clear many moons ago by the now famous xkcd strip https://www.xkcd.com/936/ https://www.xkcd.com/936/
  - DenisM 11y ago
    My innovation :) is to prevent users from selecting their own words, so that we can actually guarantee the entropy required. Otherwise a Markov chain will tear it to pieces.
    - cuckcuckspruce 11y ago
      You mean like Diceware[1], which has been around since at least 2000? [1] http://world.std.com/~reinhold/diceware.html http://world.std.com/~reinhold/diceware.html
      - DenisM 11y ago
        Good stuff. All we need now is to marry it with a password manager so that it generates random passwords based on this one passphrase and then autofills the web forms for you.
oniony 11y ago
All of these systems suffer from the differing password restrictions imposed by the various services you need to register for. • Some services require both upper and loweracase characters. • Some services require punctuation characters whilst others prohibit them. • Some services prohibit repeated characters. • Some services impose a minimum password length; some impose a maximum password length; some impose both. Covering all these situations is nearly impossible.
- eterm 11y ago
  The first line of the article makes it clear this is for passwords used in programmatic use. These restrictions exist for when humans are allowed to generate passwords. This article is discussing systems where humans don't generate passwords and don't in regular operation enter them. Think of automatic password generation for a secure API endpoint, or automatic generation of private keys secured by a password that typically will be used in a system with it on the keychain but where the backup copies will be stored offsite. In that case it's acceptable to have a password which is both secure but it has to be easy to type when required but doesn't have to be easy to type (i.e. short) for regular use. The internet of things means that more and more devices will be creating "users" which are actually just other IoT devices. Those devices/device-users require these sorts of passwords.
munificent 11y ago
News flash: taking a randomly generated sequence of bytes and treating it as correctly following some encoding may fail. This is like saying "Why isn't this random sequence of bytes a valid JPEG file?" If you want a random image, you generate the image randomly, then you encode it. Strings are no different — though the encoding is simpler.
- mikeash 11y ago
  Unicode mystifies a lot of people. Many people don't even realize that a sequence of 16-bit unicode value is UTF-16 (or UCS-2), let alone that not all sequences of 16-bit values are valid UTF-16. The password bit is really just the hook, the main info in this article is the fact that these values are interpreted as UTF-16, and that UTF-16 has requirements beyond "sequence of 16-bit values." Which is kind of obvious, but still not well known for many.
  - theophrastus 11y ago
    I'll freely admit to being one of those mystified folk. As an easy example of which, can you roughly outline which n-bit values are not valid UTF-n? (are they reserved for shifting to other systems? and if so, isn't that still a valid, even an important value, within UTF-n?)
    - mikeash 11y ago
      The article covers this for the case of UTF-16. To recap, UTF-16 has surrogate pairs, which are a sequence of two 16-bit values in certain ranges. A high surrogate is in the range 0xD800–0xDBFF and a low surrogate is in the range 0xDC00–0xDFFF. This is used to encode values beyond 65,535. If a high surrogate appears without a following low surrogate, or a low surrogate appears without a leading high surrogate, the sequence is not valid UTF-16. For UTF-32, only valid code points are allowed. Values above 0x10FFFF are not allowed, nor are values in the range used for UTF-16 surrogates. UTF-8 is more complex. It's ASCII compatible, which means all values with the top bit set to 0 are allowed. Bytes with the top bit set to 1 must exist as part of a multi-byte sequence. The first byte in such a sequence must contain 2-4 leading 1s followed by a 0. Subsequent bytes must be of the form 10xxxxxx. The total length of the sequence is equal to the number of leading 1s in the first byte. Any deviation from this is invalid UTF-8. Further, any sequence must be minimal, meaning that the value it encodes can't be one that would fit into a smaller sequence.
accounthere 11y ago
It has happened to me that a registration form would not allow characters like '<' which any keyboard will most likely have, while it allowed unicode characters like (ಠ_ಠ)
- _kst_ 11y ago
  Sounds like a clumsy attempt to guard against HTML injection.
matt_wulfeck 11y ago
The article mentions that hex encoding solves most of the problems but isn't very space efficient. A good alternative may be base64k encoding, which was proposed here on hacker news[0]. This gives you safe strings as well as space-efficient encoding. As a bonus virtually all systems support unicode without any tweaking necessary. I hope the author of base64k gets around to writing an RFC because it would be a great standard to use. [0] https://www.npmjs.com/package/base65536 https://www.npmjs.com/package/base65536

69 points by ikeboy 11y ago

adzm 11y ago

Ascii85 is a great compromise between binary and base64, which works well for passwords.

Is there really any need to generate non-alphanumeric passwords as long as they are of sufficient length? Sticking with plain old A-Za-z0-9 seems like it avoids a lot of interop issues.

Cthulhu_ 11y ago
True, but I'm also pretty sure that there's no brute force password guess-o-matic that tries every possible UTF-16 character; they too will stick to the default keyboard-entered combinations because there's very few passwords outside of those.
deleted 11y ago
[deleted]
jfoutz 11y ago
Every extra supported character makes the solution space much bigger. with 2 character passwords, your set is 3844 combinations. If you can manage to add in "!@#$%^&*()", that goes up to 5184, a 16% increase in options leads to a 34% increase in search space. No, it's not necessary, unbounded length is probably better. But it's pretty nice to have a lot more characters, and ought to be an easy win.
- Retric 11y ago
  Every required charter type makes the search space dramatically smaller. https://xkcd.com/936/ https://xkcd.com/936/ The goal should be long easy to type and remember passwords, adding an extra few digit is worth far more than forcing passwords to look like: 2K#@1j* Compare say a 20 digit numeric password vs an 9 digit [0-9] [a-z] [A-Z] and special.
  - jfoutz 11y ago
    I'm not saying require *, I'm saying allow the option.
  - tgb 11y ago
    > Every required charter type makes the search space dramatically smaller. That is neither what the parent suggested nor really true. The space of, say, 8 character passwords A-Za-z0-9 that DO have at least one digit is very similar in size to the space of passwords maybe not containing digits. (The latter is 36^8 the former is 36^8-26^8, a reduction by less than 8% of the password space. The difference is even less important for longer passwords)
    - Retric 11y ago
      People have a huge bias to add digits and special Characters at the end of a password and start a password with an upper case letter. 1! is also really common. So, the rules often end up with something like a ~90% reduction in search space. PS: You also forgot about the special character.
      - tgb 11y ago
        For requiring both a number and a special character (out of 10 possibilities): reduces passwords from 46^8 to 46^8 - (36^8 + 36^8-26^8) which is a 27% reduction in password space. I wouldn't call that dramatic and it reduces in importance as the password length grows and, as you bring up biases, it eliminates the most abused password types. I don't understand your comments about adding digits and special characters at the end of the password. password + digit + special character is strictly harder to guess than just password (we've added two extra characters, after all). Do you mean that people routinely delete the last two letters of their alphabetic password and replace them with 1! ? I find that implausible. The key point is that if you don't require numbers and special characters then no one uses them at all so the possibility space becomes 26^8.
        Retric 11y ago
        > (we've added two extra characters, after all) No, the same length just with more restrictions. Your suggesting you replace a min 8 digit password with a minimum 10 digit password but the gain is from adding length not restrictions. Sadly plenty of passwords are fixed at 8 digits and they reduce the search space below that. So you go from 26^8 to 26^1 x 26^5 and 1! which effectively is just 26^6. IMO it's reasonable to remove the top 100 or so passwords. But, after that your just reducing the search space.
- ghayes 11y ago
  Easy is relative to the experience. If we're talking (26+26+10)^100 versus (26+26+10+10)^100, the difference is moot in terms of brute-forcing the password. However, the inability to double click select, to paste in to chat rooms, etc may change based on which characters are allowed. These properties may be desired (or not) for your organization.
- lmm 11y ago
  It's not an easy win compared to just adding more length. Yes adding those characters to the set would increase the search space by 34%, but going from 2 characters to 3 (with the original set) would increase it by 6100%.
ajuc 11y ago
A-Za-z0-9 != alphanumeric. My alphabet last letter is "ż" not "z". \w = alphanumeric Some people don't even have latin letters on their keyboards by default. And "latin letters" aren't well defined anyway. For one thing technicaly "w" isn't a latin letter. I'm of the opinion that all restrictions on character set in password are unnesessary and harmful. You shouldn't store plain passwords anyway. You shouldn't even pass the plain password from client to server. Why do you care what character set your customer uses? IMHO the main reason to restrict passwords' character set is to annoy users by forcing them to make another variation of their favorite throwaway password for your criticaly important blog comment section.
- falsedan 11y ago
  > For one thing technicaly "w" isn't a latin letter. Don't be silly. Yes, I know how Romans pronounced 'ave'.
sugarfactory 11y ago
I quite agree. However I have seen a great many registration forms that only accept a short password. If passwords are handled properly there's no reason to limit password length because a password will get converted to a fixed-length string due to hashing before storing it to a database. So I suspect many people prefer storing passwords in plaintext.

JoeAltmaier 11y ago

Another solution is to treat every password as binary. Text works. UUIDs work. Everything works. But folks went down the text-password road a long time ago, so we're stuck with this for now.

dchest 11y ago
Passwords-based systems assume input, and most UI frameworks use text strings for inputs. Binary password is usually not called a password, it's a key.
- smsm42 11y ago
  Exactly, so if they are not meant to be input, as the article claims, why are they passwords and not keys? Why they are even checked to be valid unicode strings? I know of no encryption algorithm that cares about key being a valid unicode string. Looks like just laziness in distinguishing which data should be binary and which should be Unicode string.

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.

13of40 11y ago

Throw in the complexity requirements a Windows domain imposes on the password, and this turns into even more of a headache. Of course you can just append A1! to an otherwise sufficiently complex password to meet the requirements, but it will make people freak out in the code review.

teraflop 11y ago

> We generate our password from a cryptographically secure random number generator. ... We found that sometimes (no predictable pattern), we have interoperability problems between systems. If there was a predictable pattern, that would be even worse!

thecatspaw 11y ago
well, no. a predictable pattern would be "every time the password starts with 0100101 they are not compatible". its not about the number having a pattern

lyle_nel 11y ago

By just looking at the title and before reading the article, I though they meant that they are checking for illegal strings that are illegal to transmit. https://en.wikipedia.org/wiki/Illegal_number https://en.wikipedia.org/wiki/Illegal_number

pmontra 11y ago

I hope the developers of those sites that insist that passwords must be, let's say, between 6 and 18 characters are reading this.

DenisM 11y ago

It has occurred to me recently that 12 random words from a 2000 word dictionary will give you 132 bits on entropy. More that you will ever need. There's a number of advantages to this scheme: - It's easy to write down and put in a safe. - No funny characters required. - Not case-sensitive. - If a user makes a spelling error, we can correct it for him without any compromise in security. - Guaranteed to be free from offensive words, unlike a randomly generated password. - People are using words anyways, misspelled if necessary, whether we like it or not. We can also make it even more user-friendly by carefully degrading security, such as trying common word substitutions for the forgetful users, or doing some kind of middle-ground "remember me" that does not let you straight in, but only demands first three words (to keep the family members at bay). Like I said, this required careful calculations as to how much security is sacrificed when we do that.

oniony 11y ago
This was made clear many moons ago by the now famous xkcd strip https://www.xkcd.com/936/ https://www.xkcd.com/936/
- DenisM 11y ago
  My innovation :) is to prevent users from selecting their own words, so that we can actually guarantee the entropy required. Otherwise a Markov chain will tear it to pieces.
  - cuckcuckspruce 11y ago
    You mean like Diceware[1], which has been around since at least 2000? [1] http://world.std.com/~reinhold/diceware.html http://world.std.com/~reinhold/diceware.html
    - DenisM 11y ago
      Good stuff. All we need now is to marry it with a password manager so that it generates random passwords based on this one passphrase and then autofills the web forms for you.

oniony 11y ago

All of these systems suffer from the differing password restrictions imposed by the various services you need to register for. • Some services require both upper and loweracase characters. • Some services require punctuation characters whilst others prohibit them. • Some services prohibit repeated characters. • Some services impose a minimum password length; some impose a maximum password length; some impose both. Covering all these situations is nearly impossible.

eterm 11y ago
The first line of the article makes it clear this is for passwords used in programmatic use. These restrictions exist for when humans are allowed to generate passwords. This article is discussing systems where humans don't generate passwords and don't in regular operation enter them. Think of automatic password generation for a secure API endpoint, or automatic generation of private keys secured by a password that typically will be used in a system with it on the keychain but where the backup copies will be stored offsite. In that case it's acceptable to have a password which is both secure but it has to be easy to type when required but doesn't have to be easy to type (i.e. short) for regular use. The internet of things means that more and more devices will be creating "users" which are actually just other IoT devices. Those devices/device-users require these sorts of passwords.

munificent 11y ago

News flash: taking a randomly generated sequence of bytes and treating it as correctly following some encoding may fail. This is like saying "Why isn't this random sequence of bytes a valid JPEG file?" If you want a random image, you generate the image randomly, then you encode it. Strings are no different — though the encoding is simpler.

mikeash 11y ago
Unicode mystifies a lot of people. Many people don't even realize that a sequence of 16-bit unicode value is UTF-16 (or UCS-2), let alone that not all sequences of 16-bit values are valid UTF-16. The password bit is really just the hook, the main info in this article is the fact that these values are interpreted as UTF-16, and that UTF-16 has requirements beyond "sequence of 16-bit values." Which is kind of obvious, but still not well known for many.
- theophrastus 11y ago
  I'll freely admit to being one of those mystified folk. As an easy example of which, can you roughly outline which n-bit values are not valid UTF-n? (are they reserved for shifting to other systems? and if so, isn't that still a valid, even an important value, within UTF-n?)
  - mikeash 11y ago
    The article covers this for the case of UTF-16. To recap, UTF-16 has surrogate pairs, which are a sequence of two 16-bit values in certain ranges. A high surrogate is in the range 0xD800–0xDBFF and a low surrogate is in the range 0xDC00–0xDFFF. This is used to encode values beyond 65,535. If a high surrogate appears without a following low surrogate, or a low surrogate appears without a leading high surrogate, the sequence is not valid UTF-16. For UTF-32, only valid code points are allowed. Values above 0x10FFFF are not allowed, nor are values in the range used for UTF-16 surrogates. UTF-8 is more complex. It's ASCII compatible, which means all values with the top bit set to 0 are allowed. Bytes with the top bit set to 1 must exist as part of a multi-byte sequence. The first byte in such a sequence must contain 2-4 leading 1s followed by a 0. Subsequent bytes must be of the form 10xxxxxx. The total length of the sequence is equal to the number of leading 1s in the first byte. Any deviation from this is invalid UTF-8. Further, any sequence must be minimal, meaning that the value it encodes can't be one that would fit into a smaller sequence.

accounthere 11y ago

It has happened to me that a registration form would not allow characters like '<' which any keyboard will most likely have, while it allowed unicode characters like (ಠ_ಠ)

_kst_ 11y ago
Sounds like a clumsy attempt to guard against HTML injection.

matt_wulfeck 11y ago

The article mentions that hex encoding solves most of the problems but isn't very space efficient. A good alternative may be base64k encoding, which was proposed here on hacker news[0]. This gives you safe strings as well as space-efficient encoding. As a bonus virtually all systems support unicode without any tweaking necessary. I hope the author of base64k gets around to writing an RFC because it would be a great standard to use. [0] https://www.npmjs.com/package/base65536 https://www.npmjs.com/package/base65536