5 ms·
"CBCrypt deterministically generates a public/private keypair unique to each specific user, on a specific server, using a specific password. Any variation of an
by dchest 11y ago
"CBCrypt deterministically generates a public/private keypair unique to each specific user, on a specific server, using a specific password. Any variation of any of these factors results in an entirely different and unrelated keypair."
If it deterministically generates a keypair from a password, then attacker acquiring a public key is equivalent to acquiring a password hash — the public key now becomes a verifier.
"The worst attack a malicious server can mount is an expensive brute force attack, attempting to overpower the rate-limiting function and eventually guess a password that recreates the exposed public key."
Almost the same result as if the server just stored an scrypt hash, but more complicated, and without a random salt. The solution for the problem just makes it worse.
- Stefan-H 11y agoNot quite - a malicious server would receive the plaintext password in the current status quo.
- StavrosK 11y agoYou could scrypt on the client.
- ybx 11y agoYou're still passing the output to the server, which can be repeated. Certainly better than just a password, but not as good as public key crypto. In the end, I'd probably prefer something like SRP
- deleted 11y ago[deleted]
- imaginenore 11y ago> You're still passing the output to the server, which can be repeated. Not if the server generates a unique ID for each attempt, and that ID must be used in hashing. It can be as simple as a timestamp.
- k3d3 11y agoWhich is then going beyond just using scrypt on the client. What you explain is simply challenge-response authentication.
- Retric 11y agoIf a server just wants a hash, then that hash becomes the password. MITM attacks still work as long as all server credentials are public. EX: A fake wifi hotspot wants to MITM a connection and can fake any public information (public key's, IP's, DNS, etc.) Further, a fake website can sidestep this by not using a secured connection and just faking the UI.
- Stefan-H 11y agoIf you read the mechanism, you'll see that this involves more than a site faking the UI - it requires browser integration. This mechanism does not protect a single site, but rather the ability to pivot from one site to another with the same password or key. You also breeze over "can fake any public information" - I have no idea what you are trying to say by the ability to fake public keys - that is not really a thing. HTTPS rides on having a trusted intermediary and so even a malicious MITM couldn't simply fake a public key.
- Retric 11y agoYou run into the question, is this the 'magic' UI or a PNG send from HAXORU. Windows reserves CTRL + ALT + DEL for this reason, but doing that on a tablet / phone that's already in production quickly runs into issues. Also, windows had plenty of issues with fake login screens. PS: I suspect protecting people from such things ends up requiring fairly strong AI or significant compromises.
- ybx 11y agoThe difference here though, is that the private key is not being sent verbatim to the server.
- deleted 11y ago[deleted]
- hinkley 11y agoIt's not the same. The main point of asymmetric ciphers is that it's a very good way to prove I know something without ever revealing the thing I know. Instead of sending the public key every time, the server sends a challenge, which only the private key holder can answer. This is a pretty basic usage of keypairs and an extremely brief perusal of their source code suggests to me they've thought of it. So no, the public key is not the password, unlike hash based systems which do suffer from the problem you're concerned about. The hash IS in fact now your password in those systems.
- tptacek 11y agoCan you explain in more detail why you believe the public key "isn't the password" the way it is in a "hash based system"? I don't think this is true, but I'm not totally clear on what you're arguing.
- hinkley 11y agoHey I got pulled away from this conversation and didn't continue. In most systems where the server never sees your password, they store a hash that is generated from the password. Then the login code on the client takes the password, performs the same operation and then sends either that same hash to the server, or one that's simple to calculate from it. So if I steal your password file, I can log in as everybody without even knowing what their passwords are. I just change the code in the client to skip the hash generation part of the authentication algorithm and use the one I supply. The idea with asymmetric ciphers (at least the ones that interest us) is that one party HAS to know the secret, and the other has no way to get it.
- tptacek 11y agoI'm even more confused now. I think you're saying that this system is better because, since it uses public key pairs, an attacker who steals the password file doesn't know enough to log in as a different user. Leaving aside that an attacker who steals your password file has probably mooted login security altogether, the attacker in this system seems to have exactly the same leverage as an attacker who steals a password file full of scrypt hashes.
- tptacek 11y agoIt looks like the client generates: S <- scrypt(zeroes, SHA2(name, pw, host)) secureSrand(s) keypair <- keygen(ecdh, secureRandom) The client sends the pubkey to the server, the sever sends nonce challenges to the client.
- dchest 11y agoI don't understand the second line of your pseudocode -- I read the description as not having any ("external") random bytes, just the PRNG initialized from the seed derived from scrypt: "CBcrypt combines publicly known authentication factors (typically username and server id) with secret factors (password), applies a rate-limiting work function such as scrypt or pbkdf2, to deterministically generate a random seed. This seed is then used in a pseudo-random number generator (prng), and the prng is used as the basis for generating a public/private keypair." EDIT: ah, got it (libc! :), secureSrand means "initialize PRNG with seed", so we're talking about the same thing.
- tptacek 11y agoYes, "srand" was my shorthand for that, but since I just invented that shorthand, I'm not surprised it was confusing. Also: is it safe to use a secret-seeded DRBG as a CSPRNG for ECDH keygen? The time it will take to generate the ECDH key will be secret-dependent, right? (I'm sure it doesn't matter in this case. Just curious about the general case.)
- dchest 11y agoI think it's safe, but we need real cryptographers to figure this out (does Matthew Green approving miniLock count?). With proper Curve25519 implementations key generation timing shouldn't be secret-depended: it's the same scalar multiplication (crypto_scalarmult_base).
- admax88q 11y agoThe benefit here is you don't have to trust the server to actually store an scrypt hash properly. And it's been pretty obvious that most service providers have no idea what they're doing and can't be trusted to do that.
- tptacek 11y agoYes, you do have to trust the server.
- sarciszewski 11y agoSpecifically, to deliver the Javascript in the first place.
- tptacek 11y agoNo, I mean, you have to trust it to store password hashes, just like in any other scheme. The ECDH public key is generated deterministically from the password. If you have it, you can crack it to recover the password.
- sgk284 11y agoHis underlying assumption is that given an ECDH public-key it is computationally infeasible to derive the private key / seed that went into creating it (via brute force). I suppose that's a fair assumption if your password has high enough entropy or is stretched sufficiently?
- tptacek 11y agoNo. The security of the password storage in this system has nothing to do with that of ECDH.
- sarciszewski 11y agoThis sounds worse than I imagined when I was reading through it earlier. Sorry if I muddied the waters earlier.