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

2009-05-21 Thread 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

2009-05-09 Thread 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

2009-05-09 Thread 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

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

2009-05-06 Thread Peter Gutmann
Ben Laurie b...@links.org 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

2009-04-30 Thread 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

2009-03-02 Thread Steven M. Bellovin
On Sat, 21 Feb 2009 11:33:32 -0800
Ed Gerck edge...@nma.com 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.  In the scenario you
cite, all it 

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

2009-02-24 Thread Ed Gerck

silky wrote:

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

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

2009-02-24 Thread 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

2009-02-24 Thread silky
On Tue, Feb 24, 2009 at 8:30 AM, Ed Gerck edge...@nma.com 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

2009-02-24 Thread Ed Gerck

silky wrote:

On Tue, Feb 24, 2009 at 8:30 AM, Ed Gerck edge...@nma.com 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

2009-02-24 Thread silky
On Tue, Feb 24, 2009 at 12:23 PM, Ed Gerck edge...@nma.com 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: The password-reset paradox

2009-02-23 Thread Ian G

On 19/2/09 14:36, Peter Gutmann wrote:

There are a variety of password cost-estimation surveys floating around that
put the cost of password resets at $100-200 per user per year, depending on
which survey you use (Gartner says so, it must be true).

You can get OTP tokens as little as $5.  Barely anyone uses them.



The two numbers are not comparable.  One is the business cost to a 
company including all the internal, absorbed costs (see Steve's email), 
while the other is the pricelist of the supplier, without internal 
user-company costs.


If we compared each method using the other's methodology, passwords 
would list at $0 per reset, and tokens recoveries would estimate at 
$105 to $205, plus shipping.




Can anyone explain why, if the cost of password resets is so high, banks and
the like don't want to spend $5 (plus one-off background infrastructure costs
and whatnot) on a token like this?



It is a typical claim of the smart card  tokens industry that that the 
bulk unit cost of their product is an important number.  This is 
possibly because the sellers of such product cannot offer the real 
project work because they are too product oriented and/or too small.  So 
they have to sell on somthing, and push the number.  It is for this 
reason that IBM once ruled the world, they bypassed the whole 
listprice/commodity issue.


As a humourous aside, here's another deceptive sales approach available 
to the token world, the end of something we know security, as we know 
it :)


http://www.technologyreview.com/computing/22201/?a=f



iang

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


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

2009-02-23 Thread Ed Gerck

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.


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


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


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.


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

RE: The password-reset paradox

2009-02-23 Thread Charlie Kaufman
I would assume (hope?) that when you have an OTP token, you get two factor
authentication and don't stop needing a password. You would need a password
either to unlock the OTP device or to enter alongside the OTP value. Otherwise,
someone who finds your token can impersonate you.

Assuming that's true, OTP tokens add costs by introducing new failure modes 
(e.g.,
I lost it, I ran it through the washing machine, etc.). I suspect a similar 
study
would find that the cost of the OTP token would be $500-$700/yr. even if the
device itself only cost $5. After all, passwords are free!

--Charlie

-Original Message-
From: owner-cryptogra...@metzdowd.com [mailto:owner-cryptogra...@metzdowd.com] 
On Behalf Of Peter Gutmann
Sent: Thursday, February 19, 2009 5:36 AM
To: cryptography@metzdowd.com
Subject: The password-reset paradox

There are a variety of password cost-estimation surveys floating around that
put the cost of password resets at $100-200 per user per year, depending on
which survey you use (Gartner says so, it must be true).

You can get OTP tokens as little as $5.  Barely anyone uses them.

Can anyone explain why, if the cost of password resets is so high, banks and
the like don't want to spend $5 (plus one-off background infrastructure costs
and whatnot) on a token like this?

(My guess is that the password-reset cost estimates are coming from the same
place as software and music piracy figures, but I'd still be interested in any
information anyone can provide).

Peter.

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

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


Re: The password-reset paradox

2009-02-23 Thread Debra L Cook



On Fri, 20 Feb 2009, Jerry Leichter wrote:


On Feb 19, 2009, at 8:36 AM, Peter Gutmann wrote:

There are a variety of password cost-estimation surveys floating around 
that

put the cost of password resets at $100-200 per user per year, depending on
which survey you use (Gartner says so, it must be true).


You can get OTP tokens as little as $5.  Barely anyone uses them.

Can anyone explain why, if the cost of password resets is so high, banks 
and
the like don't want to spend $5 (plus one-off background infrastructure 
costs

and whatnot) on a token like this?

(My guess is that the password-reset cost estimates are coming from the 
same
place as software and music piracy figures, but I'd still be interested in 
any

information anyone can provide).
I suspect some very biased analysis.  For example, people who really need 
their passwords reset regularly will probably lose their tokens just as 
regularly.  The cost of replacing one of those is high - not for the token 
itself, but for the administrative costs, which *must* be higher than for a 
password reset since they include all the work in a password reset (properly 
authenticating user/identifying account probably contribute the largest 
costs), plus all the costs of physically obtaining, registering, and 
distributing a replacement token - plus any implied costs due to the delays 
needed to physically deliver the token versus the potential for an 
instantaneous reset.


I suppose the $100-$200 estimate might make sense for an organization that 
actually does password resets in a secure, carefully managed fashion. 
Frankly ... I, personally, have never seen such an organization.  Password 
resets these days are mainly automated, with authentication and 
identification based on very weak secondary security questions.  Even 
organizations you'd expect to be secure authenticate password reset 
requests based entirely on public information (e.g., if you know the name and 
badge number of an employee and the right help desk to call, you can get the 
password reset).  New passwords are typically delivered by unsecured email. 
All too many organizations reset to a fixed, known value.


It's quite true that organizations have found the costs of password resets to 
be too high.  What they've generally done is saved money on the reset process 
itself, pushing the cost out into whatever budgets will get hit as by the 
resulting security breaches.

  -- Jerry



Peter.



There is nothing technical in the following, but I wanted to reply because 
the cost issue isn't the only reason. The format of the token and user

interface are just as important. Think of a user with multiple accounts and
how to have the tokens on a single device with a single user interface 
when the banks don't use the same token vendor.


For large banks, cost was cited as a reason - both for deployment and 
synchronizations/replacements. Another issue is that even with banks and

brokerage firms in the US that offer tokens to customers, the bank thinks in
term of the customer having a token for one bank (itself) and not the 
inconvenience that a token per bank places on a customer. Also, in a 
consumer scenario as opposed to a work scenario, the consumer wants to be able to 
log into his/her bank account regardless of physical location and PC/laptop.


In a study I did last year with middle-age, well-educated adults, the average number of bank and brokerage accounts accessed online was 6. 
One person had 20. No one wanted to carry around multiple hardware tokens 
in case they need to access an account from someplace other than home. No one wanted a cup 
full of hardware tokens next to their PC at home. For banks that require 
certain customers (such as those with an account below some minimum 
balance) pay for their token, no one wants to pay $15-$25 every couple years for a single token when they don't 
understand what it provides over a static password.
Without commenting on security of software implementations, software-based 
tokens offered for browsers and cell phones get rid of the hardware issue 
for users. Broswer-based tokens don't solve the problem of users wanting 
to log in from anywhere. Tokens on cell phones are more promising in 
terms of human factors if the user is not required to install a different application for every bank account and has a standard
interface to all the tokens, and has a way of migrating tokens to a new 
cell phone. However, what I've seen so far are vendors charging a small
licensing fee per token per a specific number of years. Thus the bank 
either needs to cover the cost or a user pays a fee for every token every 
couple of years. To deploy tokens, the bank will need to either install 
and start the tokens on the cell phone for the customer or expect a large 
percentage of calls to a help desk. An alternative of having an OTP 
delivered to the user's cell phone on an as needed basis and 

Re: The password-reset paradox

2009-02-23 Thread Matt Crawford


On Feb 21, 2009, at 10:26 PM, Charlie Kaufman wrote:

Assuming that's true, OTP tokens add costs by introducing new  
failure modes (e.g.,

I lost it, I ran it through the washing machine, etc.)


Or even more surprising hazards.

http://home.fnal.gov/~crawdad/CryptoCard.jpg

The token on the left in that picture was issued in 2003 by postal  
mail to a Sloane Digital Sky Survey collaborator at the US Naval  
Observatory. All incoming packages were subjected to high doses of  
electron and x-ray radiation, as it is also the residence of the Vice  
President.


On the right is the normal appearance of the token and its holder.

-
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

2009-02-23 Thread 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


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

2009-02-23 Thread silky
On Sun, Feb 22, 2009 at 6:33 AM, Ed Gerck edge...@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, 

Re: The password-reset paradox

2009-02-20 Thread Jerry Leichter

On Feb 19, 2009, at 8:36 AM, Peter Gutmann wrote:

There are a variety of password cost-estimation surveys floating  
around that
put the cost of password resets at $100-200 per user per year,  
depending on

which survey you use (Gartner says so, it must be true).


You can get OTP tokens as little as $5.  Barely anyone uses them.

Can anyone explain why, if the cost of password resets is so high,  
banks and
the like don't want to spend $5 (plus one-off background  
infrastructure costs

and whatnot) on a token like this?

(My guess is that the password-reset cost estimates are coming from  
the same
place as software and music piracy figures, but I'd still be  
interested in any

information anyone can provide).
I suspect some very biased analysis.  For example, people who really  
need their passwords reset regularly will probably lose their tokens  
just as regularly.  The cost of replacing one of those is high - not  
for the token itself, but for the administrative costs, which *must*  
be higher than for a password reset since they include all the work in  
a password reset (properly authenticating user/identifying account  
probably contribute the largest costs), plus all the costs of  
physically obtaining, registering, and distributing a replacement  
token - plus any implied costs due to the delays needed to physically  
deliver the token versus the potential for an instantaneous reset.


I suppose the $100-$200 estimate might make sense for an organization  
that actually does password resets in a secure, carefully managed  
fashion.  Frankly ... I, personally, have never seen such an  
organization.  Password resets these days are mainly automated, with  
authentication and identification based on very weak secondary  
security questions.  Even organizations you'd expect to be secure  
authenticate password reset requests based entirely on public  
information (e.g., if you know the name and badge number of an  
employee and the right help desk to call, you can get the password  
reset).  New passwords are typically delivered by unsecured email.   
All too many organizations reset to a fixed, known value.


It's quite true that organizations have found the costs of password  
resets to be too high.  What they've generally done is saved money on  
the reset process itself, pushing the cost out into whatever budgets  
will get hit as by the resulting security breaches.

-- Jerry



Peter.

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


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


Re: The password-reset paradox

2009-02-20 Thread Steven M. Bellovin
On Fri, 20 Feb 2009 02:36:17 +1300
pgut...@cs.auckland.ac.nz (Peter Gutmann) wrote:

 There are a variety of password cost-estimation surveys floating
 around that put the cost of password resets at $100-200 per user per
 year, depending on which survey you use (Gartner says so, it must be
 true).
 
 You can get OTP tokens as little as $5.  Barely anyone uses them.
 
 Can anyone explain why, if the cost of password resets is so high,
 banks and the like don't want to spend $5 (plus one-off background
 infrastructure costs and whatnot) on a token like this?
 
Because then you need PIN resets, lost token handling, and my token
doesn't work and I'm on a trip and my boss will kill me if I don't get
this done resets.  I've personally had to deal with two of the three,
and it was just as insecure as password resets


--Steve Bellovin, http://www.cs.columbia.edu/~smb

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


Re: The password-reset paradox

2009-02-20 Thread James Chacon


On Feb 19, 2009, at 7:36 AM, Peter Gutmann wrote:

There are a variety of password cost-estimation surveys floating  
around that
put the cost of password resets at $100-200 per user per year,  
depending on

which survey you use (Gartner says so, it must be true).

You can get OTP tokens as little as $5.  Barely anyone uses them.

Can anyone explain why, if the cost of password resets is so high,  
banks and
the like don't want to spend $5 (plus one-off background  
infrastructure costs

and whatnot) on a token like this?

(My guess is that the password-reset cost estimates are coming from  
the same
place as software and music piracy figures, but I'd still be  
interested in any

information anyone can provide).


I'd almost guarentee that's the reason. Buying OTP's comes out of  
direct funds right there on the spot whereas it costs us XXX to reset  
passwords is a nebulous stat that can likely be written however  
someone wants to read it.


Plus given most OTP's have short expirations to generate rolling  
revenue for the provider (ala SecuriID) it's not a simple cost to  
start down this path for a lot of businesses.


James

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