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

[silky]

On Sun, Feb 22, 2009 at 6:33 AM, Ed Gerck <edgerck at nma.com> wrote:
> List,
>
> In a business, one must write down the passwords and one must have a
> duplicate copy of it, with further backup, where management can access it.
> This is SOP.
>
> This is done not just in case the proverbial truck hits the employee, or
> fire strikes the building, or for the disgruntled cases, but because people
> do forget and a company cannot be at the same time responsible to the
> shareholders for its daily operations and not be responsible for the
> passwords that pretty much define how those daily operations are run.
>
> The idea that people should not write their passwords is thus silly from the
> security viewpoint of assuring availability and also for another reason.
> Users cannot be trusted to follow instructions. So, if one's security
> depends on their users following instructions, then something is wrong from
> the start.
>
> Solving password problems one at a time.
>
> I submit that the most important password problem is not that someone may
> find it written somewhere. The most important password problem is that
> people forget it. So, writing it down and taking the easy precaution of not
> keeping next to the computer solves the most important problem with not even
> a comparably significant downside. Having automatic, secure, and
> self-managed password recovery and password reset (in case the password
> cannot be recovered) apps are also part of this solution.
>
> I see the second most important problem in passwords to be that they usually
> have low entropy -- ie, passwords are usually easily guessable or easy to
> find in a quick search.
>
> The next two important problems in passwords are absence of mutual
> authentication (anti-phishing) and absence of two-factor authentication.
>
> To solve these three problems, at the same time, we have been experimenting
> since 2000 with a scheme where the Username/Password login is divided in two
> phases. In different applications in several countries over nine years, this
> has been tested with many hundreds of thousands of users and further
> improved. (you can also test it if you want). It has just recently been
> applied for TLS SMTP authentication where both the email address and the
> user's common name are also authenticated (as with X.509/PKI but without the
> certificates).
>
> This is how it works, both for the UI and the engine behind it.
>
> (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).

And FWIW, renaming "password" to "usercode" doesn't make it more secure.


> (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 ...)


> (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.


> 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.


> 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.


> 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.


> 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.


> Usability considerations still must be applied, of course, but not to solve
> the security problem. I submit that trying to solve the security problem
> while facing usability restrictions is what has prevented success so far.
>
> Comments are welcome. More at <www.Saas-ST.com>

Stop spamming?


> Best regards,
> Ed Gerck
> ed at gerck.com

-- 
noon silky
http://www.boxofgoodfeelings.com/

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