Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What technical reasons are there to have low maximum password lengths?

security.stackexchange.com

Post reply on HN
Print view View original

121–128 of 128 posts

Re: What technical reasons are there to have low maximum password lengths?

#121

Post by just2n »

drostie wrote: post #83
just2n wrote: post #53

Earlier quoted context omitted.

I didn't mean to imply that you'd just store the hash the client comes up with. That's idiotic, of course. Not everyone uses SSL, even though they should, and it's not always secure, and even with the use of SSL, it seems that there would be a potential length attack that could be employed to effectively guess a user's password length. So in all cases, IMO, it makes more sense to be receiving a fixed-length thing tha…

Here is the attack scenario: Alice is trying to login to server Bob, but her WiFi access point Eve is running a protocol-mismatch attack: Alice communicates to Eve by HTTP, which Eve records and then transmits to Bob by HTTPS. We'll assume that Eve does not inject her own scripts but just eavesdrops on the conversation. Your problem: clientHash is "password-like" and Eve can use it to log in. One solution: use the HT…

Thanks for explaining that.

So sitting here trying to think about a way to solve that problem, what I come up with is essentially PKI. But if the attacker has the ability to inject code, they can always break this entirely by stealing my private key.

This feels to me like URLs are fundamentally broken, in that a user might try to go to http://mybank.com. Is there any secure way to get their browser to redirect to https://mybank.com? It seems like there might be something that could be done with dnssec, but that feels brittle too. Gross.

Re: What technical reasons are there to have low maximum password lengths?

#122

Post by throwaway125 »

throwaway125 wrote: post #85

For how much people like to repeat the "Use bcrypt!" mantra I'm amazed no one has mentioned the password length limit of bcrypt. The hash output of bcrypt stops changing after 72 characters but almost all bcrypt documentation mentions a 55 character limit. I'm not quite sure what that is about, can anyone clarify?

To clarify I never meant that the limit is a security issue, just that it's a valid technical limitation to limit the length of a password.

Re: What technical reasons are there to have low maximum password lengths?

#123

Post by stouset »

just2n wrote: post #121
drostie wrote: post #83

Earlier quoted context omitted.

Here is the attack scenario: Alice is trying to login to server Bob, but her WiFi access point Eve is running a protocol-mismatch attack: Alice communicates to Eve by HTTP, which Eve records and then transmits to Bob by HTTPS. We'll assume that Eve does not inject her own scripts but just eavesdrops on the conversation. Your problem: clientHash is "password-like" and Eve can use it to log in. One solution: use the HT…

Thanks for explaining that. So sitting here trying to think about a way to solve that problem, what I come up with is essentially PKI. But if the attacker has the ability to inject code, they can always break this entirely by stealing my private key. This feels to me like URLs are fundamentally broken, in that a user might try to go to http://mybank.com . Is there any secure way to get their browser to redirect to ht…

HTTP Strict Transport Security solves this.

Re: What technical reasons are there to have low maximum password lengths?

#124

Post by just2n »

stouset wrote: post #123
just2n wrote: post #121

Earlier quoted context omitted.

Thanks for explaining that. So sitting here trying to think about a way to solve that problem, what I come up with is essentially PKI. But if the attacker has the ability to inject code, they can always break this entirely by stealing my private key. This feels to me like URLs are fundamentally broken, in that a user might try to go to http://mybank.com . Is there any secure way to get their browser to redirect to ht…

HTTP Strict Transport Security solves this.

That only works if the user makes an https request first.

Say the URL is: https://mybank.com, but I go to http://mybank.com, and I haven't been there yet, so the STS rule isn't in my browser. How can a user reliably be switched to https without risk of having the connection hijacked by someone injecting code to the user?

Re: What technical reasons are there to have low maximum password lengths?

#125

Post by drdaeman »

icebraining wrote: post #118
drdaeman wrote: post #80

Earlier quoted context omitted.

And if you have SSL anyway, why use passwords when you can use certificates?

Because users don't understand certificates?

They didn't understood many other form of credentials either (like OpenID), but sites educated them and now they do.

Re: What technical reasons are there to have low maximum password lengths?

#126

Post by icebraining »

drdaeman wrote: post #125
icebraining wrote: post #118

Earlier quoted context omitted.

Because users don't understand certificates?

They didn't understood many other form of credentials either (like OpenID), but sites educated them and now they do.

They do? Are you sure of that?

Re: What technical reasons are there to have low maximum password lengths?

#127

Post by drdaeman »

icebraining wrote: post #126
drdaeman wrote: post #125

Earlier quoted context omitted.

They didn't understood many other form of credentials either (like OpenID), but sites educated them and now they do.

They do? Are you sure of that?

That depends on who the site's audience are and how the login UI's done. Fairly tech-savvy visitors certainly do understand OpenID and alike. At least, I strongly believe so. Well, more casual audience probably don't.

However, my bank uses X.509 certificates to authenticate users over Internet. Out of curiosity, I've asked bank employee once and was told that most users do manage their certificates just fine, without any issues. Obviously, bank provides short and simple manuals, which explain how to generate a certificate request, obtain a signed certificate (by visiting bank in person), authenticate and renew expiring certs.

(My bank's not using in-browser PKI due to legal reasons and provides a small piece of software wrapping around the browser, but that doesn't really matter.)

Re: What technical reasons are there to have low maximum password lengths?

#128

Post by eru »

randomdata wrote: post #103
mistercow wrote: post #91

I actually emailed my credit union, pleading for them to increase their 10 character limit to something reasonable, and got a response saying that the way their database handles passwords made it impossible. Needless to say, I found that to be even more disconcerting than the existence of the character limit.

My credit union enforces similar limits (and only 0-9 are valid characters), but I realized the validation was only enforced in Javascript. I disabled the validation and I was able to use any password I wanted.

Did you try any SQL injection attacks?
Post reply on HN