Dan, Upon examining SRP, you are correct. SRP solves the same problem in a superior manner. lulz
On Wed, Sep 8, 2010 at 2:52 PM, Dan Kaminsky <[email protected]> wrote: > Ah, a new password-authenticated DH. At first glance, this is similar to > SRP (http://srp.stanford.edu/), but the server stores a plaintext password. > > Initial thinking -- I'm not convinced that an offline brute force attack > won't work -- the nonce may break rainbow tabling, but it is transmitted via > unauthenticated DH (meaning, an attacker can see it with a mildly active > attack). > > Thus the questions: > > a) Can an attacker, able to see multiple instances of a client's g2b, g3b, > Pb and Qb, offline-brute-force them to verify the plaintext password? > b) Can an attacker, able to see multiple instances of a server's Pa, Qa and > Ra, offline-brute-force them to verify the plaintext password of an > arbitrary user? > > Neither is possible in the present form-based HTTPS system, or SRP. > > I'm not saying the above attacks will work. There are a decent amount of > randomizers in here (both r and s are randomly selected, and never sent). > But the fact that you're saying "even if x-y could be extrapolated..." is > worrisome. > > First, x==y, no? So isn't x-y always 0? > Second, a MITM can clearly control the nonce (remember, at this point the > server pubkey isn't authenticated yet, and the server entirely controls the > nonce), so your statement that "a new nonce is built for every > authentication attempt, and potentially meaningful data from (x – y) cannot > be generated without multiple attempts on the same shared secret value." > isn't accurate. > > Also, multiple attempts on the same shared secret value...what's hard about > that? > > Finally, this entire approach needs to stay out of the DOM. It's not just a > client authentication protocol, it's a server authentication protocol, > meaning you can't trust the foreign UI until the password has authenticated > the content coming in. > > > > On Wed, Sep 8, 2010 at 1:22 PM, Andrew Auernheimer <[email protected]> > wrote: >> >> Chris, >> >> The cryptographic primitives are long-standing and strong, and the >> source is open! Feel free to pick apart our proposed protocol >> specification! >> >> On Wed, Sep 8, 2010 at 12:15 PM, Christian Sciberras <[email protected]> >> wrote: >> > You're expecting us to trust YOU over the Government X? >> > >> > How do we know you're not working for the French Government (seeing >> > how you didn't list it in your conspiracy list)? >> > >> > I love jokes, but this is a bit too late for April's Fool. >> > >> > Cheers, >> > Chris. >> > >> > >> > >> > On Wed, Sep 8, 2010 at 6:59 PM, Tim <[email protected]> >> > wrote: >> >> >> >> Hello Andrew, >> >> >> >>> un-tl;dr abstract: SSL is broken. Certificate authorities only exist >> >>> to let the US, Chinese, Turkish, Brazilian etc etc government or >> >>> Russian mob spy on you (whichever is interested first). Well, I guess >> >>> they also exist to line the pockets of assholes who want $10-50 for >> >>> pushing a button. Luckily, we’ve remedied this! We’ve established a >> >>> way that a client, using only standard password authentication, can >> >>> validate a server’s public key and ensure that no third party is >> >>> listening (without the use of a trusted third party such as a >> >>> certificate authority or manual fingerprint verification). Read on for >> >>> a wonderfully simple hack and proof of concept code! >> >>> >> >>> Biggest problem we solve: “Trusted” third parties can’t be trusted and >> >>> criminals or hostile governments are free to launch man in the middle >> >>> attacks. Extensive research in this area has been done by by >> >>> Marlinspike, Dan Kaminsky and Mike Zusman which you really should >> >>> read. >> >> ... >> >>> The whole PKI architecture is broken and cannot be safely relied upon. >> >>> Any system of authentication which relies on a “trusted” third party >> >>> that you have no dominion over is flawed. DNSSEC is only an >> >>> incremental improvement with the same underlying flaw– I may trust the >> >>> ICANN, ISC, NIST, NTIA, the Department of Homeland Security, or >> >>> VeriSign more than the combined ineptitude and maliciousness of every >> >>> current SSL CA, but I still don’t trust them. The whole idea of a >> >>> trust anchor is fallacious. >> >> >> >> I agree with you, the currently used SSL/TLS PKI is fragile and >> >> subvertible. SSL/TLS itself isn't so bad (less a renegotiation flaw). >> >> >> >> >> >>> We set out to solve this problem in a way that can reconcile three >> >>> realities of security: >> >>> >> >>> * Users cannot effectively comprehend anything but password >> >>> authentication. They don’t understand key management, and the task of >> >>> getting hundreds of thousands or millions of users to install a client >> >>> certificate or generate a keypair (and not accidentally reveal the >> >>> private key) is a Herculean task that few IT departments want to >> >>> try. >> >>> >> >>> * Users cannot be trusted to manually verify fingerprints. >> >>> Seriously, they just won’t. Even the ones that perceive themselves as >> >>> sophisticated and security-conscious. >> >> >> >> Ok, maybe. Let's assume for now that these two assertions are correct. >> >> >> >> >> >>> * The network is now many times more hostile and open to attack >> >>> than the server. >> >> >> >> Really? Now compared to when? >> >> >> >> >> >>> HERE'S HOW CLENCH WORKS: >> >>> >> >>> 1. Client connects to server and sends hello. >> >>> 2. Server sends hello back, along with its cert. >> >>> 3. Standard Diffie-Helman key exchange happens in SSL/TLS/SSH >> >>> fashion. Initial handshake is finished, cypher spec is changed, now >> >>> here comes the magic: >> >>> 4. Server sends client the nonce value [ Ticks since unix epoch + >> >>> 16 bytes of random data ] >> >>> 5. Client sends userid/username to server. >> >>> 6. Client types in password, but password is not sent to server. >> >>> Both sides generate a hash. >> >>> Client generates y, a hash of [ client password + server's >> >>> public key, as client sees it + nonce from step 4 ] >> >>> Server generates x, a hash of [ client password + server's own >> >>> public key + nonce from step 4 ] >> >>> 7. Client and server use a symmetric and fair zero-knowledge proof >> >>> to verify that we both have the same hash without revealing the value >> >>> of the hash to one another. Imagine a two pan scale, and a secret of a >> >>> given weight of marbles in a bag. If we both place our bag of marbles >> >>> on the pans at the same time, if they come to an equilibrium we will >> >>> have verified our shared secret without revealing it to one another. >> >>> For more information on this step please see the excellent paper >> >>> “A Fair and Efficient Solution to the Socialist Millionaires’ >> >>> Problem“. >> >>> 8. Upon successful completion of the proof, the server allows the >> >>> session to proceed. >> >> >> >> >> >> This seems awfully similar in concept to the proposed Mutual >> >> Authentication protocol for HTTP. See: >> >> >> >> http://www.rcis.aist.go.jp/special/MutualAuth/ >> >> >> >> Note that it also uses a shared secret to provide the mutual >> >> authentication and incorporates server (SSL/TLS) certificates into the >> >> hashing process. I'm not sure on how the details differ, but if you >> >> haven't looked at it yet, you should. They already have a solid draft >> >> RFC. >> >> >> >> >> >>> THE ROADMAP FROM HERE: >> >>> >> >>> There’s some barriers to implementation on this for HTTPS. Firstly, >> >>> there needs to be a javascript function that returns the current >> >>> public key (or at least the fingerprint) of the https server called to >> >>> load the page in the current DOM. >> >> >> >> You're kidding right? You plan on relying on JavaScript to implement >> >> the crypto and password checking process? If you assume someone is >> >> already MitM-ing your SSL/TLS connection, then how do you know the >> >> JavaScript sent to you isn't malicious (backdoored Clench >> >> implementation) to begin with? >> >> >> >> >> >>> There also needs to be some >> >>> mechanism in the GUI of the browser that can’t be mimicked by an >> >>> attacker to inform the client that the current login form implements a >> >>> Clench-like authentication mechanism. Because obviously an attacker >> >>> can just rewrite the form if they’re MitMing and trick the user into >> >>> sending plaintext. >> >> >> >> Yeah, these kinds of protocols must be baked into the browser. >> >> Whether that be through an add-on or native, it needs to be >> >> distributed "a priori". Don't bother with JavaScript. >> >> >> >> tim >> >> >> >> _______________________________________________ >> >> Full-Disclosure - We believe in it. >> >> Charter: http://lists.grok.org.uk/full-disclosure-charter.html >> >> Hosted and sponsored by Secunia - http://secunia.com/ >> > >> >> _______________________________________________ >> Full-Disclosure - We believe in it. >> Charter: http://lists.grok.org.uk/full-disclosure-charter.html >> Hosted and sponsored by Secunia - http://secunia.com/ > > _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
