Figured I’d expand on something Alex said in response to you.

Client side should not hash the password which I am fairly sure would allow pass-the-hash, but don’t quote me on that.

Basically hashing it on the client doesn’t solve the problem it just shifts it a bit. Instead of needing to capture and then send the plaintext password to the server. An attacker would simply need to capture and send the hash as generated by the client to the server. In both cases an attacker with access to the plain communication between client and server would have all the information necessary.

Basically if you hash it on the client-side, you’ve just made the hash the password that needs to be protected as an attacker only needs to “pass the hash” to the server.

That said you are raising a legitimate concern and its a great question that shows you’re starting to think about the issues at hand. Because, you’re right. When we send the password in plaintext at the application layer we are simply trusting that the communication channel is secure, and that is not a safe assumption.

There is a bit of a rabbit hole regarding authentication schemes you can dive into and there is a scheme that adds a bit more onto the simple idea of just hashing the password on the client-side. Basically, the server provides a nonce (a one-time use value) to the client. The client hashes their password with this nonce included and sends the resultant hash back to the server to be validated. It kinda solves the issue of someone being able to read the communication as the hash being sent over the wire is only useful in response to that specific nonce for that specific user.

The trade-off on this is that in-order for the server to be able to validate the response from the client, the server must have access to that same key-data the client hashed with the nonce, AKA passwords needs to be stored in a recoverable way. You increase security against a compromised communication channel, but also increased the damage that an attacker could do if they could leak the database.

Going further down the rabbit hole, there is Salted Challenge-Response Authentication which takes a step towards alleviating this by storing a salted and hashed version of the password. And then providing the client the nonce as usual along with the salt and other information needed for the client to reproduce the version of the hash the server is storing. This does mean passwords are not in “plaintext” but it has in effect made the hashed version the password that should be protected. Anyone who compromises the database still has all the information necessary to generate the response for any nonce. They just couldn’t try for password reuse stuff like one could if it was actually recoverable.

Ultimately, this comes down to what is the bigger threat. You can (somewhat) secure against a compromised communication channel (which is generally a targeted attack against only one user at a time), but it means that some server side vulnerabilities will be able to compromise every user account. In general, for web-apps I think you’re better off hardening the server-side and having mitigations like 2FA around sensitive actions to limit the damage just compromising the password could do.

Also, if you really wanted to be more secure against communication channel issues, public key cryptography is a better tool for that, but has generally not be well supported for web-apps.

deleted by creator

sure

Since I’ve made my career on the AppSec and research side of the fence I do have a few recommendations on that side of things:

Absolute AppSec - Discussion of the week sort of podcast, from a couple of experience AppSec guys. I originally came across them because they seem to be one of the few resources really talking details about source code review (they offer a training on it). Which is just one of those areas that kinda easy to talk about but really hard to teach (imo). But yeah they’ll generaly just discuss a few topics from recent news and how it impacts AppSec. Good variety here, sometimes offensive, sometimes defensive, sometimes its something else. The hosts occasionally will disagree and will have some solid discussions on it.

Critical Thinking: Bug Bounty Podcast - More of a bug bounty focus. While priorities differ between more general AppSec assessments and bug bounty, there is enough overlap to make the podcast worthwhile. Fairly discussional podcast, kinda a discussion of the week sometimes riffing off of recent vulnerability disclosures but also getting into other aspects like tooling and methodology.

Dayzerosec - I cohost this podcast with a friend, we both work in vulnerability research and exploit development so we are kinda just doing a podcast on what we would find interesting. talking about root causes, and exploitation of whatever interesting bugs were disclosed in the last week-ish. Its a very technical podcast and we don’t really tend to cover news/attacks. We do two episodes a week, one focused on “bug bounty” style issues, just higher-level appsec and websec stuff, and one lower-level memory corruption and occasionally hardware layer attacks. Though we also put out summaries of many of the vulnerabilities we cover https://dayzerosec.com/vulns