Re: how to properly secure non-ssl logins (php + ajax)
I think you are close, but are probably doing way too much work. First let's define a function HMAC_MD. HMAC is defined in RFC2104 and represents the current best current practice for using a hash to "sign" a data value. It takes: result = hmac_md(key, value) You can use hmac with MD5, SHA1, SHA256... whatever. You will likely find libraries that already implement this in various languages. Below "SHA" means SHA1, SHA256, your choice. We'll assume each user has a password which is stored on the server. For a bit of extra security I would have the server store it as a SHA hash of the actual password.) For authentication you do a challenge response. Server Client nonce > <===username, hmac_md(sha(password), nonce) The trick is to ensure that the nonce is not re-used. There are several ways to do this. One way is to store it in a table: crate table nonces ( nonce varchar(128), # Probably enough ts timestamp, used Boolean ) When the server gets the reply it looks up the user's "sha(password)" which is stored in the user account table. It then verifies that the nonce value is in the nonces table and that used is False. It then verifies that the timestamp is "fresh" (you can decide this). Upon use, the nonces table is updated to set used to True. A second login attempt would require a separate nonce. Once a nonce is no longer "fresh" it can be purged from the nonces table (so you don't have to store these forever). Obviously the server computes hmac_md(sha(password), nonce) and verifies it is the value received from the client. There are a copy of gotchas here. The biggest is how you initially setup the shared secret (aka the password). Without public key operations there is no good way to create accounts (unless this is done administratively, effectively "off line"). SSL of course can solve this (but you don't want to use SSL). You can also attempt to implement RSA in javascript and PHP (well, I'm sure routines exist for PHP). You can then download a public key in your javascript code for account registration. The user's browser can then compute sha(password) and send it encrypted in the public key (or encrypted in a data encrypting key which is encrypted in a public key). I don't know how amenable javascript is to doing RSA. Years ago (when computers were much slower) I wrote a Java Applet that did RSA in the applet for account registration at MIT. It wasn't very fast, but it was good enough for a one-time registration applet. Heh heh, we still use it today! Now of course I really cannot end this message without throwing in the obvious caution that without SSL your authentication is pretty weak. Even though you have not exposed the user's password, once logged in PHP uses a session cookie. This cookie, although of limited lifetime, is now available to the eavesdropper to steak and abuse. I'm not even sure that PHP ensures that a cookie is coming from the same IP address it was issued to (and in fact you cannot usually implement such a restriction because some environments [aka large NATs and other crud] can result in a legitimate user's traffic coming from different IP addresses even within the same web session!). And of course all of your data is also exposed, both for viewing and for modification in flight. Last I checked, SSL certificates could be had for the $20/year range, so I don't see how that is cost prohibitive! Modern hardware also does SSL pretty darn fast. You really have to have a very high traffic site before it becomes a problem. There actually aren't that many high traffic sites out there. Most organizations may think their sites are high traffic, but they rarely are. -Jeff - "Rene Veerman" wrote: > Hi. > > Recently, on both the jQuery(.com) and PHP mailinglists, a question > has arisen on how to properly secure a login form for a non-ssl > web-application. But the replies have been "get ssl".. :( > > I disagree, and think that with a proper layout of authentication > architecture, one can really secure a login system without having the > administrative overhead of installing SSL everywhere, and the monetary > cost for a SSL certificate for each domain. -- Jeffrey I. Schiller MIT Network Manager Information Services and Technology Massachusetts Institute of Technology 77 Massachusetts Avenue Room W92-190 Cambridge, MA 02139-4307 617.253.0161 - Voice j...@mit.edu - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: how to properly secure non-ssl logins (php + ajax)
Rene Veerman writes: >Recently, on both the jQuery(.com) and PHP mailinglists, a question has >arisen on how to properly secure a login form for a non-ssl web-application. >But the replies have been "get ssl".. :( > >I disagree, and think that with a proper layout of authentication >architecture, one can really secure a login system without having the >administrative overhead of installing SSL everywhere, and the monetary cost >for a SSL certificate for each domain. > >[...] > >I'm halfway (or more?) there, i think. For my own CMS, i have taken the >following approach, which i'd like to hear your improvements on: Go out and get a copy of "Network Security" by Kaufman, Perlman and Speciner, this has an entire chapter that discusses this issue, including the pros and cons of different approaches and all the ways you can get it wrong (oh, and it's written for a non-security-geek audience). I think any discussion here will end up being mostly a rehash of bits of the chapter, their version goes into much more detail and has diagrams to boot. Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: how to properly secure non-ssl logins (php + ajax)
- Original Message - From: "Rene Veerman" Sent: Sunday, February 15, 2009 4:30 AM Subject: how to properly secure non-ssl logins (php + ajax) I'm going to edit this, since I assume most of the code is completely irrelevant proposal: database stores Hash(password | salt) on server challenge = Hash(random bits), challenge specifically does NOT change every time user_hash = Hash( Hash( password | salt) | challenge) There are so many ways to attack this I'm not sure where to begin: 1) Man-in-the-middle - user <-> Jerk <-> server, Jerk can easily highjack the session 2) Fake server sends out known predictable challenges, user is now an oracle 3) hack the real server, retrieve Hash(password| salt) hacker can now log in to server FASTER than user 4) hash attacks, you mention specifically that MD5 is available as a hash for this, DONT EVER USE MD5 the list continues Now how to (mostly) fix it: g, p, q are DSA parameters of sufficient size Hash is a secure Hash, SHA256 will work, but SHA512 will work faster database stores g^Hash(password | salt) mod p, call it gUser Challenge = time | random bits, make it 256 bits, using time reduces the number of random bits used gChallenge = g^Challenge mod p Signed-gChallenge = cryptographically signed gChallenge | time, this does not take a certificate, just a trusted known signature key Client receives Signed-gChallenge and salt Client verifies signature including time on Signed-gChallenge and extracts gChallenge Client computes Y = gChallenge^Hash(password | salt) mod p Server computes Y = gUser^Challenge mod p If Y=Y client knows the password. For proof of security, this is signed-half ephemeral Diffie-Hellman key agreement with reveal. 1) This does not fix the MITM attack, only an encrypted tunnel can do that, so use SSL 2) Fake server only repeat a challenge created by the real server because of the signature, but the public key of the signing key needs to be verifiable, this is where certificates come in 3) Retrieveing gUser from the database is exactly identical to retrieving a Diffie-Hellman public key, no risk, database can be public 4) ALWAYS REMEMBER TO NEVER USE MD5 Also with SSL you don't need to have a paid for certificate, have a look at https://financialcryptography.com/ for an example. Joe - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Crypto Craft Knowledge
Stephan Neuhaus wrote: >> Yes, there's a need for a "crypto practices FAQ" to which one can refer. > > I disagree because you cannot force developers to read (and understand) > these FAQs. Instead, there is a need for APIs that are difficult to use > in an insecure way. For example, Peter Gutmann's cryptlib makes it > intentionally hard to get at private key material because of precisely > this issue. Also, I believe, cryptlib does not allow RSA in anything > but ECB mode, because doing so means the developer is seriously on the > wrong track here. This is a good point, and it reminds me of this presentation from Rusty Russell on "levels" of Linux kernel interfaces. See http://ozlabs.org/~rusty/ols-2003-keynote/img39.html and following. The main issue I see is how do you force the developer to adopt your library and corresponding API? A secondary issue is what do you do if there isn't a suitable library and API yet available? In cases where you can't (yet) provide a simple "use cryptlib" response, a crypto practices FAQ would be helpful for pointing out common problems and explaining them well. I've started a wiki in case anyone wants to hack on such a FAQ: http://www.cryptohygiene.org/ -David Molnar signature.asc Description: OpenPGP digital signature
Re: how to properly secure non-ssl logins (php + ajax)
On Sun, 15 Feb 2009, Rene Veerman wrote: > Recently, on both the jQuery(.com) and PHP mailinglists, a question has > arisen on how to properly secure a login form for a non-ssl web-application. > But the replies have been "get ssl".. :( Unfortunately, they are right: get SSL. > If you have a completely alternative way of securing a non-ssl login > form, i'd like to hear about it too. I suspect what you have coded is a reinvention of RFC 2617 (implemented, e.g., by mod_auth_digest in Apache). Depending on your threat model, this can be all you need (plaintext password is not transmitted, but this does not prevent local dictionary attacks), but any such scheme fails miserable against active attacks. -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Crypto Craft Knowledge
Stephan Neuhaus wrote: > Many mistakes in crypto coding come from the fact that API developers > have so far very successfully shifted the burden of secure usage to the > application developer, the API user. But I believe this hasn't worked > and needs to be changed. I totally agree, and this is the thinking behind the Keyczar project (http://www.keyczar.org/): "Cryptography is easy to get wrong. Developers can choose improper cipher modes, use obsolete algorithms, compose primitives in an unsafe manner, or fail to anticipate the need for key rotation. Keyczar abstracts some of these details by choosing safe defaults, automatically tagging outputs with key version information, and providing a simple programming interface. Keyczar is designed to be open, extensible, and cross-platform compatible. It is not intended to replace existing cryptographic libraries like OpenSSL, PyCrypto, or the Java JCE, and in fact is built on these libraries." Cheers, Ben. -- 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: Crypto Craft Knowledge
On Feb 14, 2009, at 12:54 PM, David Molnar wrote: Ben Laurie wrote: [snip discussion of bad crypto implementation practices] Because he is steeped in the craft knowledge around crypto. But most developers aren't. Most developers don't even have the right mindset for secure coding, let alone correct cryptographic coding. So, why on Earth do we expect them to follow our unwritten rules, many of which are far from obvious even if you understand the crypto? Yes, there's a need for a "crypto practices FAQ" to which one can refer. In addition to individual education, it'd be helpful to have something when pointing out common mistakes. [snip specific discussion] I find this conversation off the point. Consider other trades like woodworking. There is no FAQ that can be created that would be applicable to building a picture frame, dining room table or a covered bridge. A FAQ for creating a picture frame would be possible, but this is not the FAQ that is being discussed. Crypto protocol failures are not trivial. The recent CBC attack on SSH shows that this is the case. http://secunia.com/Advisories/32760/ What FAQ would prescribe how not to make this mistake? There are PhD programs related to this subject. I would argue (and actually dovetailing with another thread) that, if one creates a FAQ, that it point to well vetted implementations of information delivery protocols like SSL and SSH, and that any FAQ regarding the use of crypto libraries be that this is dangerous and should only be attempted with proper oversight and/or training. Crypto protocols are not trivial, and suggesting a FAQ would be able to take the uninitiated to secure coding is more dangerous than good. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Contradictory opinion on KMIP
Recently, there was a posting on this forum on the Key Management Interoperability Protocol (KMIP) Technical Committee charter, proposed by a group of storage vendors (RSA, IBM, HP, et al) at OASIS. (Unfortunately, I deleted the posting, so I cannot refer to it directly, but here's a link to the original posting): http://www.mail-archive.com/cryptography@metzdowd.com/msg10274.html I thought it might be useful to inform readers of this forum that a contradictory opinion has been submitted to the OASIS Charter list (by this author) at: http://lists.oasis-open.org/archives/oasis-charter-discuss/200902/msg1.html It is fair to warn readers that the contradictory opinion is not a technical discussion of cryptography, but more a political fallout in the KM space. If KM standards are of interest to readers, they may find the comments at the OASIS link germane. Arshad Noor StrongAuth, Inc. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: how to properly secure non-ssl logins (php + ajax)
[Moderator's note: top posting is not considered good form. --Perry]
Hi Rene,
I suspect from reading this quickly that you may not be a cryptographer. I'd
highly suggest that you borrow one for a bit before you go ahead with this.
I'm having a bit of trouble reading exactly what you want to do, but I am
fairly sure that this isn't as secure as you'd like. (Heck, I can probably
help you out with this, but not today because I'm swamped.)
Thanks,
Lea
On Sun, Feb 15, 2009 at 4:30 AM, Rene Veerman wrote:
> Hi.
>
> Recently, on both the jQuery(.com) and PHP mailinglists, a question has
> arisen on how to properly secure a login form for a non-ssl web-application.
> But the replies have been "get ssl".. :(
>
> I disagree, and think that with a proper layout of authentication
> architecture, one can really secure a login system without having the
> administrative overhead of installing SSL everywhere, and the monetary cost
> for a SSL certificate for each domain.
>
> I wish to code such a solution into a really-free library (so probably LGPL
> or GPL + MIT) over the next 2 to 5 months.
> This library would be a complete SQL, PHP & javascript package (jQuery
> "plugged in"), targetted for the novice programmer.
>
> I'm halfway (or more?) there, i think.
> For my own CMS, i have taken the following approach, which i'd like to hear
> your improvements on:
>
> (For onewayHash() i have MD5 and SHA256 implementations in both JS and
> PHP..)
>
> SQL:
>
> create table users (
> user_id integer,
> user_login_name varchar(250),
> user_login_hash varchar(250),
> user_password_hash varchar(250),
> other fields
> primary key (user_id)
> );
>
> create table preferences (
> pref_system_hash varchar(250)
>
> );
>
> PHP (pseudo-code) , on system installation:
> preferences.pref_system_hash = onewayHash ( randomStringLength(100) );
>
> PHP , on user-create:
>
> users[user_id].user_login_hash = onewayHash(user_login_name +
> preferences.pref_system_hash);
> users[user_id].user_password_hash = onewayHash ("someGooodPasswordNot" +
> preferences.pref_system_hash);
>
> PHP, on request of a login form:
>
> challenge = makeNewChallenge ();
> //checks since when [browser IP] has last received a new challenge,
> if < threshold : make a new challenge. else return old challenge.
> //a challenge is a random string (+ special chars) pushed through the
> onewayHash function.
>
> html = '
>
> value="preferences.pref_system_hash">
>
>
>
>
>
>
> ';
> sendHTMLtoBrowser (html);
>
> Javascript: on page with login form:
>
> jQuery('#loginForm').submit (function () {
> var sh = jQuery('#sh')[0]; //same for ch, plain_user, plain_pass,
> all the inputs in the html form.
>
>
> user_hash = onewayHash ( onewayHash ( plain_user.value + sh.value )
> + challenge );
> //same for pass_hash basically
>
> plain_user.value = ''; //clear out the plain text fields so they
> dont get transmitted (same for plain_pass ofcourse)
>
> jQuery.ajax ( /* submit login form through POST, handle results */
> )
> }
>
>
> PHP, on receiving the login form data:
>
> // walk through all the records in users table, for each, calculate:
> user_hash = onewayHash ( users[user_id].user_login_hash + challenge
> );
> pass_hash = onewayHash ( users[user_id].user_password_hash +
> challenge );
>
> // if they match what was sent, then it's the user we're looking for
> with the right password, so their $_SESSION['authenticated_user'] = updated.
>
>
>
>
> If you have a completely alternative way of securing a non-ssl login form,
> i'd like to hear about it too.
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Shamir secret sharing and information theoretic security
Begin forwarded message: From: Sarad AV Date: February 17, 2009 9:51:09 AM EST To: cypherpu...@al-qaeda.net Subject: Shamir secret sharing and information theoretic security hi, I was going through the wikipedia example of shamir secret sharing which says it is information theoretically secure. http://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing In the example in that url, they have a polynomial f(x) = 1234 + 166.x + 94.x^2 they construct 6 points from the polynomial (1,1494);(2,1942);(3,2578);(4,3402);(5,4414);(6,5615) the secret here is S=1234. The threshold k=3 and the number of participants n=6. If say, first two users collude then 1494 = S + c1 .1 + c2.1 1942 = S + c1 .2 + c2.2 clearly, one can start making inferences about the sizes of the unknown co-efficients c1 and c2 and S. However, it is said in the URL above that Shamir secret is information theoretically secure in the url below they say http://en.wikipedia.org/wiki/Information_theoretic_security "Secret sharing schemes such as Shamir's are information theoretically secure (and in fact perfectly secure) in that less than the requisite number of shares of the secret provide no information about the secret." how can that be true? we already are able to make inferences. Moreover say that, we have 3 planes intersecting at a single point in euclidean space, where each plane is a secret share(Blakely's scheme). With 2 plane equations, we cannot find the point of intersection but we can certainly narrow down to the line where the planes intersect. There is information loss about the secret. from this it appears that Shamir's secret sharing scheme leaks information from its shares but why is it then considered information theoretically secure? They do appear to leak information as similar to k-threshold schemes using chinese remainder theorem. what am i missing? Thanks, Sarad. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: how to properly secure non-ssl logins (php + ajax)
Hi, > Recently, on both the jQuery(.com) and PHP mailinglists, a question has > arisen on how to properly secure a login form for a non-ssl web-application. > But the replies have been "get ssl".. :( What makes you think these are ill-advised? > I disagree, and think that with a proper layout of authentication > architecture, one can really secure a login system without having the > administrative overhead of installing SSL everywhere, and the monetary cost > for a SSL certificate for each domain. Well, it depends on how much security is enough for you. If the threats you are concerned with encompass the threats mitigated by SSL/TLS, then you should definitely use TLS. You could arguably use Kerberos, SSH or IPSEC to achieve the same level of security, but that would not be handy, since SSL/TLS is what is bundled in web servers and browsers. Oh, and you don't necessarily have to buy a certificate to Verisign to use SSL! The only thing your scheme seems to achieve is protect your password against eavesdroppers. But then, an eavesdropper could reuse your cookie to hijack your session. Your protocol does not mitigate such threats as session hijacking, MITM, phishing, HTTP cache poisoning and the list goes on. And whatever the shortcomings of TLS might be, it does mitigate these threats. Now, if you threat model goes along the lines of : * The only asset I want to protect is my password (because I use the same password to access critical data hosted on other services!) * I don't care whether my session is compromised. * I don't care whether my data is captured by an eavesdropper. Then your scheme might indeed be what you need. I did not give it more than a quick look though. And I would suggest you reconsider in the first place the reasons that made you reuse such a precious password. I hope this last paragraph makes sense and you will forgive my use of sarcasm. -- Erwan Legrand Simplicity is prerequisite for reliability. -- E. W. Dijkstra - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: how to properly secure non-ssl logins (php + ajax)
On Feb 15, 2009, at 7:30 AM, Rene Veerman wrote: Recently, on both the jQuery(.com) and PHP mailinglists, a question has arisen on how to properly secure a login form for a non-ssl web- application. What's the threat model? users[user_id].user_login_hash = onewayHash(user_login_name + preferences.pref_system_hash); That you're hashing the username suggests you're worried about eavesdroppers identifying the user at login time. But without SSL, it'll almost certainly be trivial for an eavesdropper to identify the user _after_ they login. What's the threat model? //checks since when [browser IP] has last received a new challenge, if < threshold : make a new challenge. else return old challenge. It is incorrect to rely on a bijection between IPs and users. "preferences.pref_system_hash"> What you're calling a system hash is usually referred to as salt. // walk through all the records in users table, for each, calculate: This is a completely broken approach, and prohibitive for applications with more than a handful of users. I suggest you start by trying to write down a clear, brief and coherent threat model. Once that's done, you can solicit feedback until you're satisfied with the definition of what you're trying to build. Once you can focus on implementation, I suggest looking at things like bcrypt, PBKDF2, and SRP as background reading. Cheers, -- Ivan Krstić | http://radian.org - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
fyi: Researchers Hack Biometric Faces
apropos to the biometrics essay in the Jan 2009 crypto-gram: Researchers Hack Biometric Faces slashdot.org/palm/18/09/02/17/216216_1.shtml from the face-off dept. posted by kdawson on 2009-02-18 01:35:00 yahoi sends in news from a week or so back: "Vietnamese researchers have cracked the facial recognition technology [1] used for authentication in Lenovo, Asus, and Toshiba laptops in lieu of the standard logon/password. The researchers were able to easily bypass the biometric authentication system built into the laptops by using photos of an authorized user, as well as by presenting multiple phony facial images in brute-force attacks. One of the researchers will demonstrate the hack at Black Hat DC this week. He says the laptop makers should remove the facial biometrics feature from their products because the vulnerability of this technology can't be fixed." [1] http://www.darkreading.com/security/vulnerabilities/showArticle.jhtml;jsess ionid=1TT4XOGIHD2DCQSNDLRSKHSCJUNN2JVN?articleID=213901113 --- end - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
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
stripping https from pages
http://www.theregister.co.uk/2009/02/19/ssl_busting_demo/ -- we've talked about this attack for quite a while; someone has now implemented it. --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Shamir secret sharing and information theoretic security
On Tue, 17 Feb 2009, R.A. Hettinga wrote: hi, I was going through the wikipedia example of shamir secret sharing which says it is information theoretically secure. http://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing ... The scheme is defined over a finite field *not* over the integers. When Shamir's scheme is run over a finite field, it is information theoretically secure. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: The password-reset paradox
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
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
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
