Live data from Hacker News

Why your password can’t have symbols—or be longer than 16 characters

arstechnica.com

21–30 of 75 posts

Re: Why your password can’t have symbols—or be longer than 16 characters

#21

I found this very strange The permitted characters and length for passwords are defined as a regular expression in Evernote’s API, but spaces are left out, Evernote says, because leading and trailing spaces presents a problem. “Software needs to precisely determine how to treat leading and trailing spaces,” Dave Engberg, Evernote’s CTO, told Ars. “Some UI frameworks and third-party applications would unreliably trim…

I assume the problem is related to space-handling on HTML form submission. I don't know off-hand how POST handling differs, but for forms submitted by GET, spaces get all screwed up and it wouldn't surprise me if some or all browsers automatically trimmed leading and trailing spaces, and it also wouldn't surprise me if various JS libs took varying approaches to compensating for this weirdness.

Re: why you'd have a regex for validating passwords, I assume this is in the password setting user interface, so you can give the "hey that password doesn't meet the requirements" feedback without waiting for a round-trip to the server.

Edit: the real frustrating thing about this article is that it doesn't actually answer the question in the title, and nobody seems to care. Yeah, Microsoft, great point: longer passwords may not actually be more secure, but prohibiting them causes your users problems if they've developed a nice consistent scheme for generating their passwords and have to have a special exception for your dumb site that limited the length for no good reason.

Re: Why your password can’t have symbols—or be longer than 16 characters

#22
post #16

It's not that they don't care, they are managing support headaches, and balancing risk to reward. 6 Character AlphaNumeric for Schwab is because they use the same password for phone, and this is a throwback to a "Pin". They could at least be honest that this is why it is what it is. The Fobs they send that generate a random number to go with your login make this not a deal breaker for me. Microsoft is balancing suppo…

Hashing passwords intentionally slow for security. The solution to a DOS like this is to ignored all password attempts after N per M time.

That's like saying to get someone to stop punching you, just punch yourself.

DOSing yourself to stop a DOS :/

Re: Why your password can’t have symbols—or be longer than 16 characters

#23
post #9

A third user thought the length limit suggested that the company may then be storing the password themselves rather than hashing them This was my first thought at well, and none of the examples in the article refute it satisfactorily. Is there any point at all to capping the maximum length? Are sites worried that if the 64-character limit is lifted, 64+ character passwords will become common, leading to a bad user ex…

Well to be fair, there really is zero point from a security point of view in having a password longer than 64 characters. If someone does enter more than 64 they almost certainly have made a mistake (a copy-paste screw up for example).

And you do need some kind of limit to prevent people using gigabyte sized passwords.

Re: Why your password can’t have symbols—or be longer than 16 characters

#24
A favorite example from personal experience that boggles the mind and helps explain things:

A core financial platform used by many many hundreds of financial institutions in the US offers "encryption" of the online banking password, which is stored in the core DB. (Most of the times, the core system -- which records how much money you have, your txn history, &c -- is separate from other auxiliary functions like online banking, and the two are joined with some sort of gateway.)

The encryption scheme was taking the password, and doing a byte-wise conversion to EBCDIC for that field. It was trivial to reverse with a one-line TCL query, but appeared encrypted to the casual observer.

Brittle security theater, but probably allowed this company to hold their nose and mark off a "data secured at rest" checkbox somewhere.

The encryption of the data transfered between teller workstations and the core was just as laughable -- XORed against a key sent to the client in plaintext at the beginning of the session. You didn't even need the key to break it -- using static strings or frequency analysis would suffice.

Re: Why your password can’t have symbols—or be longer than 16 characters

#25
I would bet 99% of this is legacy support. Someone in built an entire system over assuming the password is CHAR(6).

Unfortunately these fixes aren't always as easy as updating the column and introducing salt/hash. The system could be sending the password in plaintext to multiple sub-systems, it could be used for VOIP services, it could even be used by CSRs to manually update settings on behalf of a user, even better, they might be extracted and emailed as attachments to partner companies. I've seen all of the above done with passwords. Fun stuff.

Re: Why your password can’t have symbols—or be longer than 16 characters

#26
post #14

The only line of reasoning in the article that seems somewhat convincing to me is Microsoft's point that stronger passwords don't prevent phishing, malware, or compromise via another site (and I'm not sure about the third one -- I guess it's true if the other site is storing passwords in the clear, but if they're hashed, I'd think stronger passwords would be harder to get using rainbow tables). But even if it's true…

"Evernote's reason seems more like an admission of a technical debt than any kind of defense." Our eyebrows are only raising because an article with a strong focus on passwords was written and they saw fit to include this tidbit. In isolation I doubt any of us, including the developers of this particular little thing, sees it as something worth caring about. The point about leading or trailing spaces is definitely tr…

There's no technical reason for this. It's all about reducing their support burden. I wish they'd just be honest.

Re: Why your password can’t have symbols—or be longer than 16 characters

#27
Assuming they salt each password before hashing it and use a reasonable number of iterations, having relatively short password should not be a huge deal, right? The salt means that an attacker can't just use a rainbow table attack against a single password. In the event that an attacker does get ahold of all the hashes and salts, they would still have to brute-force each individual password.

Though I suppose having a maximum password length of 6 might correlate with not using other best practices, like salting the hashes...

Re: Why your password can’t have symbols—or be longer than 16 characters

#28
post #9

A third user thought the length limit suggested that the company may then be storing the password themselves rather than hashing them This was my first thought at well, and none of the examples in the article refute it satisfactorily. Is there any point at all to capping the maximum length? Are sites worried that if the 64-character limit is lifted, 64+ character passwords will become common, leading to a bad user ex…

Well to be fair, there really is zero point from a security point of view in having a password longer than 64 characters. If someone does enter more than 64 they almost certainly have made a mistake (a copy-paste screw up for example). And you do need some kind of limit to prevent people using gigabyte sized passwords.

Most people using 50+ character passwords or phrases often use password management software like 1Password, Keepass, or browser-based, etc.

I do think an upper limit is valid, as allowing an arbitrary long string could be a form of DOS (imagine someone sending the library of congress as a password), but 64 characters seems kind of weak.

Re: Why your password can’t have symbols—or be longer than 16 characters

#29

The only line of reasoning in the article that seems somewhat convincing to me is Microsoft's point that stronger passwords don't prevent phishing, malware, or compromise via another site (and I'm not sure about the third one -- I guess it's true if the other site is storing passwords in the clear, but if they're hashed, I'd think stronger passwords would be harder to get using rainbow tables). But even if it's true…

> if users don't like entering certain characters on a mobile phone, they can pick a different password

Fundamentally, I don't think it's unreasonable to try to protect users from themselves.

Post reply on HN