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

[Anne & Lynn Wheeler]

On 05/09/09 07:33, Jerry Leichter wrote:

I had a discussion with a guy at a company that was proposing to create
secure credit cards by embedding a chip in the card and replacing some
number of digits with an LCD display. The card would generate a unique
card number for you when needed. They actually had the technology
working - the card was pretty much indistinguishable from any other. (Of
course, how rugged it would be in typical environments is another
question - but they claimed they had a solution.)



Deloitte staff trial Visa card with built in OTP generator for IT access control
http://www.finextra.com/fullstory.asp?id=20019



--
40+yrs virtualization experience (since Jan68), online at home since Mar1970

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

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

[Anne & Lynn Wheeler]

On 05/09/09 07:33, Jerry Leichter wrote:

On May 8, 2009, at 3:39 PM, Ian G wrote:

The difficulty with client certs is that I need them to also work on my
laptop. And my other laptop. And my phone.

So, how do I get hold of them when I'm on the road?


Good point. The difficulty with my passwords is that I have so many
that are so long that I can only manage them on my laptop, and have to
carry my laptop with me ...

We can imagine all sorts of techie solutions to this, but it does
appear that we are in a bit of a grey zone with auth at the moment,
and the full solution might take a while to emerge. Try them all?

This is part of a broader UI issue.

I had a discussion with a guy at a company that was proposing to create
secure credit cards by embedding a chip in the card and replacing some
number of digits with an LCD display. The card would generate a unique
card number for you when needed. They actually had the technology
working - the card was pretty much indistinguishable from any other. (Of
course, how rugged it would be in typical environments is another
question - but they claimed they had a solution.)

I pointed out that my wife knows one of her CC numbers by heart. The
regularly quotes it, both on phone calls and to web forms. The card
itself is buried in a thick wallet, which is buried in her pocketbook,
which is somewhere in the house - likely not near the phone or the
computer.

Hell, one of the nice things about on-line shopping is that I can do it
in my bathrobe - except that I *don't* know my CC by heart, so in fact I
tend to put off buying until later when I have my wallet with me. (This
does save me money)

When I'm in a store, I'm used to having to have my CC with me, because I
always had to have the wallet with money anyway. At home, it's a whole
different story. In any case, merchants are trying to make the in-store
experience as simple as possible, pushing for things like RFID credit
cards and even fingerprint recognition.

So many people would see these "safer" cards as a big step backwards in
usability. Why would they want such a thing? The card companies are
trying to sell "safety", but in the US, where your liability is at most
$50 if your CC number is stolen (and where in practice it's $0), the
only cost you as an individual bear is the inconvenience of replacing a
card. Because replacements for security problems have gotten so common,
the CC companies have streamlined the process. It's really no big deal.
I've had CC numbers stolen a couple of times (by means unknown);
recently, two of my CC's were replaced by the companies based on some
information known only to them. In every case, the process was very
quick and painless. Hell, these days even on-line continuing charges
often update to the new number automatically (though I've learned to
keep track of those and check).

The person arguing for this claimed that CC companies could offer a
discount for users of the "secure" cards. But if you look at actual loss
rates - how much could you offer? (I'd guess it's about the same as
Discover offers: About a 1.5% rebate on most purchases. Not enough to
let Discover steal customers from Visa and MC. Given all the other
charges - and the absurdly high interest rates - on cards, anything like
this gets lost in the noise.)

Security that depends on people changing their habits in a way that is
inconvenient to them ... won't happen (unless you're in an environment
where you can *force* such changes).
-- Jerry


at least the initial introduction of one-time-account number displays
had a problem because they couldn't meet the flexing specification
(like cards in mens wallet and getting sat on).

note that there has been big push to "signature debit" (similar interchange
fees and fraud as "signature credit") with 15 times the fraud of PIN-debit
(which has significantly lower interchange fees compared to signature debit)
reference
http://www.digitaltransactions.net/newsstory.cfm?newsid=73
mentioned in this post from 2006
http://www.garlic.com/~lynn/2006e.html#21

there has been some articles about "unsafe" cards being a profit item
for financial institutions ... since they charge merchants a significantly
higher interchange fee. there have been references that there can be
as much as a order of magnitude difference in fees between "unsafer" transaction
fees and "safer" transaction... with "unsafe" transaction fees
contributing significantly to reports that payment fees have represented
as much as 40% of bottom line for US consumer financial institutions
(an order of magnitude reduction would be a big hit). part of thread
on this subject in this mailing list from two years ago
http://www.garlic.com/~lynn/aadsm27.htm#31
http://www.garlic.com/~lynn/aadsm27.htm#32
http://www.garlic.com/~lynn/aadsm27.htm#33
http://www.garlic.com/~lynn/aadsm27.htm#34
http://www.garlic.com/~lynn/aadsm27.htm#35
http://www.garlic.com/~lynn/aadsm27.htm#37
http://www.garlic.com/~lynn/aadsm27.htm#38
http://www.garlic

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

[Jerry Leichter]

On May 8, 2009, at 3:39 PM, Ian G wrote:
The difficulty with client certs is that I need them to also work  
on my

laptop. And my other laptop. And my phone.

So, how do I get hold of them when I'm on the road?


Good point.  The difficulty with my passwords is that I have so many  
that are so long that I can only manage them on my laptop, and have  
to carry my laptop with me ...


We can imagine all sorts of techie solutions to this, but it does  
appear that we are in a bit of a grey zone with auth at the moment,  
and the full solution might take a while to emerge.  Try them all?

This is part of a broader UI issue.

I had a discussion with a guy at a company that was proposing to  
create secure credit cards by embedding a chip in the card and  
replacing some number of digits with an LCD display.  The card would  
generate a unique card number for you when needed.  They actually had  
the technology working - the card was pretty much indistinguishable  
from any other.  (Of course, how rugged it would be in typical  
environments is another question - but they claimed they had a  
solution.)


I pointed out that my wife knows one of her CC numbers by heart.  The  
regularly quotes it, both on phone calls and to web forms.  The card  
itself is buried in a thick wallet, which is buried in her pocketbook,  
which is somewhere in the house - likely not near the phone or the  
computer.


Hell, one of the nice things about on-line shopping is that I can do  
it in my bathrobe - except that I *don't* know my CC by heart, so in  
fact I tend to put off buying until later when I have my wallet with  
me.  (This does save me money)


When I'm in a store, I'm used to having to have my CC with me, because  
I always had to have the wallet with money anyway.  At home, it's a  
whole different story.  In any case, merchants are trying to make the  
in-store experience as simple as possible, pushing for things like  
RFID credit cards and even fingerprint recognition.


So many people would see these "safer" cards as a big step backwards  
in usability.  Why would they want such a thing?  The card companies  
are trying to sell "safety", but in the US, where your liability is at  
most $50 if your CC number is stolen (and where in practice it's $0),  
the only cost you as an individual bear is the inconvenience of  
replacing a card.  Because replacements for security problems have  
gotten so common, the CC companies have streamlined the process.  It's  
really no big deal.  I've had CC numbers stolen a couple of times (by  
means unknown); recently, two of my CC's were replaced by the  
companies based on some information known only to them.  In every  
case, the process was very quick and painless.  Hell, these days even  
on-line continuing charges often update to the new number  
automatically (though I've learned to keep track of those and check).


The person arguing for this claimed that CC companies could offer a  
discount for users of the "secure" cards.  But if you look at actual  
loss rates - how much could you offer?  (I'd guess it's about the same  
as Discover offers:  About a 1.5% rebate on most purchases.  Not  
enough to let Discover steal customers from Visa and MC.  Given all  
the other charges - and the absurdly high interest rates - on cards,  
anything like this gets lost in the noise.)


Security that depends on people changing their habits in a way that is  
inconvenient to them ... won't happen (unless you're in an environment  
where you can *force* such changes).

-- Jerry

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

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

[Peter Gutmann]

Ben Laurie  writes:

>Incidentally, the reason we don't use EKE (and many other useful schemes) is
>not because they don't solve our problems, its because the rights holders
>won't let us use them.

That's not the reason, TLS-SRP isn't that annoyingly encumbered, and even the 
totally unencumbered TLS-PSK doesn't get used by anyone.  I was told a reason 
for the lack of use of strong password protocols from one browser vendor that 
was so stunningly stupid that I had trouble beliving that it was for real, ask 
me in private mail if you want the details.  In any case though it's not 
patent issues that are leading to non-use.

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

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

[Ben Laurie]

Steven M. Bellovin wrote:
> We've become prisoners of dogma here.  In 1979, Bob Morris and Ken
> Thompson showed that passwords were guessable.  In 1979, that was
> really novel.  There was a lot of good work done in the next 15 years
> on that problem -- Spaf's empirical observations, Klein's '90 paper on
> improving password security, Lamport's algorithm that gave rise to
> S/Key, my and Mike Merritt's EKE, many others.  Guess what -- we're not
> living in that world now.  We have shadow password files on Unix
> systems; we have Kerberos; we have SecurID; we have SSL which rules out
> the network attacks and eavesdropping that EKE was intended to counter;
> etc.  We also have web-based systems whose failure modes are not nearly
> the same.  Why do we think that the solutions are the same?  There was
> a marvelous paper at Hotsec '07 that I resent simply because the
> authors got there before me; I had (somewhat after them) come to the
> same conclusions: the defenses we've built up against password failure
> since '79 don't the problems of today's world.  We have to recognize
> the new problems before we can solve them.  (I *think* that the paper
> is at
> http://www.usenix.org/events/hotsec07/tech/full_papers/florencio/florencio.pdf
> but I'm on an airplane now and can't check...

That's a pretty annoying paper.

Firstly, I don't care about the average rate of account compromise for
sites that host my stuff, I only care about _my_ account. This means
that I cannot, despite their claim, write down my long, "secret" user ID
because if anyone ever sees it, I'm sunk because of the short password
they are advocating.

Secondly, they claim that user IDs are in practice secret, on the basis
that if they weren't, then sites would be experiencing massive DoS
attacks. To prove this claim, they cite a case where SSNs are used as
user IDs. Now, if there's one thing we know, it's that SSNs aren't even
a little bit secret. Therefore the reason there is no widepsread DoS is
because no-one wants to mount the attack.

Thirdly, they really need to learn when to use apostrophes!

Incidentally, the reason we don't use EKE (and many other useful
schemes) is not because they don't solve our problems, its because the
rights holders won't let us use them.

> But usability is *the* problem, with server and client penetration a
> close second.

On this we agree. We do have any number of decent cryptographic schemes
that would complete solve phishing. All we have to do is figure out:

a) How to show the user that he is actually using the scheme and is not
being phished.

b) Get it rolled out everywhere.

I am not holding my breath, though perhaps '09 is the year for action?

-- 
http://www.apache-ssl.org/ben.html   http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

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

[Steven M. Bellovin]

On Sat, 21 Feb 2009 11:33:32 -0800
Ed Gerck  wrote:

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

Up to a point.  The "most important password problem" is very much
context-dependent.  I'm not going to forget the unlock password to my
laptop, because I use it many times/day.  I regularly forget my login
password to the CS department's servers because I use it so rarely --
as best I can tell, I haven't used it in at least 15 months, because I
use public key authentication for most functions.  They've installed
some new service that will require it, though, so I suppose I need to
learn it.

However -- if you're talking about garden-variety web passwords, you're
probably correct.  

For your last sentence, see my next response...

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

Define "automatic" and "secure".  "Self-managed" is context-dependent.
It's true for generic web authentication; it most certainly is not for
more serious ones.  The generic recovery/reset mechanisms have their
own security issues -- how secure is the back-up authentication
systems?  In most cases, the answer is "much less secure than the base
mechanism".
> 
> 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.

So -- why does that matter?

We've become prisoners of dogma here.  In 1979, Bob Morris and Ken
Thompson showed that passwords were guessable.  In 1979, that was
really novel.  There was a lot of good work done in the next 15 years
on that problem -- Spaf's empirical observations, Klein's '90 paper on
improving password security, Lamport's algorithm that gave rise to
S/Key, my and Mike Merritt's EKE, many others.  Guess what -- we're not
living in that world now.  We have shadow password files on Unix
systems; we have Kerberos; we have SecurID; we have SSL which rules out
the network attacks and eavesdropping that EKE was intended to counter;
etc.  We also have web-based systems whose failure modes are not nearly
the same.  Why do we think that the solutions are the same?  There was
a marvelous paper at Hotsec '07 that I resent simply because the
authors got there before me; I had (somewhat after them) come to the
same conclusions: the defenses we've built up against password failure
since '79 don't the problems of today's world.  We have to recognize
the new problems before we can solve them.  (I *think* that the paper
is at
http://www.usenix.org/events/hotsec07/tech/full_papers/florencio/florencio.pdf
but I'm on an airplane now and can't check...

> The next two important problems in passwords are absence of mutual 
> authentication (anti-phishing)

Personally, I think this is the biggest problem when it comes to
phishing attacks.

> and absence of two-factor
> authentication.

What problem does two-factor solve?  I agree that it's helpful, but
until we know the threat we can't solve it.
> 
> 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.

As Peter Gutmann has pointed out, that has succeeded only because it
hasn't been seriously attacked.  Research results show that users are
very easily fooled by "changes" to the server

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

[silky]

On Tue, Feb 24, 2009 at 12:23 PM, Ed Gerck  wrote:
[snip]
> What usercode? The point you are missing is that there are 2^35 private
> usercodes and you have no idea which one matches the email address that you
> want to sent your phishing email to.

What you're missing is that it doesn't matter. The user enters the
usercode! So they enter it into the phishing site which passes the
call along.

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

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

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

[Ed Gerck]

silky wrote:

On Tue, Feb 24, 2009 at 8:30 AM, Ed Gerck  wrote:
[snip]
  

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



This is meaningless. What attack is the 'usercode' trying to prevent?
You said it's trying to authorise the site to the user. It doesn't do
this, because a 3rd party site can take the usercode and send it to
the 'real' site.
  


What usercode? The point you are missing is that there are 2^35 private 
usercodes and you have no idea which one matches the email address that 
you want to sent your phishing email to.


The other points, including the  TLS SMTP login I mentioned, might be 
clearer with an example. I'll be happy to provide you with a test account.


Cheers,
Ed Gerck

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

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

[silky]

On Tue, Feb 24, 2009 at 8:30 AM, Ed Gerck  wrote:
[snip]
> 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).

This is meaningless. What attack is the 'usercode' trying to prevent?
You said it's trying to authorise the site to the user. It doesn't do
this, because a 3rd party site can take the usercode and send it to
the 'real' site.


[snip]
> 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.

Eh? This still doesn't make any particular amount of sense.


[snip]
> 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

Anything you do can be simulated by an evil site. Sending a key to a
phone is a good idea, but still, in the end, useless, because the evil
site can simulate it by passing whatever requested the user did to
that site.


[snip]
> 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.

No, it isn't.


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

*shrug* make one of them autogenerated. Doesn't matter. You're just
adding complexity for no real benefit.


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

Well I'm sorry but you don't understand your own system then.
Obviously it must have information to 'attack' a given account,
because you used it to generate something. The function you used did
something, so you can repeat it if you have all the inputs.


> Sorry if it wasn't clear. Please have a second reading.

Indeed.


> Cheers,
> Ed Gerck

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

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

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

[Ed Gerck]

James A. Donald wrote:

No one is going to check for the correct three letter
combination, because it is not part of the work flow, so
they will always forget to do it.


Humans tend to notice patterns. We  easily notice mispelngs. Your 
experience may be different but we found out in testing that 
three-letters can be made large enough to become a visually noticeable 
pattern.


Reversing the point, the fact that a user can ignore the three-letters 
is useful if the user forgets them. The last thing users want is one 
more hassle. The idea is to give users a way to allay spoofing concerns, 
if they so want and are motivated to, or learn to be motivated. Mark 
Twain's cat was afraid of the cold stove.


Cheers,
Ed Gerck

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

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

[James A. Donald]

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

No one is going to check for the correct three letter
combination, because it is not part of the work flow, so
they will always forget to do it.

It might work if you have something that dramatically
alters the overall look of the page and organization of
the page, such as a big skin with a big graphic,
editable by user, and initially randomly generated per
user.  If you put the fields in different places,
depending on the user, then user will have to pay
attention when fields are not where he expects them to
be.

It would also help if you made the login page
extensively user customizable, and ask the user to
customize it in order to protect himself against
phishing.  When suddenly his customizations vanish, he
will instantly and instinctively feel that what is his
has been taken, and appropriately perceive himself to be
under attack.

But a better solution would be to use SRP or J-Pake so
that a successful phish fails to reveal the password.

Unfortunately, for reasons that are entirely unclear to
me, there is passionate resistance to building J-Pake or
SRP into the browser - we need a UI in the browser, and
a PHP module on the server, to make these actually
usable.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: 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  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 
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 at

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

[silky]

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

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

[Dave Kleiman]

>> On February 21, 2009 14:34, Ed Gerck wrote:
>> 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.

Most organizations I interact with have an SOP that nobody should ever know 
another's password. The only passwords that are safe stored are those for 
encryption or the top level admin. You take on a degree of legal responsibility 
if you have the ability to logon as another user. Since the admin can easily 
change a user's password, what would be the necessity for this risk? All 
password changes should be audited.


Respectfully,

Dave Kleiman - http://www.ComputerForensicExaminer.com 
4371 Northlake Blvd #314
Palm Beach Gardens, FL 33410
561.310.8801 




-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com