20 ms·

Passwords are sent to the server though in most cases. So there must be some limit.

mcny 3y ago
What should this limit be? Personally, I think the limit should be nothing smaller than a thousand characters. Or even allowing something like a hundred characters or more would be better. I remember at some point Hotmail had a maximum length limit of sixteen characters. https://arstechnica.com/information-technology/2012/09/secret-microsoft-policy-limited-hotmail-passwords-to-16-characters/ https://arstechnica.com/information-technology/2012/09/secre...
- AtNightWeCode 3y ago
  256 is fine in most user scenarios. No one will type in more chars than that anyway. And if a pw manager is used the length is not really a problem. For services there are often better alternatives.
- falcolas 3y ago
  100Kb is a perfectly reasonable length IMO. Only takes seconds to send even over terrible links.
  - iLoveOncall 3y ago
    It becomes problematic when it needs to be hashed, you can essentially DDOS servers by sending extremely long passwords that need to be hashed.
    - falcolas 3y ago
      Realistically speaking, the hash would be your smallest problem if you're being DDoSed. Bcrypt for example would require at most ~6.4Mb of memory to do the hash, and more realistically only the 100k plus some constant. And modern CPUs are pretty efficient at doing the encryption steps, meaning little additional load for encrypting a larger value.
      - AtNightWeCode 3y ago
        [flagged]
        dang 3y ago
        Attacking another user like that will get you banned here. No more of that, please. If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.
    - tracker1 3y ago
      Part of why I prefer to have authentication on a separate server... if it gets ddos'd at least existing sessions can carry on.
TedDoesntTalk 3y ago
A few MB is acceptable for https POST these days. This gets hashed down to 64 chars or whatever.
- AtNightWeCode 3y ago
  Are you aware of that secure pw hashing comes with a cost factor and that the cost is linear with the size of the input to the hashing algorithm? EDIT: Down voters. What pw hashing algo are you using instead of BCrypt or similair?
  - ndriscoll 3y ago
    I'm not particularly familiar with this stuff, but aren't the cost factors for hash algorithms essentially the number of times to nest the hash function? i.e. `hash(hash(hash(hash(hash(input)))))` type of thing. So it would cost more, but only for the first round? After that the size is reduced to the size of the image of the hash for future rounds? That said, a few MB is a lot for one client to post if you have a significant amount of traffic. Just hash client side first.
monsieurbanana 3y ago
Yes but that's not what they're discussing, it's about the sites that have some low limit like 8-16 characters. And if someone knows why banks are specially prone to having crapshit password requirements... Flashback to my french bank that had a password that needed to be exactly 8 digits, no letters or other, and that you could only type by clicking on a digital numpad that had the numbers randomly sorted.
- tracker1 3y ago
  Interconnected old mainframe systems fwiw... In the end, a lot of these banking systems are connected back to mainframe systems with a LOT of legacy cruft that nobody has the nerve to actually update. It may not even be hashed or encrypted, which is part of why banks also add a second factor/cookie, though the implementation could/should be better.
michaelt 3y ago
If you don't let your users upload a 3GB Shrek dvdrip as their password, do you even care about security?
- AtNightWeCode 3y ago
  What? I always use my daily backup of the Internet as the pw every time I sign up for something.
ndriscoll 3y ago
The sensible thing to do here is hash the password before sending it, not impose a character limit on the field. Ideally, browsers could even support this directly as part of the input element if they weren't busy adding things no sane person wants like webUSB or browser notifications.
- AtNightWeCode 3y ago
  It can easily be done with WASM. You could even add the domain as a salt.
- TedDoesntTalk 3y ago
  They do support it directly. There has been a WebCrypto API with carrots hashing algorithms for years.
  - ndriscoll 3y ago
    You can do hashing in javascript, but I mean something more like <input type="password" hash="sha-256" /> By default, salt with the domain. Have an optional `hash-domain` attribute to override it if needed. Have an optional hash-extra-salt field that you can use to target e.g. a username input. Make it quick and easy to do the right thing, and for a linter to check that you did the right thing (e.g. warn if a password input is missing hash options). For all the development that goes into browsers, HTML is really missing some basic stuff that tons of people need. Stuff like this or e.g. graphs. Why do you need to pull in huge javascript libraries and write code to draw a line chart? Why is drawing a pie chart harder than making a table? In contrast, I can think of literally 0 websites that could even come up with the most contrived reason to need USB. The best I can think of is some incredibly bespoke CAD thing that uses a hardware dongle for DRM, and then why isn't it just an actual application? Why would the enablement for that go into a web browser? Or the vibration API. Or the sensors API. Who in their right mind would ever want these things to even be possible for websites to use? You know instantly that they will only be abused. Why is WHATWG working on this stuff and not taking common reasons people reach for javascript and adding standardized, declarative versions into HTML?
tracker1 3y ago
I wrote an authentication platform a few years ago... I had a setting to allow a max passphrase length (because it was a govt requirement for a client), but if unset, it would be 1024 as a pragmatic limit on the payload (considering the hash length was less), I always thought that was reasonable.

mcny 3y ago

What should this limit be? Personally, I think the limit should be nothing smaller than a thousand characters. Or even allowing something like a hundred characters or more would be better. I remember at some point Hotmail had a maximum length limit of sixteen characters. https://arstechnica.com/information-technology/2012/09/secret-microsoft-policy-limited-hotmail-passwords-to-16-characters/ https://arstechnica.com/information-technology/2012/09/secre...

AtNightWeCode 3y ago
256 is fine in most user scenarios. No one will type in more chars than that anyway. And if a pw manager is used the length is not really a problem. For services there are often better alternatives.
falcolas 3y ago
100Kb is a perfectly reasonable length IMO. Only takes seconds to send even over terrible links.
- iLoveOncall 3y ago
  It becomes problematic when it needs to be hashed, you can essentially DDOS servers by sending extremely long passwords that need to be hashed.
  - falcolas 3y ago
    Realistically speaking, the hash would be your smallest problem if you're being DDoSed. Bcrypt for example would require at most ~6.4Mb of memory to do the hash, and more realistically only the 100k plus some constant. And modern CPUs are pretty efficient at doing the encryption steps, meaning little additional load for encrypting a larger value.
    - AtNightWeCode 3y ago
      [flagged]
      - dang 3y ago
        Attacking another user like that will get you banned here. No more of that, please. If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.
  - tracker1 3y ago
    Part of why I prefer to have authentication on a separate server... if it gets ddos'd at least existing sessions can carry on.

TedDoesntTalk 3y ago

A few MB is acceptable for https POST these days. This gets hashed down to 64 chars or whatever.

AtNightWeCode 3y ago
Are you aware of that secure pw hashing comes with a cost factor and that the cost is linear with the size of the input to the hashing algorithm? EDIT: Down voters. What pw hashing algo are you using instead of BCrypt or similair?
- ndriscoll 3y ago
  I'm not particularly familiar with this stuff, but aren't the cost factors for hash algorithms essentially the number of times to nest the hash function? i.e. `hash(hash(hash(hash(hash(input)))))` type of thing. So it would cost more, but only for the first round? After that the size is reduced to the size of the image of the hash for future rounds? That said, a few MB is a lot for one client to post if you have a significant amount of traffic. Just hash client side first.

monsieurbanana 3y ago

Yes but that's not what they're discussing, it's about the sites that have some low limit like 8-16 characters. And if someone knows why banks are specially prone to having crapshit password requirements... Flashback to my french bank that had a password that needed to be exactly 8 digits, no letters or other, and that you could only type by clicking on a digital numpad that had the numbers randomly sorted.

tracker1 3y ago
Interconnected old mainframe systems fwiw... In the end, a lot of these banking systems are connected back to mainframe systems with a LOT of legacy cruft that nobody has the nerve to actually update. It may not even be hashed or encrypted, which is part of why banks also add a second factor/cookie, though the implementation could/should be better.

michaelt 3y ago

If you don't let your users upload a 3GB Shrek dvdrip as their password, do you even care about security?

AtNightWeCode 3y ago
What? I always use my daily backup of the Internet as the pw every time I sign up for something.

ndriscoll 3y ago

The sensible thing to do here is hash the password before sending it, not impose a character limit on the field. Ideally, browsers could even support this directly as part of the input element if they weren't busy adding things no sane person wants like webUSB or browser notifications.

AtNightWeCode 3y ago
It can easily be done with WASM. You could even add the domain as a salt.
TedDoesntTalk 3y ago
They do support it directly. There has been a WebCrypto API with carrots hashing algorithms for years.
- ndriscoll 3y ago
  You can do hashing in javascript, but I mean something more like <input type="password" hash="sha-256" /> By default, salt with the domain. Have an optional `hash-domain` attribute to override it if needed. Have an optional hash-extra-salt field that you can use to target e.g. a username input. Make it quick and easy to do the right thing, and for a linter to check that you did the right thing (e.g. warn if a password input is missing hash options). For all the development that goes into browsers, HTML is really missing some basic stuff that tons of people need. Stuff like this or e.g. graphs. Why do you need to pull in huge javascript libraries and write code to draw a line chart? Why is drawing a pie chart harder than making a table? In contrast, I can think of literally 0 websites that could even come up with the most contrived reason to need USB. The best I can think of is some incredibly bespoke CAD thing that uses a hardware dongle for DRM, and then why isn't it just an actual application? Why would the enablement for that go into a web browser? Or the vibration API. Or the sensors API. Who in their right mind would ever want these things to even be possible for websites to use? You know instantly that they will only be abused. Why is WHATWG working on this stuff and not taking common reasons people reach for javascript and adding standardized, declarative versions into HTML?

tracker1 3y ago

I wrote an authentication platform a few years ago... I had a setting to allow a max passphrase length (because it was a govt requirement for a client), but if unset, it would be 1024 as a pragmatic limit on the payload (considering the hash length was less), I always thought that was reasonable.