quote:

Originally posted by architect:
<snip>
The Achilles heel of a hash-based authentication store is that the challenge must be presented "in the clear" so there is an additional attack surface that has to be addressed.
<snip>

The challenge is a request to enter your username and password. No security issue with that challenge. The response to that challenge is certainly not presented "in the clear" – it’s encrypted.

Am I misunderstanding your comment?

At work, we had a Secure Id token. A small device that used a rolling code much like a garage door opener

quote:

Originally posted by Pipe Smoker:

quote:

Originally posted by architect:
<snip>
The Achilles heel of a hash-based authentication store is that the challenge must be presented "in the clear" so there is an additional attack surface that has to be addressed.
<snip>

The challenge is a request to enter your username and password. No security issue with that challenge. The response to that challenge is certainly not presented "in the clear" – it’s encrypted.

Am I misunderstanding your comment?

Yes.

I'm using the word "challenge" as a general term for credential presentation, not as a specific challenge/response mechanism. My comment was intended to illustrate that various authentication methods are not without their costs, closing a "hole" in one aspect often exposes an attack surface in another.

Basically, if the entity you are authenticating against maintains their knowledge base (e.g. a list of valid passwords) in hashed or encrypted form, they must receive your credentials in plain text. Only if they maintain a plain text knowledge base can credentials be presented in encrypted or hashed formats. So somewhere there has to be plain text in the conversation or on a storage medium, which is open to interception by an out-of-bounds attack.

quote:

Originally posted by architect:

Basically, if the entity you are authenticating against maintains their knowledge base (e.g. a list of valid passwords) in hashed or encrypted form, they must receive your credentials in plain text. Only if they maintain a plain text knowledge base can credentials be presented in encrypted or hashed formats. So somewhere there has to be plain text in the conversation or on a storage medium, which is open to interception by an out-of-bounds attack.

Just adding some clarity for the thread, not disagreeing.

Credentials entered in the browser on a secure site are encrypted in transit as part of the browser session, but then would be decrypted at the other end. Thus, plain text presentation to the authentication layer.

quote:

Originally posted by Pipe Smoker:

quote:

For those who hate repeatedly entering usernames and passwords

With a good PW Manager it isn’t hard. The PW Manager apps on my iPhone and MacBook sync. Change an entry in one device and it’s almost immediately changed on the other device too.

Do you use one you’d care to recommend?

^^^^^
I use mSecure. $14.99/year. There are free apps for my MacBook and iPhone. Probably PC and Android too. I pay the annual fee via an Apple “subscription”. Very convenient.

There’s a media choice for syncing the apps: Wi-Fi, Dropbox, and mSecure’s own server. I use the latter. No additional cost, and no third-party involved. I’ve never seen that server down.

I’ve used mSecure for more than ten years.