Nice catch! This looks like a trivial (and thus educationally useful) instance of an unknown keyshare attack.
Your 30-second look at the code needs more than 30 seconds. If a client connects to malicious server A, the private key it would use for that connection is different from the private key it would use on server B. So malicious server A cannot replay an authentication session on a different server.
Video is not suited for technical details.
It's not easy to quote / excerpt, to quickly refer back to previous (or later) parts, to take more time over parts that need it, etc; not the way text is.
My default reaction to "you'll understand if you just watch the video", is that someone is peddling bullshit and doesn't want me thinking too deeply.
Note, however, PBKDF2 has a bug where each additional block of output bytes is recomputed independently, which means the work factor (iteration count of the underlying hash algorithm) is applied separately for each block of output generated. So if you ask for, say, 1,000,000 iterations of PBKDF2-HMAC-SHA256 with 64 bytes of output, you are actually running two separate independent runs of 1,000,000 HMAC-SHA512 under the hood. This allows attackers to derive the output block-by-block instead of having to compute all or nothing, which can increase cracking speed in some cases (see 1Password writeup [1])
More simply, you can use a hash/KDF to produce a single block of seed with all your desired work factor imputed into that one value, and then stretch the seed simply as: for 1..n { hash(seed || n) } to get however many bytes you need to produce your privKey. In other words, 1,000,000 iterations of work for the seed, and a single iteration of work for each final block -- effectively all or nothing.
This will let you reduce the number of primitives to the single hash function you choose, which personally I think is much cleaner than introducing a whole PRNG into the mix.
[1] - http://blog.agilebits.com/wp-content/uploads/2013/07/playing...
That may or may not be true for traditional DH. For ECDH it's false. A Curve25519 ECDH private key, for example, is quite literally a handful of random bits. (Depending on how you look at it, it's a 256-bit number with some fixed bits or just 252-ish bits. I say "ish" because I don't remember the exact number of fixed bits off the top of my head.)
Edit: Fixed bogus EdDSA reference. Also, I just looked it up. A Curve25519 private key (http://cr.yp.to/ecdh.html) indeed requires exactly 252 random bits (or the 252-bit output of a secure KDF).
From looking at their tests and the PowerPoint file in their repo, they mention confirming that the hostname provided by the server in the challenge matches the SSL Certificate. Asking as someone who knows very little about crypto, under the assumption that they validate the hostname and are using TLS would it still be vulnerable to a replay attack?
All of these seem like pointless assumptions to have to make when a better protocol wouldn't have this problem in the first place.
In any case, I'm having a little bit of trouble understanding why this thing is useful at all. It helps against an attacker that compromises a server but isn't willing to inject malicious code into the JavaScript served up by the attacker, and attackers who want to target everyone without being detected might actually have that limitation, but more targeted attackers will just modify the JavaScript (unless they have some other deployment scenario in mind).
(Minor correction to my first post: I didn't actually mean "replay attack" -- I meant "relay attack". Whoops, silly typo. Although, now that I think about it, they might be vulnerable to replay attacks, too -- I make no effort to check for that.)
I'm not saying it's right, but as people keep reminding me there's a lot of grey area between 'bad' and 'perfect' and most of the time we don't get anywhere near perfect. 'Better' would be something for a lot of people.
When the SRP code was going around people kept saying "Hey use the javascript library" and for reasons similar to yours I said, "No thanks, when will the browsers support it?"
Because if we're going to use keypairs for authentication, it really should be integrated into the user agent, where it's extremely hard (and hopefully impossible most days) to inject code.
Ad networks get hacked all the time. Probably better than half the sites I visit will pop up a login prompt over the top of the ads, which means somewhere I'm logging in, an ad could very well be trying to get my credentials, and it only takes once for the UA to fail to prevent it and I'm in hot water.
If you don't know what the PRNG is for, perhaps a cursory 30 second lookover and then crap all over wasn't enough. ;-) Watch the 9 minute Tech Video, which explains, the asymmetric key generator can't use a fixed length seed; it needs to be a random stream. Also, there's a challenge/response which can only be answered by knowledge of the client's private key, so your comment about the replay attack (I think you meant relay attack) is also incorrect - whichever you actually meant, you're wrong either way.
PAKE can be used to construct all kinds of things. You can generate a key for one session, you can generate a persistent key, you can run a PAKE to authenticate an existing session, etc.
The algo can work by the site sending the user their personal salt. The algo will then encrypt the password, use the salt, and send the derived key.
This DOES remove the burden on the user of trusting every site with their password. The problem is quickly the password is only but one of a lot of data hackers look for.
> To cryptographers, the phrase “prove you know something secret without exposing it” instantly suggests “use asymmetric cryptography.”
No, wrong, stop right there!
The phrase "prove you know something secret without exposing it" instantly suggests that you should figure out what "exposing" means before you try to design a protocol. If I'm a user reusing a password between two sites, then it's unavoidable that either site can try to brute-force my password. However, it would be rather nice if an attacker who hasn't compromised either site can't brute-force my password without interacting with one of the servers for every single guess.
That property is achievable using well-understood techniques, and this blind use of asymmetric cryptography fails to achieve this goal and is unnecessarily complicated (what's the PRNG for?). The primitive you want is an "augmented PAKE". The IRTF CFGR is very slowly working on standardizing one, but in the mean time there are several high-quality augmented PAKEs out there.
Also, note that I said "primitive". A strong primitive does not automatically make a good protocol. CBCrypt's docs say "Keypair is ECDH 256, derived from SeededPRNG". This raises all kinds of warning bells: while there are perfectly good protocols based on ECDH, ECDH by itself just gives an /unauthenticated/ session key, and from a 30-second look at the code, CBCrypt appears to be trivially vulnerable to a replay attack in which a malicious server A convinces a standard client to give it a valid authenticator for a session to a different server B.