Re: Securing Password Inputs

On Fri, Aug 31, 2012 at 12:19 AM, Arthur Clifford <art@artspad.net> wrote:
> Why not request the salt from the server?

Why would the server implement a salt to be applied on the client
which it can't verify itself?

Server programming is based on the principle that as soon as data
leaves the server it is not to be trusted. HTTP request\repsonse
cycles must essentially be treated independently.

> The server could choose whether to always use the same salt or to have
> rotating salts etc.

They can't change the salt because they don't know what the original
password was to compare against. This suggestion wasn't to protect
transfer but to obscure storage.

> The problem with specifying how to encrypt things in a public specification
> is that everybody knows how it is done, and therefore all you are doing is
> resetting the timer for hackers to figure things out. There should be
> something provided by servers that the server knows and trusts.

Exactly. There is a reason why security folks are cagey.

>
>
> -Art C
>
>

Thanks,
Cameron Jones

Received on Friday, 31 August 2012 14:12:15 UTC