[codexon]

Then just add a time sensitive seed to it? I don't think it is equivalent to leaking plaintext. It can't be used to guess passwords on other websites.

If your SSL layer is compromised, you can't trust the client-side encryption. The attacker can send arbitrary javascript.

[Kalium]

> Then just add a time sensitive seed to it? I don't think it is equivalent to leaking plaintext. It can't be used to guess passwords on other websites.

You're reinventing password hashing and salting. Further, there's no guarantee that the has cannot be used to guess passwords on other sites. For what benefit, exactly? Your hash is now the password, and basically as dangerous as it was in a more conventional arrangement.

Pass-the-hash is a real kind of vulnerability that has been used to exploit real systems. We might be better off sticking with design approaches that don't have this problem instead of trying to fix out way out of the problem.

> If your SSL layer is compromised, you can't trust the client-side encryption. The attacker can send arbitrary javascript.

Are you sure this is what it's guarding against? A sophisticated application architecture might involve a load balancer decrypting and doing the initial routing, several sets of data handoffs, and then the application that needs it handling the password. Any one of them could mishandle or leak the password, but only the one at the end actually needs it in the clear.

[codexon]

How exactly is asking for my password to be hashed "reinventing password hashing and salting"? Seems like the opposite, no?

If your password is properly salted, it can't be used to guess passwords on other sites, that's the whole point of salt and hash.

The fact that RSA is being used means that your plain-text password is going to appear on their servers. Maybe it won't get cracked in the SSL layer, but it is still there.

> Are you sure this is what it's guarding against? A sophisticated application architecture might involve a load balancer decrypting and doing the initial routing, several sets of data handoffs, and then the application that needs it handling the password. Any one of them could mishandle or leak the password, but only the one at the end actually needs it in the clear.

Do you realize that if an adversary even only has read access to the SSL layer, they can just copy the cookie and steal the account that way?

[Kalium]

> How exactly is asking for my password to be hashed "reinventing password hashing and salting"? Seems like the opposite, no?

You've already started to add new things, like a TOTP-ish element, to stymie replays. Then the server has to check what it's been fed, having stored neither the original password nor the hash of the password it's been passed. It cannot be allowed to have the hash because the has is now the password. It need something safe-ish to store that the input can be computed on to make comparisons possible.

Now you have all the problems of server-side hashing and comparison coupled with extra client-side hoops.

Again, what have you gained?

> Do you realize that if an adversary even only has read access to the SSL layer, they can just copy the cookie and steal the account that way?

You are absolutely correct. That is completely accurate in every single possible way.

Do you think that perhaps there might be other reasons to consider here? Such as debugging, logging systems, and so on? Perhaps there are design goals beyond blocking direct attacks. On an average day, most of these systems will be more likely to be accessed and used by authorized administrators than by external adversaries, after all. Many security incidents arise not out of malice, but out of tools behaving dangerously. I know I've dealt with sensitive material leaking into logs.

I hope I have made myself clearer. I can see I failed to communicate effectively previously. Please, don't hesitate to say so if I have failed either there or in understanding your points.

[codexon]

> You've already started to add new things, like a TOTP-ish element, to stymie replays. Then the server has to check what it's been fed, having stored neither the original password nor the hash of the password it's been passed.

I don't see how this is any different from Valve "reinventing" SSL by using RSA. This isn't a new concept or roll your own crypto. I just don't want my password to be in plain-text. The only thing the server should get is the hash. If you are using RSA on the password, that means your password is going to be in plaintext on their servers eventually.

> It cannot be allowed to have the hash because the has is now the password. Now you have all the problems of server-side hashing and comparison coupled with extra client-side hoops.

The original password? Ok go ahead and encrypt it (and also hash it). But only do it once and not every login.

> Do you think that perhaps there might be other reasons to consider here? Such as debugging, logging systems, and so on? Perhaps there are design goals beyond blocking direct attacks. On an average day, most of these systems will be more likely to be accessed and used by authorized administrators than by external adversaries

It just seems strange to me that you would have trouble trusting your administrators to accidentally leak logs. What happens if they need to debug or log the app server behind the SSL layer? How likely is it that the dumb SSL termination layer is causing a problem and not the app layer?

[Kalium]

> I don't see how this is any different from Valve "reinventing" SSL by using RSA.

What Valve is doing is layering cryptography to make it possible to do access control more granular than a pure binary. What you are proposing is layering hashing in a way that does not introduce access control.

I hope this is clearer!

> I just don't want my password to be in plain-text. The only thing the server should get is the hash. If you are using RSA on the password, that means your password is going to be in plaintext on their servers eventually.

OK. Now your hashword is on the server. Your hashword now has essentially all the properties of your password that you were trying to get away from in the first place. It is de facto your password now.

Sure, it's a different string now. Your goal is accomplished and the server doesn't have your magic string. Instead it has a different one that's equally magical, equally came from you, and equally security-sensitive.

That's why pass the has was brought to your attention. Network security has been down this road before. We had login systems where the server only ever had a hash, and never the original magical string. They were not safer.

> The original password? Ok go ahead and encrypt it (and also hash it). But only do it once and not every login.

OK. So now we have a new thing that's identical to a password in all of its properties, except that it requires extra work client-side. Again, what have we gained? This is not an idle question, it's the only one that matters.

Valve has an answer, and it's a reasonably compelling one that speaks to real-life use-cases.

> It just seems strange to me that you would have trouble trusting your administrators to accidentally leak logs.

I routinely see developers do things like dump full web request contents into logs without thinking about consequences. With that in mind, I think it's very possible that exactly this kind of scenario could happen. Indeed, I think it a virtual certainty.

The plaintext of passwords being stolen from the memory of servers that handle logins is a comparatively uncommon event, as far as I know.

> What happens if they need to debug or log the app server behind the SSL layer?

A great question! That's critical info. In this scheme, they can. They just cannot access the most sensitive contents, such as passwords. Literally every other part of the request has been decrypted and is available for use.

I hope this has answered your questions.