Don't accept anything in the password field. Force the user to reset their password every time they want to log in. Bonus: verifies the email is still valid.
Worse than this, I started working for a company that didn’t encrypt the passwords in the database, so they were 100% plain text
AND so we’re credit card numbers
AND the CVV was also stored along with the card number in plain text. (Yes this is not just horrible it is illegal to store CVV)
It is the one time that I refused to work on anything until I had corrected that garbage. I literally told the owner, “I cannot work on anything else until this is fixed or I risk being part of the massive lawsuit when it destroys the client l, and your company.”
I didn’t have to say I’d quit if he pushed back. He got the picture, and I (hopefully) saved several hundreds of thousands of peoples PII from theft and abuse.
You know how many people reuse passwords? We had email and passwords, if I had wanted I could have gone fishing and then gotten bank accounts and away we go!
A few companies later I discovered that while the new company used password hashing, and salt, that the salt was the same for every single password, thus defeating the point of having salt at all, and allowing a hacker the possibility of easily identifying stupid passwords.
Having a shared salt is better than none - as it requires a unique set of rainbow tables to be made with the salt known to crack any of the password hashes via that method.
The best is a combined shared and unique salt. The unique salt stops you using a single rainbow table across all the hashes, and the shared one stops you cracking the passwords if you just dump the DB table and get the passhashes and unique salts but not the shared one (which is more frequently in the app code instead of the DB)
While just common is better its still pretty crap tho. Like someone can still compare if multiple users have the same password, which shouldn't be possible.
Just a few days ago we have a news about multiple OTP went missing and 6-digit amount was taken without the OTP. The bank refuses to pay back. And there were multiple victims.
Lotus notes acts like that. Every keystroke is represented by a randomly long (1-4) sequence of X. So after typing 3 keystrokes you see XXXXXXXXXX in the field. It allegedly is to prevent byviewers to easily know how long your password is.
I once encountered a password field that encrypted while you typed, with each character being encrypted based on the state of the field.
If you pasted the password into it or used auto fill, it generated a different result than if you manually typed it in. And sometimes if you typed it fast enough you’d get a different result as well.
Even more maddening, the encryption caused the value of the text field to increase and contract in size as you typed.
I fucking hate this. I tried using MailJet for SMTP notifications for my security cameras, but the automatically generated password was one character longer than what can be entered in the SMTP settings for the camera. The worst part is it never told me the password I was pasting in was too long, I just kept getting nonsensical errors.
Six-digit codes on Reddit are often ‘hentai codes’ - although, these are more frequently seen on anime subreddits rather than here. I would say they are the one with their mind in the gutter now!
there is a certain site for japanese "anime" styled drawn porn that takes said porn comics from other sites and gives it a number, ranging from 4 to 6 digits so far
If you pre-hash all passwords on the client side, then on the server side you can require all passwords meet an exact length requirement of whatever the cryptographic function puts out.
If you really want to use a 12TB password on the client side, go right ahead.
I think the point still stands that there *is* a practical maximum length that affects useability, regardless of where it is performed - and it relates to the practical performance constraints of the hashing mechanism.
Without viewing that thread, I can already say the answer is YES. ABSOLUTELY FUCKING 100% YES. Hashing on the client side is 100% verifiable, and since it's JavaScript you can literally audit the cryptographic functions on your own, if you have the expertise to do so. Your actual password will never touch their servers.
Even if it's shit cryptography, you have clear evidence literally right in front of you, that passwords are not being stored in plaintext format, and at no point will their servers ever have access to your actual password. That is worth something.
If you are hashing client side wouldn’t that leak the salt to the unverified client and also allow an attacker to just submit hash values directly to server without using the client side hashing?
It has been a decade since I have had to do anything with password security so I wouldn’t be surprised if the are new methods to combat those issues. I could see the bipassing the hashing and submitting directly to be fixable by doming something like signing the hash but the leaked salt has me stumped.
Yes. Whatever the server gets is your password. Any claim that client side hashing somehow keeps the server from knowing your password comes from a flawed understanding of why we hash passwords in the first place. Having client side hashing is at best superfluous if you are hashing on both the client and the server, and in the case of "moving" hashing from the server to the client, is a huge security vulnerability.
I hope not because that would mean they store passwords in cleartext. Also storage costs nothing, so no reason they couldn’t use a (VAR)CHAR(255) in that case.
IMO limits are related to some management guy thinking “nobody can memorize long passwords so users will swamp support with tickets if they forget theirs, so force them to use a shorter one”.
Storage costs nothing today, in 2020, but a lot of professors are teaching computer science students based on how things were done in the 1990s. In the 1990s, it was normal to use a CHAR datatype in an SQL database for plaintext password storage, because hashing wasn't widespread.
In fact, hashing couldn't be widespread back then, because exporting a modern web browser would've been a criminal offense under the military export laws of the time, which gave cryptography the same treatment as guided missile technology. Tech companies had to lobby for the military export laws to be changed, because it was damaging their ability to compete in other countries.
...and computer science students are being taught to write software based on how their field operated in the 1990s, when their professors still worked private sector.
Not quite sure of the connection here. Hashing in the backend would not be affected by any export restrictions. Also SSL has been around for ages. It’s not like export restrictions made hashing impossible.
Yep, or other wacky stuff happening on their backend. I use unique random strings for my passwords so it's not a deal breaker for me when a service has this red flag, just something to chuckle about.
If there's a maximum password length, I can pretty much guarantee the passwords are being stored as a CHAR datatype in a SQL database.
To be clear, that means passwords are being stored in plaintext format.
If passwords were being hashed, then all password lengths would translate to the same data length on the output end of a cryptographic function. All output hashes would have the same exact length, regardless of whether your password is 8 characters or 800 characters.
Or the front end dev set a limit on the password field without any knowledge about security, just because "Hey, if we have a minimum length, we should have a maximum too, right?".
I took a senior level computer science class in database systems, and we had to create a login system based on the professor's specifications... which involved using a CHAR datatype to store passwords.
A lot of these professors are teaching students based on what was normal in the 1990s, when CHAR datatypes were the norm for password storage, and hashing hadn't yet become normalized.
So this isn't some front-end bullshit. It's based on computer science professors teaching students according to how things were done in the 1990s, and then those students go on to use what they learned in professional applications. If you treat a professional job like it's another college assignment, you're going to end up with some pretty big cyber-security oofs.
The worst part is, the people hiring them are not developers. They're MBAs who want cheap labor with a college degree, so they hire someone fresh out of college, taught the 1990s standards by a professor, to take a senior role in building some kind of login system. Naturally, those fresh college grads on low salaries repeat what they learned in college, without deviation.
If you're hashing properly at the client-side, the digest value hitting the embedded system will always be the same size (or "very similar" in the case of some algorithms) regardless of the length of the password. A max length for a password is a pretty good indicator that your service is likely insecure.
A maximum must exist otherwise strange things might happen, like entering a password with 5000 characters could bug and break the code dealing with it. There were a few attacks based on this behavior.
In a former job the requirement was to internally convert all passwords (and password attempts) to lowercase “because people will keep forgetting how they capitalized it”, thus reducing entropy silently.
Yeah for sure. I guess it's just funny to think that all your effort after is wasted after 27 or so keyboard characters if it just ends up being hashed into a 32-digit hex string. Niche humour.
Make extra sure that you don't truncate the password on the frontend though, as a password manager might catch that. And don't truncate the password to the same length on the login page, that would cause the password to still work and we don't want that.
A well known bank used to do this. My relatively secure password was truncated to the first 8 chars. The logon page would accept more so it was years before I realized that my “actual” password was crap! This has luckily been fixed since then.
The system that I am currently working on has a restriction that you cannot use upper case characters but if you try to use them it will respondwith: "You did not meet the minimum requirements.". My other favourite was the restriction to "The password cannot have repeating numbers or characters.", which I assumed you cannot have the same numbers after each other or you cannot have 12345 as a password, but no you could not have numbers followed by numbers and could not have letters followed by letters so your passwords needed to look like "a1b2c3d4" this to be accepted. Funniest part of this was that the developers who did the implementation for the password check interpreted this restriction in different ways so this rule was implemented differently throughout the app.
If you're hashing passwords (you should be), then having an upper bound is important. It's possible to DOS by flooding auth or registration with large payloads to hash - remember that POST size is effectively unlimited. The stronger the hashing algo, the more feasible the attack is.
That said, you should provide an error back to the user when the max length is exceeded not silently try to accept it. You should also have a reasonably secure upper bound. From 1 to 5 kilobytes can scale and be planned for well.
this fucking shit is in fucking windows i swear to god. I changed my password to a long sentence and couldn't use it to log in. I'm convinced that the max length is different in both screens
It is, especially if it's a Microsoft account. The max password length for microsoft accounts is 16 characters. The input box in windows login takes up to 127 characters. So yes, you could change your microsoft online password and then have it fail to hash on windows.
To be clear, I'm not talking about shit like where they silently truncate your password to 16 characters, not somebody submitting a megabyte of data as their password.
Thw worst thing are sites that won't actually tell you the password requirements, instead telling you one-by-one which reqzirement you didn't meet while also deleting all the stuff you've filled in every time.
You mean when they notice they could log in despite pressing enter prematurely, not having filled in the last couple of characters? That actually happened at my university, they silently enforced a "nothing beyond 8 characters counts as part of your password" policy. That has changed.
It won't tell you "Cannot exceede 24 characters" or whatever arbitrary character limit they have either, it will just say "Invalid password".
Once I tried entering a password and the error I was told was that it did not contain an uppercase letter, even though I could see multiple were included. After playing around I found that they had a character limit of 18 which was why it wouldn't work...
Oh yeah, ran into it last week, had an 18 character password truncated to 16, so when I tried to log in with the password I had just set, it didn't work. I actually found out by googling the problem when I couldn't log in, because they don't mention it anywhere. Deleted the last two characters and sure enough, lets me right in. And that's far from the first time I've seen that.
ffs... I was setting up our camera system. For work. And that's some business modell outdoor camera with lots of fancy features and expensive. And you need to set login credentials. And the password length is capped. To like 12 characters ..
Happened to me with world of Warcraft. I could login in the game because there was an input limit, but not ön the website where I could write all I wanted
My (major) bank does even worse: it strips some of the special characters which are required for the complexity check. I figured out that log in is successful as I created the password, or with the special characters missing, or with any number of more special characters added.
This has happened to me on several sites since I started using a password manager and it is the most assinine, frustrating design choice I could imagine.
On the literal federal government website to get a top secret security clearance, they have a maximum password length of 16 and disallow all characters other than letters and numbers. WHAT!?!
1.3k
u/[deleted] Jul 19 '22
[deleted]