Should I hash the password before sending it to the server side?

Question

I noticed that most sites send the passwords as plain text over HTTPS to the server. Is there any advantage if instead of that I sent the hash of the password to the server? Would it be more secure?

@Jader Dias: I know you didn't ask this, but it wouldn't make any more secure if you hash it, THEN send it over https. In fact, it might make it less secure, since you exposes your salt. Also, (talking out my back-side here), the mixing of algorithms might cause more hash collisions, and make it more hackable. — Merlyn Morgan-Graham, Aug 02 '10 at 20:26
Mixing algorithms does not increase collision probability at all. That's the whole point of a hash function. Given any input entropy, return output that has an equal probability of being anywhere in the possible output space. — J.J, Mar 08 '16 at 17:39
@J.J "Mixing algorithms does not increase collision probability at all." I would really like to see a proof of that statement. Let me stop you: **this is false**, in general it does increase collisions. I can easily construct a hashing function such that h(x) is not constant 0 but h(h(x))=0 for all x. So you would have to refer to exact set of hashing algorithms and how you mix them. Then you would need to prove your statement. AFAIK even for multiple SHA (with salt) this is an open problem. And basically we **believe** this is true. Cryptography is hard. — freakish, Jul 11 '19 at 11:56

score 204 · Accepted Answer · edited Jun 09 '22 at 04:44

204

This is an old question, but I felt the need to provide my opinion on this important matter. There is so much misinformation here

The OP never mentioned sending the password in clear over HTTP - only HTTPS, yet many seem to be responding to the question of sending a password over HTTP for some reason. That said:

I believe passwords should never be retained (let alone transmitted) in plain text. That means not kept on disk, or even in memory.

People responding here seem to think HTTPS is a silver bullet, which it is not. It certainly helps greatly however, and should be used in any authenticated session.

There is really no need to know what an original password is. All that is required is a reliable way to generate (and reliably re-generate) an authentication "key" based on the original text chosen by the user. In an ideal world this text should immediately generate a "key" by salting then irreversibly hashing it using an intentionally slow hash-algorithm (like bcrypt, to prevent Brute-force). Said salt should be unique to the user credential being generated. This "key" will be what your systems use as a password. This way if your systems ever get compromised in the future, these credentials will only ever be useful against your own organisation, and nowhere else where the user has been lazy and used the same password.

So we have a key. Now we need to clean up any trace of the password on the clients device.

Next we need to get that key to your systems. You should never transmit a key or password "in the clear". Not even over HTTPS. HTTPS is not impenetrable. In fact, many organisations can become a trusted MITM - not from an attack perspective, but to perform inspections on the traffic to implement their own security policies. This weakens HTTPS, and it is not the only way it happens (such as redirects to HTTP MITM attacks for example). Never assume it is secure.

To get around this, we encrypt the key with a once off nonce.
This nonce is unique for every submission of a key to your systems - even for the same credential during the same session if you need to send it multiple times. You can reverse said nonce (decrypt), once it arrives in your own systems to recover the authentication key, and authenticate the request.

At this point I would irreversibly hash it one last time before it is permanently stored in your own systems. That way you can share the credential's salt with partner organisations for the purposes of SSO and the like, whilst being able to prove your own organisation cannot impersonate the user. The best part of this approach is you are never sharing anything generated by the user without their authorisation.

Do more research, as there is more to it than even I have divulged, but if you want to provide true security to your users, I think this method is currently the most complete response here.

TL;DR:

Use HTTPS. Securely hash passwords, irreversibly, with a unique salt per password. Do this on the client - do not transmit their actual password. Transmitting the users original password to your servers is never "OK" or "Fine". Clean up any trace of the original password. Use a nonce regardless of HTTP/HTTPS. It is much more secure on many levels. (Answer to OP).

edited Jun 09 '22 at 04:44

Top-Master

7,611
5
39
71

answered Feb 12 '14 at 01:12

user3299591

2,216
2
12
3

42

I just checked gmail and facebook - chrome developer tools tell me both POST with a urlencoded message containing my username and password in plain (unsalted) text. How/why are the big players not using nonce salting on the client? – gremwell Dec 16 '15 at 08:55
2

Why not just use a simple hash on the client side and a salted hash in the backend? – Mentor Nov 24 '16 at 10:49
38

If you don't trust HTTPS every single effort is pointless! Your code itself is shipped through the wire and an attacker can modify/replace all your attempts to to secure password in transit – Sajid Kalla Feb 11 '17 at 02:08
4

A MitM that can rewrite a cert can rewrite the nonce. Or what Sajid said. – leewz Mar 19 '17 at 19:27
2

So you encrypt the key with a nonce, then decrypt it on the server, then hash it, then store the hash. Later, you do the same thing, except instead of storing the hash, you check if there is an entry in storage with the same username, and if so, you check if the hash is the same. Alternatively, depending on the hash function, you verify that the hash you stored and the hash that just came through were computed with the same key (password). Do I have that right? – trysis Mar 18 '18 at 15:37
1

So what I want to know is this means the password is present on the server between decryption and storage/verification. Is this safe? Keep in mind I am not a security expert, though I got a network security degree. That was 3 years ago, and I haven't really used it since, been mostly front-end. – trysis Mar 18 '18 at 15:39
2

We should hash user passwords because we *assume our system will be compromised*. Reading the database is only one way to obtain passwords as an intruder, which is what server-side salted password hashing prevents. An intruder could simply tap the authentication endpoint if passwords are being sent in plain-text. Client-side hashing prevents the intruder from sniffing passwords and reusing them in other systems. – Benjamin B. Nov 28 '18 at 08:08
10

If you are worried about MITM with HTTPS, what's the point in sending a salt to the client so that the client can salt the password before transmitting the hash back to the server? Seems pointless. Might as well just do an unsalted hash to the server, then use a salt to hash again on the server. Clearly, the client can't be the generator of the client-salt either because the next login, it would be different and not compute the same hash server-side. – crush Feb 04 '19 at 22:37
3

I would like an answer to @gremwell. If Google ain't doing it, I ain't doing it. If only for the sake of being practical. – Sarsaparilla Mar 02 '19 at 01:30
10

This answer has many wrong information, using HTTPS and hashing the password before storing into the server database are enough for most of the cases. For more important accounts, use multi-factor authentication instead of client side hashing. For more information, see: [I just send username and password over https. Is this ok?](https://security.stackexchange.com/q/7057), [https security - should password be hashed server-side or client-side? A](https://security.stackexchange.com/q/8596) and [Why is client-side hashing of a password so uncommon?](https://security.stackexchange.com/q/53594). – J3soon Apr 05 '19 at 14:11
For using salt+nonce in a login authentication process, see this answer: https://stackoverflow.com/a/24978909/43615 – Thomas Tempelmann May 16 '19 at 15:02
3

Also, even big companies accidentally stored passwords in their log files. That's another reason why you should not send passwords over the net, but only hashes – Thomas Tempelmann May 16 '19 at 15:03
2

`There is really no need to know what an original password is.` What about password validation? You don't actually believe that users create secure passwords, do you? – freakish Jul 11 '19 at 11:14
@HaiPhan .Companies like that always require an email confirm, other device confirm, and other two factor things to detect when another device or another internet IP logs into the account. – CDM social medias in bio Feb 08 '20 at 02:48
2

I believe one of the points that Thomas is trying to make is that in the case of a compromise of the service you are using, the passwords would not have been sent over in cleartext. He is advocating for defense in-depth, by assuming that even if the service is compromised at a later date, the passwords were not sent over the wire in plaintext, and possibly captured in log files, invalid server configurations, caches, etc. Even though a service is now compromised, the email+password combos are not, and thus protects users from other services where they may have used the same credentials. – arashb31 Sep 30 '20 at 16:19
@StevenLu Well [Kerckhoffs's principle](https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle) says the opposite. but I do agree with your thought. – Aagam Sheth May 22 '21 at 10:36
@freakish ??? Password validation is done in client's side. – Daniel N. May 18 '22 at 23:16
1

@DanielN. you do realize that client side validation is as safe as no validation at all? – freakish May 19 '22 at 05:57
@j3soon - how is this wrong? Who decides what is right? This is a fine and secure way to do things. – Jamie Marshall Aug 18 '22 at 00:26
If TLS is broken only God or Turing's eternal spirit can help you anymore. What this answer is suggesting is encrypting the password with a "nonce" (by which they mean an ephemeral key). This key will have to go over the line in plaintext, so if TLS is compromised, the attacker will also have this key and this provides ZERO additional security. If you generate this "nonce" with a proper protocol such as Diffie-Hellman you are simply doing EXACTLY what TLS is already doing for you for every session. There is NOTHING to be gained unless you mistrust your system's TLS implementation. – JMC Jul 30 '23 at 13:14

score 31 · Answer 2 · answered Aug 02 '10 at 19:56

31

Since it's over HTTPS, it's definitely just fine to send the password without hashing (over HTTPS it's not plaintext). Furthermore, if your application is depending on HTTPS to keep it's content secure, then it's useless to hash the password before sending it over HTTPS (i.e. if an attacker can unencrypt the data on the wire, you're screwed anyways)

answered Aug 02 '10 at 19:56

Kiersten Arnold

1,840
1
13
17

I fear that HTTPS data is intercepted by proxies, and hashing it in the client would prevent they becoming leak points. Do you agree? – Jader Dias Aug 02 '10 at 20:01
5

This shouldn't be a problem. If the client is using a proxy, then all the proxy will see is the HTTPS encrypted data. If you're talking about a man-in-the-middle attack, a properly configured certificate should prevent this. – Kiersten Arnold Aug 02 '10 at 20:03
7

@Jader: No amount of fiddling with the data will stop a MITM attack, since it can just relay whatever comes to it. It doesn't matter whether you're transmitting a password or hash. That's a completely different matter. – David Thornley Aug 02 '10 at 20:10
@David I think a challenge-based encryption could prevent a replaying the hash, so it would be useless to intercept a password hashed with a one-time salt (the challenge). – Jader Dias Aug 02 '10 at 20:15
2

The purpose of SSL (HTTPS = HTTP over SSL) is to thwart MITM. – yfeldblum Aug 02 '10 at 20:20
1

@carnold - MINTM - What about redirecting to http? Would most people notice? sslstrip - http://www.securityfocus.com/brief/910 – nate c Aug 02 '10 at 20:38
@Jader: So, what in nonce would prevent a MITM attack? The only thing it would do is prevent a replay attack, and the MITM already has full access for the duration of the session. Is it worth complicating things to hinder turning full access into permanent full access? – David Thornley Aug 02 '10 at 20:48
1

@Jader Dias your trying to stop a problem that doesn't exist. HTTPS stops this problem, a client side hash does not add any amount of security. The client can never be trusted. – rook Aug 02 '10 at 22:40
@David Thornley - You said that "No amount of fiddling with the data will stop a MITM attack, since it can just relay whatever comes to it," but Jader pointed out that a nonce defeats replay attacks. Can you explain how to MITM a TLS connection without generating a client warning? – Hut8 Aug 03 '10 at 17:14
@bowenl2: A nonce defeats replay attacks, in the sense that it's impossible for an eavesdropper to replay the credential later and get into a session. A MITM would accept the challenge from one side, replay it to the other, and then do the same in the reverse direction with the response, so a nonce-based solution won't do squat against MITM. The only way to defeat MITM is to authenticate who you're immediately talking to, which means certificates that are independently authenticated and which you can rely on, which isn't quite the case today (cont) – David Thornley Aug 03 '10 at 17:24
(from cont) because (a) not all certificate authorities are completely trustworthy and immune to deception, and (b) not all certificate holders use their certificates properly (so that dealing with them requires violating good security practice). – David Thornley Aug 03 '10 at 17:25
does it mean that mobile developer should POST to url: https://www.domain.com when he is posting data? – FosAvance Oct 23 '15 at 20:42
HTTPS is fine... If you want more security then go with 2 Step verification. HTTPS is Encrypted data, I don't get what is so hard to understand about it. – Daniel N. May 18 '22 at 23:20

score 25 · Answer 3 · edited Jun 11 '14 at 08:36

No, in fact this would be a vulnerability. If the attacker is able to obtain the hash from the database, then he could use it to authenticate without needing to crack it. Under no circumstance should a user or an attacker be able to obtain a hashes password.

The whole point of hashing passwords is to add an extra layer of security. If an attacker is able to obtain the hash and salt from the database using SQL Injection or an insecure backup then he has to find the plain text by brute forcing it. John The Ripper is commonly used to break salted password hashes.

Not using https is a violation of the OWASP Top 10: A9-Insufficient Transport Layer Protection

EDIT: If in your implementation you calculate a sha256(client_salt+plain_text_password) and then calculate another hash on the server side sha256(server_salt+client_hash) then this is not a serious vulnerability. However, it is still susceptible to eavesdropping and replaying the request. Thus this is still a clear violation of WASP A9. However, this is still utilizing a message digest as a security layer.

The closest thing i have seen to a client-side replacement for https is a diffie-hellman in key exchange in javascript. However, this does prevent active MITM attacks and thus is till technicality a violation of OWASP A9. The Authors of the code agree that this is not a complete replacement for HTTPS, however it is better than nothing and better than a client-side hashing system.

Actually I would hash it again in the server, so please edit your answer contemplating this scenario. — Jader Dias, Aug 02 '10 at 20:00
@Rook is using diffie-hellman key exchange together with https is a "useless" solution ? ( I mean we can only use https and diffie helman do not increase the security imao ) — Michel Gokan Khan, Dec 03 '12 at 08:39
@Michel Kogan a DH key exchange can be used in HTTPs along with other tools. — rook, Dec 03 '12 at 16:22
@Rook It is a best practice to apply a hash on the server, so I think you should update the beginning of your answer not to dismiss client-side hashing, and only then mention that the server's stored hashes and salts should never be exposed. — Levente Pánczél, May 27 '14 at 10:09

score 13 · Answer 4 · answered Aug 02 '10 at 20:07

13

Sending a hash over the wire completely defeats the purpose of the hash, because an attacker can simply send the hash and forget about the password. In a nutshell, a system that athenticates using a hash in clear text is wide open and can be compromise with nothing more than network sniffing.

answered Aug 02 '10 at 20:07

Paul Keister

12,851
5
46
75

3

This seems total bullsh... How is a hash less secure than a password? – Levente Pánczél May 27 '14 at 10:11
2

This is only true for "dumb" hashes. Consider this: A server sends a salt S to the client and the client does HASH(S + PASSWORD), and sends it to the server. The server honors that specific hash only for the current session. An attacker can indeed send the hash and forget about the password, but ONLY FOR THE CURRENT SESSION. Therefore it's more secure than plain-text. – Hello World Jun 11 '14 at 08:38
Update: Digest Access Authentication is even more sophisticated: https://en.wikipedia.org/wiki/Digest_access_authentication – Hello World Jun 11 '14 at 08:53
2

Just to be clear: when I say "defeats the purpose of hash" I'm referring to common and secure practice of hashing passwords before storing them in a database. Nevertheless the argument holds that sending a hashed value instead of a password does nothing to enhance security without additional steps. – Paul Keister Jun 11 '14 at 14:42
Just to add to what Paul said: this kind of attack is called a “replay attack” if anyone wants to read more about it elsewhere. – Feb 24 '19 at 10:16

score 9 · Answer 5 · answered Oct 22 '15 at 15:11

The password in plaintext show never (not even when using HTTPS) leave the client. It should be irreversibly hashed before leaving the client as there is no need for the server to know the actual password.

Hashing then transmitting solves security issues for lazy users that use the same password in multiple locations (I know I do). However this does not protect your application as a hacker that gained access to the database (or in any other way was able to get his hands on the hash) as the hacker could just transmit the hash and have the server accept it.

To solve this issue you could of course just hash the hash the server receives and call it a day.

My approach to the issue in a socket-based web application I'm creating is that on connection to the client the server generates a salt (random string to be added before hashing) and stores it on the sockets variable, then it transmits this hash to the client. The client takes the users password, hashes it, adds the salt from the server and hashes the whole thing, before transmitting it to the server. Then it's sent to the server which compares this hash to the hash(hash in the DB + salt). As far as I know this is a good approach, but to be fair I haven't read a lot on the topic and if I'm wrong about anything I'd love to be corrected :)

score 5 · Answer 6 · answered Jul 15 '17 at 06:00

Disclaimer: I'm by no stretch a security expert-- and I'm posting with the hope that others will critique my position as overly cautious or improvable and I will learn from it. With that said, I just want to emphasize that hashing when it leaves your client doesn't mean you get to don't have to hash on the backend before putting it in the database.

Do both

Do both because:

Hashing on the ride over helps cover vulnerabilities of transport, if SSL connection is compromised, they still can't see the raw password. It won't matter in terms of being able to impersonate authorized users, but it will protect your users from having their passwords read in association w/ their email. Most people don't follow best practice and use the same password for many their accounts, so this can be a serious vulnerability to your visitors.
If someone, somehow was able to read passwords from the database (this does happen, think SQL injection), they still won't be able to execute privileged actions impersonating users through my API. This is because of hash asymmetry; even if they know the hash stored in your DB, they won't know the original key used to create it and that's what your auth middleware uses to authenticate. This is also why you should always salt your hash storage.

Granted, they could do a lot of other damage if they had free rein to read what they want from your database.

I just want to emphasize here that if you do decide to hash the key before departure from your clients, that isn't enough-- the backend hashing is, imo, much more important and this is why: If someone is intercepting traffic from your client, then they will see the contents of the password field. Whether this is a hash, or plain text, it doesn't matter-- they can copy it verbatim to impersonate an authorized client. (Unless you follow the steps which @user3299591 outlines, and I recommend you do). Hashing the DB column, on the other hand, is a necessity and not at all difficult to implement.

score 3 · Answer 7 · answered Aug 02 '10 at 20:05

3

Use HTTP Digest - it secures the password even over http (but best useage would be http digest over https)

Wikipedia:

HTTP digest access authentication is one of the agreed methods a web server can use to negotiate credentials with a web user (using the HTTP protocol). Digest authentication is intended to supersede unencrypted use of the Basic access authentication, allowing user identity to be established securely without having to send a password in plaintext over the network. Digest authentication is basically an application of MD5 cryptographic hashing with usage of nonce values to prevent cryptanalysis.

Link: http://en.wikipedia.org/wiki/Digest_access_authentication

If you want to see a "real life" use, you could look at phpMyID - a php openid provider that uses http digest authentication http://siege.org/phpmyid.php

.. or you could start from the php auth samples at http://php.net/manual/en/features.http-auth.php

Http digest rfc: http://www.faqs.org/rfcs/rfc2617

From my tests all modern browsers support it...

answered Aug 02 '10 at 20:05

vlad b.

695
5
14

HTTP Digest implements what I meant in this question, but would we have any advantage if we used HTTPS Digest (SSL + HTTP Digest) ? – Jader Dias Aug 02 '10 at 20:21
One main difference would be that everything is sent/received encrypted - http headers send and received and the html reply. To someone randomly trying to "hack" ssl using a man-in-the-middle-attack the http digest would be an extra motive to make him search another easier target, or if he is logging all captured traffic your passwords is still safer. I may have misunderstood the question, english is not my first language. – vlad b. Aug 02 '10 at 20:54
Hash over password has one big advantage: if the traffic is logged or captured somehow it will make the job harder for that person. Also, with http digest, if ssl is not always required, you could let users choose between http and https. Or you could use different protocols for diferent servers (for example i do not enforce https to view/modify less importand data (username, avatar uploading) but enforce https on billing and other parts of the site (that way i can decrease the load on some servers, if/when needed). – vlad b. Aug 02 '10 at 20:58

score 3 · Answer 8 · edited Sep 13 '10 at 02:37

If you're looking to replace a clear-text password over HTTPS with a hashed password over HTTP then you're asking for trouble. HTTPS generates a random, shared transaction key when opening up a communication channel. That's hard to crack, as you're pretty much limited to brute forcing the shared key used for a (relatively) short-term transaction. Whereas your hash can be just sniffed, taken off-line and looked up in a rainbow table or just brute forced over a long amount of time.

However, a basic client-side password obfuscation (not hash) sent over HTTPS does have some value. If I'm not mistaken this technique is actually used by some banks. The purpose of this technique is not to protect the password from sniffing over the wire. Rather, it's to stop the password from being usable to dumb spying tools and browser plug-ins that just grab every HTTPS GET/POST request that they see. I've seen a log file captured from a malicious website that was 400MB of random GET/POST transactions captured from user sessions. You can imagine that websites that used just HTTPS would show up with clear-text passwords in the log, but websites with very basic obfuscation (ROT13) as well would show up with passwords that are not immediately of use.

"but websites with very basic obfuscation (ROT13) as well would show up with passwords that are not immediately of use" - this contradicts the original statement. The key is that they are not IMMEDIATELY of use, but that really is futile. The password and its ROT13 are equivalent. BUT if you SHA2 the password, it will not be present in the logs (so your admins do not get to know users' possible passwords to other systems), and you're NO LONGER in violation of almost every privacy Act. — Levente Pánczél, May 27 '14 at 10:06

score 3 · Answer 9 · answered Nov 04 '19 at 21:03

Whether there's an advantage, and whether it's more (or less) secure really depends on implementation. There's arguably some advantage, but if you implement it poorly, you could definitely create a solution that is less secure than passing even a plaintext password.

This can be looked at from the perspective of two types of attacks-- one with access to the network traffic, and another with access to the database.

If your attacker can intercept the plaintext version of the network traffic, then seeing a hash of the password is more secure than seeing the password in plaintext. Although the attacker could still log in to your server using that hash, it would require a brute-force crack (sometimes pre-computed) of that hash to determine the password that might be useful on other systems. People should use different passwords on different systems, but often don't.

If an attacker gained access to the database, perhaps through a copy of a backup, then you'd want to ensure that one couldn't log in with only that knowledge. If, for example, you stored a hash salted with the login name as hash(login_name+password), and you passed that same hash from the client for direct comparison, then the attacker could pick a user at random, send the hash read from the database and log in as that user without knowing the password, increasing the scope of the breach. In that case, sending the password in plaintext would have been more secure because the attacker would need to know the plaintext in order to log in, even having a copy of the database. This is where implementation is key. Whether you send a plaintext password or a client-side hash of that password, you should hash that value at the server-side and compare that hash with the hash stored in the user record.

Concepts to keep in mind:

You "salt" a hash by mixing in some scope-unique value to your hash, typically row-unique. Its purpose is to guarantee uniqueness of hashes from each other even if the plaintext values they represent are the same, so two users with the same password would still have different hashes. It's unnecessary to treat a salt as a secret.
When authenticating, always hash on the server-side whatever value you pass from the client as a password (even if it's already hashed) and compare it with a pre-hashed value stored on the database. This may necessitate storing a double-hashed version of the original password.
When you make a hash, consider adding a server/cluster-unique salt to the hash as well as a row-unique salt to safeguard against matching any pre-computed hashes in lookup tables.

score 2 · Answer 10 · answered Aug 02 '10 at 20:00

2

If you're connected to an https server the data stream between the server and browser should be encrypted. The data is only plain text before being sent and after being recieved. Wikipedia article

answered Aug 02 '10 at 20:00

jac

9,666
2
34
63

1

Don't proxies intercept this data? – Jader Dias Aug 02 '10 at 20:03
As I understand it they do, but the proxy is not responsible for encryption/decryption and unless it is an unscrupulous proxy only passes the data on. The encryption type and strength is dependent on what the server and client can both support. – jac Aug 02 '10 at 20:17
1

Even if the proxy is unxrupulous, it can't decrypt the data as it is encrypted using the server's public key. The only way a proxy can decrypt the data is to spoof the server's certificate with a different key – Kiersten Arnold Aug 02 '10 at 20:32
@Jader. If they did, it would make HTTPS pretty lame. when you authenticate to a server with HTTPS, you are getting a guarantee (assuming the certificate is valid) that you are connecting to a certain server, and have an encrypted path from one end to the other. Hypothetically, a man in the middle attack could be done to fool you of course, but that is not the same as a basic web proxy. – Peter Recore Aug 02 '10 at 20:44

M22 · Answer 11 · 2021-10-09T09:54:40.470

If you want to achieve the same reliability as when transferring over https, then yes - one option - the implementation of an asymmetrically encrypted channel at the ajax level.

If we are not talking about registration (for example, the first transmission of the password is always protected), then there are options.

For example,

The server generates a random string and generates a salt sends it to the user.
The user calculates a hash from his password and using this hash as a key encrypts this random string with a blowfish, for example (there is an implementation in JS for sure) and sends it back to you.
You, on your own, using the hash stored on the server, also encrypt this random string with a blowfish.
Compare.

An attacker would have to attack the bluefish key using a random source and ciphertext. The task is not easy.

This is about verifying passwords (no need to send a hashed password, but you send a hashed random string back to server) — M22, Apr 10 '21 at 21:52

score 1 · Answer 12 · answered Jan 05 '17 at 00:16

1

Isn't SSL/TLS replacing the nonce? I don't see added value of this since SSL/TLS also protects against Replay Attacks.

Ref. https://en.wikipedia.org/wiki/Cryptographic_nonce

answered Jan 05 '17 at 00:16

Tom Kip

11
2

Kindly check http://stackoverflow.com/questions/3391242/should-i-hash-the-password-before-sending-it-to-the-server-side – Ahmed Hosny Jan 05 '17 at 00:31

score 0 · Answer 13 · answered Aug 02 '10 at 19:57

0

It would actually be less secure to hash the password and send it over a non-encrypted channel. You will expose your hashing algorithm on the client. Hackers could just sniff the hash of the password and then use it to hack in later.

By using HTTPS, you prevent a hacker from obtaining the password from a single source, since HTTPS uses two channels, both encrypted.

answered Aug 02 '10 at 19:57

Carter Medlin

11,857
5
62
68

1

Actually I would hash it again in the server, and I would use HTTPS anyway, so please edit your answer contemplating this scenario. – Jader Dias Aug 02 '10 at 20:02
@Jader, the point is, all an attacker needs now is the first hash, rather than a password. In effect, the hash you take of the password on the client side is now just as useful as the password itself. So you're not really gaining much security. – Peter Recore Aug 02 '10 at 20:39
has anyone ever thought of not sending parts of the token? like if you know your methods of hashing, why would you send that. shouldn't the server know the client key to decrypt? – jemiloii Jul 15 '17 at 00:32

Should I hash the password before sending it to the server side?

13 Answers13

Linked

Related