Re: Hashing algorithm needed
On Tue, Sep 14, 2010 at 13:29, Ian G i...@systemics.com wrote: On 14/09/10 2:26 PM, Marsh Ray wrote: On 09/13/2010 07:24 PM, Ian G wrote: 1. In your initial account creation / login, trigger a creation of a client certificate in the browser. There may be a way to get a browser to generate a cert or CSR, but I don't know it. But you can simply generate it at the server side. Just to be frank here, I'm also not sure what the implementation details are here. I somewhat avoided implementation until it becomes useful. The French government has been doing this using Java applets for the last decade (at least). This allows the happy French tax payers to generate their own CSRs and have them automatically signed by the tax administration in one swoop. This might be the only large scale deployment of client-side certificates in browsers I know of. (And I'd certainly like to hear about others.) -- Erwan Legrand - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Effects of OpenID or similar standards
On Mon, Nov 9, 2009 at 3:17 AM, Jerry Leichter leich...@lrw.com wrote: On Nov 6, 2009, at 4:19 PM, Erwan Legrand wrote: Let's face it: most people use the same password for every single Web site they connect to. Starting from here, I can't see OpenID becoming much of a problem. While I'm sure this is widely believed, I wonder if it's really true. Is anyone aware of research on the subject? Not exactly, although I sure there was some research done on the number of passwords people had to remember nowadays and how many they were able to remember. Even if it's true to a large degree, the details may matter. People may routinely use the same password for all their low value accounts, but come up with something better for their bank or other high value accounts. For what it's worth (i.e. not much), in my own experience people who actually do this qualify as nerds. Paradoxically, the *lack* of a standard for password quality may help here. High-value sites often place some requirement on the nature of passwords, but the requirements vary: Letters and digits only; letters plus digits plus at least one special character - with the set of allowed special characters varying in pretty arbitrary ways; etc. It's tough to come up with a single password that will be broadly accepted at such sites, and anything someone does come up with will be so inconvenient that it's unlikely to be something they'll want to use at low-value, any-password-accepted, sites. Select any five letters long dictionary word of your choice, append 0 or 1 and you have a password one can reuse for almost all her accounts. I've seen real people do just that. A widely-used single sign on system is certainly great from a usability point of view, and does actually have some positive effects on security: You no longer need to hand your actual password to sites programmed by someone whose background in security is minimal. The downside is that you now have a single super-high-value password, the compromise of which would be very painful. Agreed. This word, usability, is the key here. I used to be very sceptical (to say the least) with regard to SSO systems. Then about everyone around gained access to the Internet and the World Wide Web. Then about every new Web site out there started requiring users to create accounts. The likes of OpenID have their use in today's world. Looking to this problem from another perspective, I'm yet to see any sensitive Web site (such as a banking site) relying on OpenID for authentication. But I must admit I haven't looked for one. Yet perhaps someone on this list knows better? -- 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)
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
