Re: Hashing algorithm needed
On 15/09/2010 00:26, Nicolas Williams wrote: On Tue, Sep 14, 2010 at 03:16:18PM -0500, Marsh Ray wrote: How do you deliver Javascript to the browser securely in the first place? HTTP? I'll note that Ben's proposal is in the same category as mine (which was, to remind you, implement SCRAM in JavaScript and use that, with channel binding using tls-server-end-point CB type). It's in the same category because it has the same flaw, which I'd pointed out earlier: if the JS is delivered by normal means (i.e., by the server), then the script can't be used to authenticate the server. That's one of the reasons I said it was only good for experimenation. -- 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: Hashing algorithm needed
On 14/09/2010 21:16, Marsh Ray wrote: On 09/14/2010 09:13 AM, Ben Laurie wrote: Demo here: https://webid.digitalbazaar.com/manage/ This Connection is Untrusted So? It's a demo. -- 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: Hashing algorithm needed
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. Marsh's notes +1 from me. iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Hashing algorithm needed
On 09/13/2010 07:24 PM, Ian G wrote: On 11/09/10 6:45 PM, f...@mail.dnttm.ro wrote: Essentially, the highest risk we have to tackle is the database. Somebody having access to the database, and by this to the authentication hashes against which login requests are verified, should not be able to authenticate as another user. Which means, I need an algorithm which should allow the generation of different hashes for which it can be verified that they stem from the same login info, without being able to infer this login info from a hash. This algorithm is the problem I haven't solved yet. Other than that, I see no way of protecting against a dictionary attack from somebody having direct access to the database. flj, I appreciate your systematic and conscientious engineering approach. But I haven't heard anything in your requirements that make it sound like a journey outside of well established protocols is justified here. There are a few experienced people around here who could probably design come up with a new custom scheme and get it right the first time. But the history of most (even professionally-designed) new security protocols usually includes the later discovery of serious weaknesses. I don't recall the full discussion, but what you described is generally handled by public key cryptography, and it is built into HTTPS. Here's my suggestion: +1 I have a similar setup going in a reasonably big production environment and it's working great. 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. 1.b. record the client cert as the authenticator in the database. 2. when someone connects, the application examines the cert used, and confirms the account indicated. Note that you can get the full client cert presented by the web server and compare it (or a sufficiently long :-) hash of it) directly with what you have in the database. There may be no need to check signatures and so on if your server-side is centralized. If an unknown cert, transfer to a landing page. 2.b note that there is no login per se, each request can as easily check the client cert listed by Apache. Most apps will want to ask the human to authenticate explicitly from time to time for one reason or another. 3. you just need some way to roll-over keys from time to time. Left for later. Make sure you have at least some way of revoking and renewing a client certs, even if it's a code update. Just on the outside chance that, say, the keys got generated by Debian Etch's RNG or something. 3.b There are some other bugs, but if the approximate scheme works... Three more recommendations: Don't put anything sensitive in the X509 cert. Just a minimal userid or even random junk. You're just looking it up in a database. Disable TLS renegotiation unless you control both the clients and the servers and can ensure they're all patched for CVE 2009-3555. Don't expect to be able to use renegotiation to hide the contents public cert, that never worked against an active attacker anyway. Use a separate dns name for the https site that accepts client certs from the one that does not. The reason is that the client cert will have to be requested on the initial handshake. Requesting a client cert will cause many browsers to pop-up a dialog. Not something you want on your secure home page. Again this is a good scheme, it's the way SSL/TLS has been intended to be used for authenticated clients since SSLv3. It even offers additional protections from the server's perspective, too: the server is no longer forced to transitively trust the union of all trusted root CA certs of all allowed clients in order to prove the non-existence of a man-in-the-middle. - Marsh - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Hashing algorithm needed
On 14/09/2010 12:29, Ian G 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. FWIW, you can get browsers to generate CSRs and eat the resulting certs. The actual UIs vary from appalling to terrible. Of some interest to me is the approach I saw recently (confusingly named WebID) of a pure Javascript implementation (yes, TLS in JS, apparently), allowing UI to be completely controlled by the issuer. Ultimately this approach seems too risky for real use, but it could be used to prototype UI, perhaps finally leading to something usable in browsers. Slide deck here: http://payswarm.com/slides/webid/#(1) (note, videos use flash, I think, so probably won't work for anyone with their eye on the ball). Demo here: https://webid.digitalbazaar.com/manage/ 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: 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: Hashing algorithm needed
On 09/14/2010 09:13 AM, Ben Laurie wrote: On 14/09/2010 12:29, Ian G 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. FWIW, you can get browsers to generate CSRs and eat the resulting certs. The actual UIs vary from appalling to terrible. Of some interest to me is the approach I saw recently (confusingly named WebID) of a pure Javascript implementation (yes, TLS in JS, apparently), allowing UI to be completely controlled by the issuer. First, let's hear it for out of the box thinking. *yay* Now, a few questions about this approach: How do you deliver Javascript to the browser securely in the first place? HTTP? How do you get the user to save his private key file? Copy and paste? How does the proper Javascript later access the user's private key securely? How do they securely wipe memory in Javascript? How do they resist timing attacks? In practice, an attacker can probably get the browser to repeatedly sign random stuff with the client cert even while he's running his own script in the same process. Ultimately this approach seems too risky for real use, but it could be used to prototype UI, perhaps finally leading to something usable in browsers. A sad indictment of browser vendor user interface priorities. Slide deck here: http://payswarm.com/slides/webid/#(1) (note, videos use flash, I think, so probably won't work for anyone with their eye on the ball). Demo here: https://webid.digitalbazaar.com/manage/ This Connection is Untrusted - Marsh - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Hashing algorithm needed
On Tue, Sep 14, 2010 at 03:16:18PM -0500, Marsh Ray wrote: On 09/14/2010 09:13 AM, Ben Laurie wrote: Of some interest to me is the approach I saw recently (confusingly named WebID) of a pure Javascript implementation (yes, TLS in JS, apparently), allowing UI to be completely controlled by the issuer. First, let's hear it for out of the box thinking. *yay* Now, a few questions about this approach: How do you deliver Javascript to the browser securely in the first place? HTTP? I'll note that Ben's proposal is in the same category as mine (which was, to remind you, implement SCRAM in JavaScript and use that, with channel binding using tls-server-end-point CB type). It's in the same category because it has the same flaw, which I'd pointed out earlier: if the JS is delivered by normal means (i.e., by the server), then the script can't be used to authenticate the server. And if you've authenticated the server vi HTTPS (TLS) then you might as well just POST the usernamepassword to the server, since the server could just as well send you a script that does just that. This approach works only if you deliver the script in some out-of-band manner, such as via a browser plug-in/add-on (hopefully signed [by a trustworthy trusted third party]). Nico -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Hashing algorithm needed
On 2010-09-09 6:35 AM, Ben Laurie wrote: What I do in Nigori for this is use DSA. Your private key, x, is the hash of the login info. The server has g^x, from which it cannot recover x, Except, of course, by dictionary attack, hence g^x, being low entropy, is treated as a shared secret. and the client does DSA using x. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Hashing algorithm needed
On 9 September 2010 10:08, James A. Donald jam...@echeque.com wrote: On 2010-09-09 6:35 AM, Ben Laurie wrote: What I do in Nigori for this is use DSA. Your private key, x, is the hash of the login info. The server has g^x, from which it cannot recover x, Except, of course, by dictionary attack, hence g^x, being low entropy, is treated as a shared secret. Indeed, if it is low entropy (I don't think you can assume it is, though I'll readily agree it is likely to be), then it is subject to a dictionary attack. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Hashing algorithm needed
On 8 September 2010 16:45, f...@mail.dnttm.ro wrote: Hi. Just subscribed to this list for posting a specific question. I hope the question I'll ask is in place here. We do a web app with an Ajax-based client. Anybody can download the client and open the app, only, the first thing the app does is ask for login. The login doesn't happen using form submission, nor does it happen via a known, standard http mechanism. What we do is ask the user for some login information, build a hash out of it, then send it to the server and have it verified. If it checks out, a session ID is generated and returned to the client. Afterwards, only requests accompanied by this session ID are answered by the server. Right now, the hash sent by the browser to the server is actually not a hash, but the unhashed login info. This has to be changed, of course. What we need is a hashing algorithm that: - should not generate the same hash every time - i.e. should includen something random elements - should require little code to generate - should allow verification of whether two hashes stem from the same login data, without having access to the actual login data We need to implement the hashing algorithm in Javascript and the verification algorithm in Java, and it needs to execute reasonably fast, that's why it has to require little code. None of us is really into cryptography, so the best thing we could think of was asking for advice from people who grok the domain. Well, you can't always get what you want. What I do in Nigori for this is use DSA. Your private key, x, is the hash of the login info. The server has g^x, from which it cannot recover x, and the client does DSA using x. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Hashing algorithm needed
f...@mail.dnttm.ro writes: The idea is the following: we don't want to secure the connection, Why not? Using HTTPS is easier than making up some half-baked scheme that won't work anyway. -- http://noncombatant.org/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
