Re: how to properly secure non-ssl logins (php + ajax)
Rene Veerman rene7...@gmail.com 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: 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
Shamir secret sharing and information theoretic security
Begin forwarded message: From: Sarad AV jtrjtrjtr2...@yahoo.com 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ć krs...@solarsail.hcs.harvard.edu | 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
