Is it fine if a website says "email already in use" before you hit submit?
from Jankatarch@lemmy.world to cybersecurity@sh.itjust.works on 08 Aug 22:14
https://lemmy.world/post/34159586
from Jankatarch@lemmy.world to cybersecurity@sh.itjust.works on 08 Aug 22:14
https://lemmy.world/post/34159586
I remember hearing before that it’s a sign they are storing your info unencrypted but I never checked.
Is this true? I was logging into a .gov website and noticed it does that.
threaded - newest
I don’t think many places encrypt/hash email addresses, but even if they did they could just apply the hash algorithm to what you entered to compare the hashes.
So ultimately hashing an email address could be a good thing, but its a matter of half measures. Sure, you can perform a basic hash before putting it in the database, but if we assume hashing is performed to prevent it being read by an attacker, why bother unless youre doing it properly?
Passwords, being more sensitive, should only be compared once finished being entered, so you can afford to run all the hashing, salting etc that is a requirement to keep the passwords safe.
If you were going to hash the email to the same standard, it becomes harder to retrieve and display, so when the user wants to look at their profile in the ui, you have to run an intense cryptographic algorithm just to display the email. Or if you want to contact the customer, or any other use for their email. Hence, people dont bother.
Hashing is completely irreversible. You cannot hash an email address and then unhash it. At most you can brute-force guess the email until the hash matches, but this is basically impossible.
Hashing the email address would break one of the main reasons to use an email address - the ability to send emails to users.
Encrypting email addresses is fine, but you wouldnt compare the encrypted data, you’d just decrypt and compare the original email address.
Man, youre totally right and I now feel embarassed i forgot that.
The email can be stored in 2 parts in the database. One hashed as a login and once as an email address to send to.
Sure, if your database is compromised, it’s still public but it still makes the log in process more secure.
The only reason we store passwords in hashed form is to prevent damage from leaks. How would storing it twice make login more secure? The client sends both the email and the password in plaintext, everything else is on the server’s side. The client does not care or know how the data is stored (or if it is stored at all). So storing it twice does nothing except waste disk space.
It only helps if log in details are siloed. The storage space taken is negligible.
It’s also possible to hash client side, so that the log in process does not access data, like the email but just confirms matching hashes for received data.
Why the fuck would the client confirm the hashes? Don’t trust the client. The server handles the login; an attacker can just write a lying client “yeah sure I know this guy, it’s hitmyspot, now let me in”.
The client doesn’t confirm the hash. The client hashes and sends the hashed data. The server confirms.
Omg, how do you know my login? ;)
The client doesn’t hash. The client needs to send the plain text. Otherwise, that’s a security problem; the server needs to confirm the user knows the actual password, so the server needs to compute the hash and compare. If the client sent the hash, then there was no reason to compute hashes in the first place, because the attacker can just send the leaked hash (the reason to hash it is to avoid that the leak can be used to log in directly).
No client side hashing is possible and secure.
If you look at sending plain text under SSL, it’s almost the same thing.
The password hashed under a mutually known algorithm that is not reversible is just as good as the plaintext.
What’s particularly interesting right now is manipulation of data that is encrypted to allow the same output (encrypted) as unencrypted data.
The point of sending hashes info from the client is that each site uses a different key, even if publicly available. This means that leaked login data cannot be compared or matched across different leaks.
No, it is not. If the server accepts the hash from an untrusted source (the client), then that’s equivalent to not using hashes at all. The reason why we hash is so a database leak does not allow malicious actors to login directly. If the server accepts a hash, that means it only does
hash_from_client == hash_from_db, meaning that’s the same as doingpassword_from_client == password_from_dbin terms of security. This is because the client can just send the hash from the DB, the user does not actually need to know the password, hence your proposal is equivalent to not using hashes at all in terms of security.That is for keyed hash functions, which is not typically done for passwords (but peppers are sometimes used, which helps similarly). This does not prevent the above scenario, though, because the leaked hash can still be used on that site. Sending hashes is a bad idea, the hash should always be computed in a trusted environment to ensure the user actually knows the password.
Not saying you’re wrong, what you’re saying makes sense, but my cryptology classes describes the stages of hashed authentication the way the guy you’re replying to describes things (client sends hash of password, server compares hashes).
I’m not saying what I was taught (intro level cryptology) is correct, up to date, or into the technical weeds enough to distinguish, but can you provide a source that backs up your position?
I’m very interested in this discussion and I’d like to see an authoritative source. I can pull the book I am referencing if you’d like, let me know and I’ll find it.
I would be very interested in that book. My university did not provide explicit book sources, so I can’t tell you what that is based on, but here are the relevant slides (from page 9). Server-side hashing is so ubiquitous as the standard that e.g. OWASP cheat sheet doesn’t even explicitly say it, but their recommendations hint at it.
A quick google search on the topic revealed others with the same opinion: stackoverflow stackoverflow. The second link (accepted answer in the same thread) argues that with a protocol around it, it can make sense, but never in the situation described here. There needs to be a meaningful computation on the server’s side, otherwise the described scenario can happen.
It’s a bit difficult to find papers on that because server-side hashing is standard, but here, for example, is a paper that explores client-side hashing (see the introduction with a reference to server-side hashing and section 2): Client Password Hashing paper. Very interesting is also section 3.4. Similar paper: Client-side hashing for efficient typo-tolerant password checkers. Essentially, both suggest that to avoid the described attack, both server-side and client-side hashing is necessary (but the server-side hash can be weaker), see “Authentication attacks after leaks”. Neither paper describes how the client-side hashing is done on the Chinese websites they mention.
You’ll also find that many frameworks (e.g. ASP.NET, Laravel) implement server-side hashing.
My conclusion from the little research I did after your prompt is that client-side hashing can work, but it’s dangerous if done incorrectly (e.g. when done as suggested above), due to the scenario I described.
I appreciate your reply but I haven’t had the time to go through your links. I just wanted to mention that I appreciate it and I’ll reply in another comment when I get the chance to respond!
Anyone dealing with health information should definitely be encrypting email address; it’s one of the HIPAA identifiers.
The only thing that needs to be encrypted or hashed is the password.
But telling that an email is already in use is leaking information. A bad actor can use this to figure out if you are using a particular service, or alternatively try random email addresses and check if they belong to a real user. This is why it’s usually encouraged to just say “invalid combination of username/email and password”, instead of specifying which is incorrect.
I keep telling my team this all the time… The push back is always from the support side that says “well users complain that they don’t know what’s incorrect to fix.” and my answer is always “they got their own credentials wrong… it’s ALL incorrect. Do it over”.
But that’s “user hostile”.
"WIPE IT CLEAN. This fucking lady's getting a new account."
That's such brain dead reasoning. Only the password should be hidden - if the user can't tell whether their username is correct they need not to be using a computer...
… Well… yes… it is brain dead.
I’ve had people fail the password reset page… Apparently chrome just autofills whatever it wants and doesn’t care about websites that say NOT to autofill a field unless you declare it in some magic way that is non-standard. And our users will get a temporary password in email to let them back into the service to do a proper password reset… They’ll fail the reset because chrome autofills their old password and they’re too dumb to paste in their temp password from the email. Now the message there is a bit more vague… something like “Please check all inputs. No changes have been made.” But I’ve literally watched users on screenshare complain that “No, I put the password there! See the dots are in the box!”… No… your browser put your old password there because that’s what it knows. You need to put the temporary one there… See the words to the right of the field that say “TEMPORARY PASSWORD”? That’s where you put it.
The infuriating part is sales and support staff that are on the user’s side and make requests to devs to change it… There’s reasons that we’ve only ever had one security event in 22 years… 1) we’re lucky… 2) these rules matter.
Users are indeed dumb. Especially the 10-20% of them that hog up 80% of your support staff.
Addendum: Oh! Our users (companies) can create sub-users (workers)! So they can invite others to do stuff on their behalf/in their account. We have support staff ask us constantly to reset those sub-user accounts… Big NO. I don’t know that user and can’t validate that user. I will not be accidentally granting someone sensitive information to another person’s information. You can contact the person who gave you the account access and tell them to reset your information… make sure you enter the temp password and not your old password in the reset form… otherwise I’ll be talking to you again in about 15 minutes.
That’s why you use a reset link instead of a temp password.
We do both… The system stores PII… we’re not taking any chances.
Auto fill without user intent is infuriating. As is password managers that decide to put an overlayed frame that takes focus away.
As a user, it’s infuriating to me. I hate just about anything that changes a webpage after it’s initial load and especially anything that takes focus. (I have an extra hate for mobile sites that have a pop-up to join an email list that pulls focus and pops up my phone’s keyboard automatically too.
I’ve had it happen to me a few times on my phone that the stupid auto complete would write my email with a space after, and then the even more stupid form would take the space into account.
Took me a while to realise what was going on!
Input forms can be designed so that an email input doesn’t put a space in it. Notice the .com, .org or whatever doesn’t do that, it’s just when it’s in the username portion. Its just lazy programming to not do it.
100% why I wrote “the even more stupid form”. Someone isn’t sanitizing inputs and it drives me nuts every time.
Idk, I don’t think silently removing whitespace in the middle of the text is appropriate (though beginning and end should be stripped), but the form should warm you when there’s obviously invalid input.
Silently “correcting” input can be really annoying. For example, my SO’s first name has multiple capitals, and some forms “helpfully” split it into two words and the first name gets cut. If I know that, I can spell it without the capitals, but sometimes it doesn’t let me know and I need to call in to get it fixed.
Oh I was talking about trimming an email, if it wasn’t clear. Spaces are not valid characters so there is really no situation where they should happen. I do agree with you that an explicit message telling the user there is invalid input might be more appropriate, but if you know the correction to apply, I’d still apply it automatically (“hey we noticed you had spaces and we removed them; click here to keep them” or something)
Right, and trim is for the beginning and end. FUTO Keyboard will put spaces after periods, so it’ll frequently try to enter something like
first. Last @domain.Com. The casing isn’t an issue because emails (and all URLs) should be treated as case insensitive.I wouldn’t expect a site to remove all whitespace, only leading and talking trailing whitespace, and then present an error if the email address is obviously invalid. There are libraries for this, and I think a simple regex would also be sufficient to catch most issues (search online for a vetted one).
Spaces are technically allowed before the @, provided you wrap it in quotes. That’s incredibly rare and validating that is a bit of a pain, so I’d stick with making it an error instead of silently stripping what could be a valid, but unsupported, email address, since that would cause more confusion than an error.
I didn’t know spaces were technically allowed before the @. TIL
Technically, but yeah, it’s super rare, and most places don’t support it.
This has been something frustrating about switching to FUTO keyboard recently. Its auto space insertion isn't clever enough not to activate in username/email fields, compared to Gboard. So because many of my logins contain a period, I have to catch and remove all the extraneous spaces now.
Yeah, and it’s annoying to type e.g. or i.e. I wish it was smarter.
Sometimes the username is not whats expected. Is it the full email or just the first part of the email? Is if something generated by the system? Do you use the system often enough to remember it? Putting a “what’s my username link?” Can be helpful
Usernames can be written down or saved in a file for reference if needed. Only passwords really need to be memorized. (Password managers notwithstanding)
Crackers. Why we can’t have nice things.
User registration will still need to check if the email is the user id (which I loathe).
Not necessarily. If it’s implemented well, the frontend will just show a “success” message, but the email sent will be different. This way, the owner of the account will know if they already have an account, or if it wasn’t them, that someone else tried to use their email. Meanwhile the bad actor won’t know anything new.
The only issue with it is that it allows attackers to determine that a given person has an account on a site. Which if the site is pornhub or similar, could be embarrassing (try sign up to pornhub with your local politicians email).
The way around this is to do something like:
“We need to verify your email is correct, by sending you a code”
This doesnt tell the attacker anything, but if there already is an account, the email itself can just say “You already have an account, here are the links to reset and login”.
Side note: encryption is reversible, hashing is not. Passwords should be stored hashed, but email only need to be encrypted (or plaintext, but less ideal). And because its reversible, they can get the original value back. They cannot reverse a hash to get the password back, so if a site ever tells you info about your password, that is a sign they might not be hashing it correctly.
Given many people use the same password.on many sites, it can allow the bad actor to “guess” their password based on data from other leaks.
Then whatever is inside that account may be accessible, such as financial info. Even protected data like cc info might show the last 4 digits, which can be used when talking to an agent to verify identity etc.
This is the way.
If you’re going to encrypt the email, you need to be careful about how you use and store the key. Doing any operation with the email will be a lot more expensive, and you’ll lose the benefits if an attacker that can access the db also has access to the key.
I personally don’t think it’s worth it and would prefer to spend more time hardening the app, especially if the email is displayed on the site (i.e. it gets decrypted frequently).
It probably makes sense when there’s sensitive data (bank, medical care, etc), but for most things it’s overkill.