silky wrote:
On Sun, Feb 22, 2009 at 6:33 AM, Ed Gerck <> 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.
(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

(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

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.

Ed Gerck

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to

Reply via email to