Who do we lobby to get them to fail their next PCI-DSS compliance test?
Don't Fuck With Paste: https://chrome.google.com/webstore/detail/dont-fuck-with-pas...
(And yeah, the "internet random" here has a github repo with the code, and the file that does this is an easily auditable 16 lines of javascript, so props to him for that. But it's still got the recently exploited attack vector that he or an attacker who takes over his account could push malicious updates to the extension, like the webdev extension from earlier this week...)
Might happen in the next version release.
At least one bank says the pin is "for this device" but then accepts it on new iOS devices too (without ever prompting for the "real" password on the new device).
(I occasionally worry that my phone's bitcoin wallet does not do this. There is occasionally a large enough balance in there that I'd really like to have to touchid to open it and transfer those bitcoin out... Not quite worried enough to investigate whether other wallet options do it, but sometimes I hand my phone to someone to show them a pic and think "Do I _really_ know this person well enough to trust they won't poke around my phone and try to distract me enough to swipe some bitcoin???")
The password you create here can be used to access Online, Mobile and Telephone Banking.
All passwords must be six characters in length. Special characters (eg. *, %, $, etc) will not be accepted.It may sound archaic but you have to raise the visibility if you're concerned about changing the banks behavior.
"No length restriction on passwords" is a common and valid report on HackerOne, because servers that do store passwords securely can be DoSed by someone providing a long password and forcing the server to hash it.
I doubt there's anyone who can make a strong argument that "64 characters isn't enough", and I doubt even intentionally computationally expensive password hashing is going to end up with significant resource usage with 64 or 128 character strings. I wouldn't want my shared hosting WordPress site with a password plugin to need to calculate the bcrypt hash of the entire text of War And Peace, bit I suspect the difference between bcrypting "password123" and a random 64 or 128 character string is insignificant enough to be ignored (but I've never tried benchmarking it, so I'm open to changing my mind here if anyone has links to benchmarks that show otherwise...)
Login attempts (should) get rate limited independently of password length limits, which makes the difference between hashing 8 characters and hashing 72 characters even less meaningful.
If you're working in an environment that has a FaaS (AWS Lambda, etc), it may be worthwhile to have this as an async function call so as not to block your primary application. Another option is to break authentication into its' own application, and have that return a signed auth token to your application.
There are lots of options.
Look, people on HN make a massive deal about passwords. One of my most shocking discoveries starting as a pentester was that "storing passwords in plaintext" would be a low-severity finding at best. Medium through critical vulns are reserved for findings that can own an app. That's how little password storage matters.
If you're relying on UPS preserving the secrecy of your 21-character master password that you're using across all your websites, you're doing it wrong. Yet the vast majority of users will do exactly that. The way to protect them is for critical services to use 2FA, which they do -- email, phone, insurance, etc all use 2FA or separate 4-digit passcodes now (USAA).
There have been so many password database leaks, yet the world moves forward. What is unacceptable is for Blue Cross to leak all your PII, yet the world moved on from that. CloudFlare leaked a huge amount of sensitive info. All of those matter way more than some password leaks.
If someone is going to target you, here's the most likely method: https://news.ycombinator.com/item?id=14919845
I suspect that's because you're viewing the situation as a pentester not a user. A plaintext password (on its own) doesn't do a pentester much good until they've already gained control of the system. However, once someone has control of the system then plaintext passwords are a threat to users because a lot of people are vulnerable to common password reuse.
(This application has had three failed rewrite/replace projects over the last 10 years. They're now onto their fourth one, and they're running 32 months over deadline on a "2 year" project timeline...)
With a limitation of 27 characters it's not possible to make my password be "if i forget this i'm in a lot of trouble".
I then entered {DELAY 3000}{PASSWORD}
Now I can log in to a full screen game that doesn't allow pasting (I type in the username by hand first). If I'm alt-tabbed out of the game with KeePass in focus, the three second delay is enough time to go from triggering auto-type to restoring the full screen game window and clicking on the password field to give it focus. I was unable to trigger KeePass autotype with the game already full screen.
If the account you're trying to log in to also has a long random username that needs to be auto-typed, you'll probably want a sequence like "{DELAY 3000}{USERNAME}{TAB}{PASSWORD}". Or, if the form doesn't allow you to tab from the username to the password field, you could use "{DELAY 3000}{USERNAME}{DELAY 3000}{PASSWORD}" and you can click on the password field during the second delay.
If that conversation starts off at 1000 characters you're fine, but more often then not it looks more like:
"Make the requirement 8-12 characters"
"12 is too short"
"fine make it longer, like"
"Ok" [18 char implementation]
"Hey, Bob in accounting says he uses 20 char passwords"
"Fine, bump it by another 50%"
[27 char implementation]
[no further internal complaints]
[Specs never updated or reviewed again]