111

I'm setting up a home HTTP server which can send and receive JSON data to/from different clients (Android and iPhone apps).

I'd like to allow access only to certain users and I'm considering using a simple username/password mechanism, as setting up client certificates seems a bit of an overkill for this small project.

Of course I can't send clear passwords from the client to the server on plain HTTP, otherwise anyone with wireshark/tcpdump installed could read it. So, I'm thinking about the following mechanism:

  1. The HTTP server can be set up as HTTPS server
  2. The server also has username/password database (passwords might be saved with bcrypt)
  3. The client opens the HTTPS connection, it authenticates the server (so a server certificate is needed) and after exchanging the master key, the connection should be encrypted.
  4. The client sends the username/password in clear to the server
  5. The server runs bcrypt on the password and compares it with the one stored in the database

Is there any problem with this kind of configuration? The password should be safe since it's sent on an encrypted connection.

Spooky
  • 107
  • 4
Emiliano
  • 1,213
  • 2
  • 9
  • 6
  • 6
    Just to add to the answers you've received already, in this kind of set-up I'd recommend looking at Certificate Pinning which helps mitigate MITM attacks... – Rory McCune Aug 04 '14 at 15:12
  • Maybe consider hashing the password instead of (or in addition to) encrypting it. – user541686 Aug 07 '14 at 02:53
  • 2
    Even though it might be safe if you use https. One problem which I read in other questions is that the username & password will get written to the server logs if it's directly passed in the urls. It can be dangerous if the logs security get compromised. – Krishnadas PC Aug 25 '17 at 03:00

9 Answers9

85

Yes, this is the standard practice. Doing anything other than this offers minimal additional advantage, if any (and in some cases may harm the security). As long as you verify a valid SSL connection to the correct server, then the password is protected on the wire and can only be read by the server. You don't gain anything by disguising the password before sending it as the server can not trust the client.

The only way that the information could get lost anyway is if the SSL connection was compromised and if the SSL connection was somehow compromised, the "disguised" token would still be all that is needed to access the account, so it does no good to protect the password further. (It does arguably provide a slight protection if they have used the same password on multiple accounts, but if they are doing that, they aren't particularly security conscious to begin with.)

As MyFreeWeb pointed out, there are also some elaborate systems that can use a challenge response to ensure that the password is held by the client, but these are really elaborate and not widely used at all. They also still don't provide a whole lot of added advantage as they only protect the password from being compromised on an actively hacked server.

AJ Henderson
  • 41,896
  • 5
  • 63
  • 110
  • 6
    @AJHenderson +1, having the client send the hash would definitely be bad, as the point of the authentication protocol is to ensure that the visitor knows the correct *password*, not the correct password *hash*. If a malicious party could obtain the hash (stolen password database, man in the middle, whatever) and the system relied on the visitor sending the hash instead of the password, any notion of real security would be out the window. – Craig Tullis Aug 04 '14 at 20:04
  • 9
    There is sometimes benefit to hash at client and then hash some more at the server. This can help ensure the password is obfuscated in any clear text logs at the client, server, and on the network. – Andy Boura Aug 05 '14 at 07:41
  • 2
    @Craig Letting the client compute the expensive salted hash is perfectly fine, as long as you apply a cheap unsalted hash on the server before storing it (or some other kind of one way function, like modular exponentiation). – CodesInChaos Aug 05 '14 at 12:29
  • @AndyBoura - if you are designing the system such that you can support client side hashing, you have control over the network and server behavior for parts that would have access to the clear text. True, you aren't harmed by hashing it on the client (other than lost time), just so long as you it doesn't significantly impact the amount of hashing you do on the server. – AJ Henderson Aug 05 '14 at 13:16
  • @CodesInChaos - I'd only go for it being slightly less bad. Even using a complex hash to make a "longer" input, it is only key extension and an attacker is going to be able to produce a lot of cheap hashes very easily. Practically, it might not matter if the client side hash output is long and there are no vulnerabilities in either hash that limit the expansion from simple values. It's also important to note that in such a case, you would need to salt both the client and server side hashes. I'm still a bit dubious of the cost vs the benefit though. – AJ Henderson Aug 05 '14 at 13:18
  • 1
    @AJHenderson There are several advantages to client side hashing: 1) Longer time limit since the client doesn't need to handle many logins at the same time. 2) Avoids DoS since the server doesn't need to compute an expensive hash. 3) Server doesn't learn the password. | The main downside is that clients often have a slower CPU than the server. | I don't see why the server side hash should use a salt when the client side hash already uses one. – CodesInChaos Aug 05 '14 at 13:32
  • 2
    @CodesInChaos - Because nothing client side is trusted. An attacker can skip the entire slow process by bypassing the client entirely. You need to make sure you can't build a rainbow table of cheap, fast hash values. It isn't feasible if you salt each and provided the intermediate hash is long enough. Otherwise, you just make a rainbow table of hash values which can be generated at a very, VERY fast rate if they are cheap. – AJ Henderson Aug 05 '14 at 14:08
  • @AJHenderson Obviously the intermediate value needs to be large enough to avoid enumeration, at least 128 bits preferably 160-256 to account for multi target attacks. Since using a proper hash like SHA-256 is so easy, I see no reason to add unnecessary complications like a salt. – CodesInChaos Aug 05 '14 at 14:15
  • @CodesInChaos - yeah, if you are using a sufficinently large intermediate hash and are sure it behaves well (truly random distribution) then it should be ok as long as the initial hash is salted and takes long enough to force use of a full enumeration of the intermediate hash space (or at least near full.) – AJ Henderson Aug 05 '14 at 14:42
  • 1
    At the risk of stating the obvious, make sure you are transmitting via POST, and not via GET :-) GETs will be in the clear. – Eric Patrick Aug 05 '14 at 16:15
  • 2
    Also, while we're talking issues like POST vs GET, be sure to implement forward secrecy so your secure sessions can't be decrypted later on by somebody who obtains your server's private key. – Craig Tullis Aug 05 '14 at 16:20
  • Password/hash conversation [continued in chat](http://chat.stackexchange.com/rooms/16227/discussion-between-aj-henderson-and-craig). – AJ Henderson Aug 05 '14 at 18:02
  • 1
    Especially with a Client-Side application, I would probably still use some hashed version of the password over the line, since I think it is possible, that for some reason an unencrypted connection could be created (by some programming error, faulty app-update, wrong settings of the underlying library, so a redirection to a http-server is accepted...) * All for the case of same password for multiple accounts, furthermore you are safe from someone with access to your server from obtaining cleartext-passwords... – Falco Aug 06 '14 at 14:04
  • @Falco - and a programming error could result in the hash being insecure too. You have to validate behavior of security related code, not just hope it works right. The more complexity you add to a system, the harder it is to validate and the more likely an error or vulnerability is to appear. You have to judge how much benefit you get for a given amount of additional effort. Eventually the added risk of error in implementation is not worth the minimal gain in added resistance. – AJ Henderson Aug 06 '14 at 15:06
  • @AJHenderson: You state "Yes, this is the standard practice." Do you have a reference to make that statement? I'm looking for best practices from a well-known authority source, like maybe NIST or even an O'Reilly book. – stackoverflowuser2010 Apr 22 '15 at 21:06
  • Does this "standard practice" also ensures complete security if we have 'goto fail' or 'HTTPS freak' as part of our communication? And if two SSL versions are broken, are we sure that the recent version is safe? – h22 Oct 27 '15 at 12:43
  • @h22 I suppose we can't be 100 percent sure, but if it isn't, passwords are the least of our concerns. Also, we're a heck of a lot more sure about TLS than we are about some home grown client side hashing or encryption setup. If say that falls under the "don't roll your own" practice. – AJ Henderson Oct 27 '15 at 13:12
  • "Home grown encryption" does not sound good indeed but there are standard cryptography libraries as well. – h22 Oct 27 '15 at 13:21
  • @h22 the home grown encryption doesn't just apply to algorithms or libraries, but also protocols. There are a lot of ways a password exchange can break down. For example, if you did client side encryption without a different challenge sent to the client every time, then the encryption would do nothing at all as it would only be obscuring the means of generating a password that would only be protected by ssl (since the client generated value would be the same all the time, making it the "real" password) There are all kinds of potential pitfalls, both obvious and non obvious. – AJ Henderson Oct 27 '15 at 15:05
  • The fact remains that there is far more testing and analysis of protocols like ssl than anything you make up as your own suite. If your own stuff is layered on top of other stuff it may produce side channel attacks. The fact it has taken so long for issues to be discovered in ssl should be a confidence builder. It means even with a ton of eyes, vulnerabilities are hard to find. Additionally it means issues are found and announced by researchers that look in to this kind of thing. – AJ Henderson Oct 27 '15 at 15:10
  • Is this still a good answer? I would expect not; some places install extra certificates and do HTTPS MitM attacks, for example. I've seen some discussion elsewhere of what should be a better scheme, but not enough for me to judge whether it was by people who actually understood security. – Daniel H Mar 06 '19 at 21:25
  • @DanielH if someone has access to install root certificates, they have access to key log. If you don't trust a computer, don't enter your password, period. Protecting against compromised clients requires an entirely different mechanism such as smart cards that can authenticate without revealing the secret, but that requires extra hardware for the client and isn't practical for most applications. – AJ Henderson Mar 06 '19 at 22:35
  • @AJHenderson There are ways to get a client to have a compromised certificate that don’t let you install a keylogger, but I withdraw that part of my objection anyway because they’d also let you change the login screen and few if any clients will check that every time for changes. This would only protect against partial-but-not-total server compromises (which may or may not be plausible depending on architecture and corporate security practices) or attacks that allowed passive evesdropping but not active interference with HTTPS (probably can exist, but very rare). – Daniel H Mar 07 '19 at 00:34
  • @AJHenderson Although most of what convinced me is that several companies I trust to have better-than-average security all seem to send the entered password in a way unencrypted beyond HTTPS. I am surprised; I would have expected a method which doesn’t do that to have become standard for the perhaps-small improvement it does offer, especially given that fighting against password reuse is a losing battle. – Daniel H Mar 07 '19 at 00:37
  • @DanielH how would you install a trusted root certificate without having admin access to the box for at least a short time? If you have that level of access, then you could be nefarious in any number of other ways as well if you wanted to be. And as you rightly pointed out, just having MitM capability means any client side mechanism could be defeated unless it was built in to an app rather than a website. – AJ Henderson Mar 07 '19 at 02:55
  • @AJHenderson You could compromise a certificate, either without being noticed or carrying out the attack before it's revoked. You could target clients who still have the [Superfish](https://en.wikipedia.org/wiki/Superfish) certificate, or an equivalent from one of the multiple other utilities that do something similar. You could sell a content-filtering middlebox or middleware which would have a valid reason for MitMing, and then either fail to guard the certificate or use it for nefarious purposes. You could trick a CA into issuing you a certificate for a site you only partially control. Etc. – Daniel H Mar 07 '19 at 03:02
  • @DanielH ok, that's a completely different context than your initial comment talking about places that install certs for MitM proxying. The cases you just described are far less common and most have either mitigations in place now or are very rare cases or only apply to systems that are otherwise vulnerable to attack against the client itself. – AJ Henderson Mar 07 '19 at 03:22
  • Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/90709/discussion-between-daniel-h-and-aj-henderson). – Daniel H Mar 07 '19 at 03:41
21

Not necessarily.

You also need to ensure the following:

  1. Your site is protected against cross-site request forgeries. Use Synchronizing Token Pattern.

  2. Your site is protected against session fixation attacks. Change session id on login.

  3. If using session cookies, that your entire site is HTTPS, not just the login URL, and that your session cookie is marked as secure and http only (no JavaScript access). Browser will send session cookie unencrypted if user types http://yoursecuresite (in same browser session).

  4. You are using a recent protocol. SSL 1 and 2 are broken, and 3 might be too. Try to use TLS 1.3.

  5. You are using a strong cipher.

  6. You are not using HTTP compression (GZip) or TLS compression. If your site displays user input (like a search input), then I can figure out your CSRF tokens and bank account number if you're using compression.

  7. Your server does not allow insecure client re-negotiation.

  8. You are using a 2048-bit RSA key (or the equivalent for an EC key), and that no one else knows your private key.

  9. You are using HSTS so browser goes direct to https even if user types http

  10. You are using perfect forward secrecy so your historical communications are secure even if your private key is leaked

kelalaka
  • 5,474
  • 4
  • 24
  • 47
Neil McGuigan
  • 3,399
  • 1
  • 17
  • 21
  • if the entire site is https, do I Still need cookie marked as secure? They would still be encrypted "for free" due to the TLS layer, right? – Emiliano Aug 04 '14 at 22:11
  • 2
    Can you explain point 6? Why compression would make the connection less secure? – Emiliano Aug 04 '14 at 22:13
  • Ya you still want secure cookie, http only, as its still stealable if not. See xss. Compression kills encryption. See BEAST and CRIME attacks. – Neil McGuigan Aug 04 '14 at 23:17
  • 2
    @Emiliano: even your site is HTTPS only, an attacker can setup a man in the middle attack and setup a fake server that uses plain HTTP, performing what is known as SSL stripping. The browser will send to the fake server the user's cookie. To mitigate this, you need Secure cookie and HSTS policy. – Lie Ryan Aug 05 '14 at 00:01
  • 9. Employ PFS to mitigate the risk of somebody (for example some evil government) stealing your private keys. – FooF Aug 05 '14 at 12:12
  • 8. that's the whole point of HTTPS... 1. not relevant for mobile client, it is unlikely that there are cookies and sessions. 6. what's wrong with compressions? - typically a server serving json services would require all requests to be authenticated. – njzk2 Aug 06 '14 at 20:54
  • @njzk 1. URLs will still be browsable in a browser, so it is relevant. 3. Depends on his implementation, worth mentioning anyways. 6. see BEAST and CRIME attacks. – Neil McGuigan Aug 06 '14 at 21:21
  • @NeilMcGuigan : Is it possible to guess the password length if it is send in clear over HTTPS? – user2284570 Aug 07 '14 at 13:30
  • @user2284570 "In the clear" and over "HTTPS" are opposites. – Neil McGuigan Aug 07 '14 at 17:51
  • @NeilMcGuigan : I wanted to mean by not transmitting them using hash or extra-encryption. – user2284570 Aug 07 '14 at 19:12
16

As long as you verify the certificate validity, this is perfectly fine and is done all the time.

mricon
  • 6,298
  • 23
  • 27
7

Most of the sites usually considered to be secure take pretty much the approach you are describing. Or put differently, you have simply described established industry standard.

I would recommend against using an approach less secure than the one you mention. (Whether bcrypt is better or worse than other salted hashes is a discussion I won't be going into. Just don't use anything weaker than a salted hash.)

If you want to distinguish yourself as having security above established industry standards, there are other options available. But it takes a huge effort in all areas of your application to make it worthwhile.

Areas regarding password validation that could be more secure include:

  • Protecting the server against DoS attacks by offloading most of the computation during validation to the client. I.e. don't iterate hashing on the server side, only iterate on client side and perform last step of hashing on server.
  • Protecting against password leaks if server is compromised by deriving a public key pair from the password and never let the server see password or secret key.
kasperd
  • 5,442
  • 1
  • 19
  • 38
4

As others have said this is a standard approach.

However for a personal site I wouldn't necessarily follow it... I would use federated login from Facebook, Google or similar as that way I don't have to handle account life-cycle issues, and can use Google 2 factor Auth etc.

It saves having quite a few forms and fields in your database which means less to go wrong.

Of course you would still need to authorise those users you wish to be able to access either through a function of the authentication provider such as a Facebook group, some sort of whitelisting of allowed users, or an approval work flow off your account. Sometimes this is done by inviting users: giving them a URL containing a unique secure code and the your system linking that to an Auth provider on first login. Alternatively users authneticate and request access. This places them in a "pending" state. You then provide an interface where you can login and approve them.

Andy Boura
  • 759
  • 3
  • 10
  • 1
    Bit I don't want everyone to join: I want to give permission only to certain users (e.g. my friends). – Emiliano Aug 05 '14 at 19:34
  • Yes, you need a list of emails that are allowed still. You then check that against the federated Id. – Andy Boura Aug 05 '14 at 19:37
  • Ah, so I can implement a white list, you mean? That is interesting, I'll look into this approach as well. – Emiliano Aug 05 '14 at 19:58
  • That's right. You could potentially even use your Facebook friends list or a group for Auth but I'm not familiar with details of how you would do it. – Andy Boura Aug 05 '14 at 19:59
2

HTTPS makes the authentication request unsniffable in transit. However, to make it "safe", there are other things that you also need to get right. For example:

  • The entire login page and all of its dependencies should also have been served over HTTPS, even though no password is being transmitted then. Serving any part of it (such as JavaScript, CSS, or image resources) over unencrypted HTTP would let an attacker modify the appearance or behaviour of the login page through a man-in-the-middle attack.

    Browsers will treat mixed HTTP/HTTPS content with varying degrees of suspicion. Some will merely suppress the "lock" icon in the UI. More paranoid browsers will refuse to load the unencrypted dependent resources altogether. Either way, you should serve the entire login page over HTTPS.

  • Do not submit the password in the query string of an HTTP GET. Webservers are typically configured to log the URLs of requests, which would include the query string portion of the URL. Put the password in a POST body instead. (You could also use RFC 2617 HTTP authentication, but logout support is spotty.)

Community
  • 1
200_success
  • 2,154
  • 2
  • 15
  • 20
  • Ah yes, I always remember GET is a bad idea because it is visible on the client system and may end up in client history, but forget that servers may log the parameters too. – AJ Henderson Aug 05 '14 at 16:41
1

Wikipedia that has the full page of historical HTTPS security issues.

HTTPS security bugs have happened before (why the two older versions are broken? And what is 'goto fail'? What is 'https freak'?).

I do not suggest to ditch HTTPS, but placing something additional underneath will make no harm in most cases. If you already can send unencrypted password through that channel, you can probably send whatever you want.

h22
  • 901
  • 6
  • 10
0

The use of HTTPS does not prevent attempts to brute force the password. So if you are rolling your own user account management, then you might want to consider features such as minimum password complexity and account lockout / maximum number of retries that would mitigate against such attempts.

D.H.
  • 628
  • 7
  • 14
0

It is quite safe but you should consider hashing the password also on the mobile app (on android/ios) before you send it to the server. This client side hashing however cannot replace server side hashing so best would be to hash on both client and server side. From the server perspective this password hashed on the client side becomes the real password so you still need to hash it on the server side. However from the user's perspective it is safer because even the server does not know what is the original password.

The reason to hash on the client side is that this way the server will never even receive an original password in plaintext which is good. In case someone hacks into the server and you do not hash the password on the client side then he will receive plaintext passwords and users might use those passwords also in other places/websites. So by hashing also on the client side you are protecting the user. This is especially true in your case with a mobile app because attacker who hacks into the server cannot replace the code of your mobile ios/android app. In case of a web app if he hacks to the server he could also remove the client side hashing from the javascript on your website so in that case with a web app this client side hashing might have less sense. However still it can prevent for example saving the plaintext passwords accidentally in server logs. Beside that if the attacker needs to replace the code on the server to get plaintext passwords then it means that he needs to reveal his presence on the server which could be more easily noticed by the server administrator or by other users. So even for a web app there are some advantages here.

Think how many times you heard that somebody hacked into a server? Probably many times and in such case even if you have a proper password hashing on the server side the attacker still have access to raw user passwords during their login process. Also even some larger companies such as GitHub or Twitter admitted that they accidentally logged plaintext user passwords in their server logs which would never happen if they used client side hashing in addition to server side hashing.

If you hash on the server side with a random salt (which you should do anyway) then on the mobile app side you could hash the password concatenated with any unique constant string (for example domain string or just any constant long string with random characters) which should be easy to implement and does not need any special handling on the server side. You could also concatenate username to that password and constant domain string and calculate client side hash from that.

Leszek Szary
  • 109
  • 3
  • 3
    Hashing client side is useless. It does not really matter whether the server receives an original password or a derivated string: whatever it receives is what it will use to authenticate the user. In your system, if attackers manages to access the client side hashed password, they will not even try to extract the original password, because they can just reuse that hash. – Serge Ballesta Jul 27 '21 at 14:11
  • @SergeBallesta it seems that you did not even read my whole answer. I wrote that you should hash on BOTH client and server side and explained why so your comment seems to be not related to my answer because if server is also hashing the hashed password then there is no problem. – Leszek Szary Jul 27 '21 at 14:13
  • @LeszekSzary no, he read it, he even mentioned "a derivated string". The comment is not incorrect and relates directly to your answer. – schroeder Jul 27 '21 at 14:14
  • How does someone who "hacks into the server" get the plaintext password? "the attacker still have access to raw user passwords during their login process" -- citation needed. "Accidentally saving plaintext passwords" is not in scope of the problem statement (and is a side issue). And if there was a logging issue, then the hash, which is the true password, is still exposed. We have entire threads here on client-side hashing. Client-side hashing is not a solution to the problem posed by the question; it solves a very different problem. – schroeder Jul 27 '21 at 14:19
  • 1
    @LeszekSzary: Only 2 ways exists: either the *secret* is what the server receives and it can store a hash in a non invertible way, or the server sends a nonce to the client that computes a non invertible hash using that nonce and the secret and sends that hash back. But then the server has to store the secret in clear text (or at least with a reversible encryption). Client side hashing secures the communication over an insecure channel at the price of the server *knowing* the plain text secret. – Serge Ballesta Jul 27 '21 at 14:20
  • If an attacker gets the full control on the server then I see no problem in how he can read the plaintext password send from a mobile app by modifying the code on the server side and he can then use this plaintext password in other website if user has the same password somewhere else. If it was prehashed on the mobile app side then he would not received that plaintext password. So saying that client side hashing is useless has no sense especially in case of a mobile andoid/ios app as in this question. – Leszek Szary Jul 27 '21 at 14:28
  • the attacker would use the hash ... the plaintext password is irrelevaant – schroeder Jul 27 '21 at 14:28
  • Client-side hashing solves some narrow client-side issues. It solves nothing on the server-side. Designing, testing, and maintaining client-side hashing for the sole purpose of protecting the user from themselves in one very defined use-case is not efficient and is outside the scope of responsibility of the server owner. – schroeder Jul 27 '21 at 14:30
  • I never said that client side hashing solves something on the server side. I said that it protects the user who might have used the same password in other places and that is why it should be done also on the client side. Please read the whole answer before you comment. – Leszek Szary Jul 27 '21 at 14:32
  • Oh, I read the whole thing. It's just that I've had this same discussion with dozens of people for years. The more I press them, the less sense this approach makes. Client-side hashing solves a very narrow use case for which the server owner is not responsible. The threat is that the server-side is fully compromised, the code base is changed, plaintext passwords are captured, AND the user has reused that specific password elsewhere and the attacker can know where those other accounts are. So,you are programming a function to protect the user's ***other*** accounts on services you do not own. – schroeder Jul 27 '21 at 14:33
  • And only then if some very specific conditions exist. While offering zero protections to the server, the account, or the users of ***this*** service. – schroeder Jul 27 '21 at 14:37
  • The fact that the server owner is not responsible for a user who uses the same password on every website does not mean that this server owner should make it more simple for potential attackers to get his plaintext password. If server owner can improve user's password security with almost no cost then why not do that and why risk being accused of leaking plaintext password by angry users when this can be easily prevented. – Leszek Szary Jul 27 '21 at 14:41
  • And, as I said from the beginning, this is not a solution to the problem statement in the question. And, by the way, "no cost"? As I have also been saying, designing, developing, implementing, testing, and maintaining client-side hashing most certainly has a cost .... – schroeder Jul 27 '21 at 14:43
  • I think you are incorrect by saying that this is not a solution to the problem stated in the question because the author clearly thinks that user's passwords are safe because he wrote "The password should be safe since it's sent on an encrypted connection." but they still can be obtained by the attacker without client side hashing. And I believe that encouraging people to use only server side hashing and skipping hashing on the mobile app is not the best practice. Besides a cost of implementing a hash on a mobile app as proposed is marginal. – Leszek Szary Jul 27 '21 at 14:52
  • @schroeder is right. With client hashing, the hashed password becomes equivalent to a password. This is why we have protocols like PAKE and SRP. With PAKE and SRP, the client demonstrates to the server that it knows the password, without the client sending the password (or password-equivalent data) to the server. Furthermore, the server does not store the password (or password-equivalent data). See https://security.stackexchange.com/questions/242811/alternatives-for-sending-plaintext-password-while-login/242824#242824 for more information. – mti2935 Jul 27 '21 at 14:56
  • Yes, you could implement other protocols that do not even require to send the client password to the server however in this question author is talking about sending password to the server and in this case it is better to send it pre hashed on the mobile side. Yes, the hashed password becomes equivalent to the password from the perspective of the server (so that is why I wrote it should still be hashed again on the server side) but from the perspective of the user who might have used this password somewhere else it is safer than sending plaintext password. – Leszek Szary Jul 27 '21 at 15:01
  • " is not the best practice" -- citation needed. – schroeder Jul 27 '21 at 17:46
  • So do you think that hashing only on the server side is better than pre hashing on the mobile side and then hashing it again on the server side? What is the reason for not pre hashing it on the client side before sending it to the server? I see no advantage for skipping the hashing on the client/mobile side as proposed in my answer and so far I do not see any arguments against proposed mobile side hashing in the comments above. – Leszek Szary Jul 27 '21 at 18:55
  • 1
    Well, if you ignore all the things we've mentioned, then sure, there's no reason not to. Please check out all the discussions around this topic here on this site. Please also check out what the *actual* best practices are when considering client-side hashing. And, the main point I've been making all along, it does not secure the scenario posed by the question. TLS is a safe way to pass a password. You have a "good idea" but it doesn't secure the system or process involved, and you do not account for the ways that it can legitimately be done. – schroeder Jul 27 '21 at 20:30
  • Well, I do not see any good arguments against additional hashing on the mobile app side above so I see nothing more to discuss. I think my answer adds useful informations to the question asked by the author of this topic and that with additional proposed client side hashing the solution presented in the question would be better than without it. – Leszek Szary Jul 27 '21 at 21:05