Solving password problems one at a time, Re: The password-reset paradox

[Ed Gerck]

silky wrote:
> On Sun, Feb 22, 2009 at 6:33 AM, Ed Gerck <edgerck at nma.com> wrote:
>   
>> (UI in use since 2000, for web access control and authorization) After you
>> enter a usercode in the first screen, you are presented with a second screen
>> to enter your password. The usercode is a mnemonic 6-character code such as
>> HB75RC (randomly generated, you receive from the server upon registration).
>> Your password is freely choosen by you upon registration.That second screen
>> also has something that you and the correct server know but that you did not
>> disclose in the first screen -- we can use a simple three-letter combination
>> ABC, for example. You use this to visually authenticate the server above the
>> SSL layer. A rogue server would not know this combination, which allays
>> spoofing considerations -- if you do not see the correct three-letter
>> combination, do not enter your password.
>>     
>
> Well, this is an old plan and useless. Because any rogue server can
> just submit the 'usercode' to the real server, and get the three
> letters. Common implementations of this use pictures (cats dogs family
> user-uploaded, whatever).
>   

Thanks for the comment. The BofA SiteKey attack you mention does not 
work for the web access scheme I mentioned because the usercode is 
private and random with a very large search space, and is always sent 
after SSL starts (hence, remains private). The attacker has a 
/negligible/ probability of success in our case, contrary to a case 
where the user sends the email address to get the three letters -- which 
is trivial to bypass.
<http://nma.com/papers/zsentryid-web.pdf>
>> (UI in use since 2008, TLS SMTP, aka SMTPS, authentication). The SMTP
>> Username is your email address, while the SMTP Password is obtained by the
>> user writing in sequence the usercode and the password. With TLS SMTP,
>> encryption is on from the start (implict SSL), so that neither the Username
>> or the Password are ever sent in the clear.
>>     
>
> I have no idea what you're referring to here. It doesn't seem to make
> sense in the context of the rest of your email. Are you saying your
> system is useless given SSL? (Aside from the fact that it's useless
> anyway ...)
>   

I'm referring to SMTP authentication with implicit SSL. The same 
usercode|password combination is used here as well, but the usercode is 
prepended to the password while the username is the email address. In 
this case, there is no anti-phishing needed.

>> (UI 2008 version, web access control) Same as the TLS SMTP case, where a
>> three-letter combination is provided for user anti-spoofing verification
>> after the username (email address) is entered. In trust terms, the user does
>> not trust the server with anything but the email address (which is public
>> information) until the server has shown that it can be trusted (to that
>> extent) by replying with the expected three-letter combination.
>>     
>
> Wrong again, see above.
>   

This case has the  same BofA SiteKey vulnerability. However, if that is 
bothersome, the scheme can also send a timed nonce to a cell phone, 
which is unknown to the attacker. This is explained elsewhere in 
http://nma.com/papers/zsentryid-web.pdf

(there are different solutions for different threat models)

>> In all cases, because the usercode is not controlled by the user and is
>> random, it adds a known and independently generated amount of entropy to the
>> Password.
>>     
>
> Disregarding all of the above, consider that it may not be random, and
> given that you can generate them on signup there is the potential to
> know or learn the RNG a given site is using.
>   

If the threat model is that you can "learn or know the RNG a given site 
is using" then the answer is to use a hardware RNG.

>> With a six-character (to be within the mnemonic range) usercode, usability
>> considerations (no letter case, no symbols, overload "0" with "O", "1" with
>> "I", for example), will reduce the entropy that can be added to (say) 35
>> bits. Considering that the average poor, short password chosen by users has
>> between 20 and 40 bits of entropy, the end result is expected to have from
>> 55 to 75 bits of entropy, which is quite strong.
>>     
>
> Doesn't really matter given it prevents nothing. Sites may as well
> just ask for two passwords.
>   
The point is that two passwords would still not have an entropy value 
that you can trust, as it all would depend on user input.
>> This can be made larger by,
>> for example, refusing to accept passwords that are less than 8 characters
>> long, by and adding more characters to the usercode alphabet and/or usercode
>> (a 7-character code can still be mnemonic and human friendly).
>>
>> The fourth problem, and the last important password problem that would still
>> remain, is the vulnerability of password lists themselves, that could be
>> downloaded and cracked given enough time, outside the access protections of
>> online login (three-strikes and you're out). This is also solved in our
>> scheme by using implicit passwords from a digital certificate calculation.
>> There are no username and password lists to be attacked in the first place.
>> No target, hence not threat.
>>     
>
> Eh? So what data was used to do the digital certificate calculation?
> That's still around.
>   

That data is just a key that is the same for /all/ users. It is not 
user-specific. its knowledge does not provide information to attack any 
account.

>> In other words, to solve the fourth password problem we shift the
>> information security solution space. From the yet-unsolved security problem
>> of protecting servers and clients against penetration attacks to a
>> connection reliability problem that is easily solved today.
>>
>> This approach of solving password problems one at a time, shows that the
>> "big problem" of passwords is now reduced to rather trivial data management
>> functions -- no longer usability or data security functions.
>>     
>
> Sorry, you've solved nothing.
>   
Sorry if it wasn't clear. Please have a second reading.

Cheers,
Ed Gerck

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com