16 ms·
CBCrypt: Encrypt from the client rather than send passwords to servers
- vixamincessidnt 11y agoWhy not use the existing secure remote password protocol instead of inventing a new protocol? https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol#Protocol https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...
- rsy96 11y agoSounds a good idea. I'd like to see a more technical description of how it derives the public/private key pair from a password. In addition, the language choice of C# is probably going to limit its popularity, given how C# is still tied to Microsoft world (I know they are open sourcing .Net, but that has not matured yet).
- jakeva 11y ago"If a user attempts to login to a malicious site accidentally or because they were tricked by a similar but different name, the malicious server will only gain knowledge of a derived public key. The attacker will not be able to impersonate the user at any other server, or even on the compromised server, because the attacker has not discovered either the user's private key for connecting to the compromised server, or the user's password that could be used to derive the private key on this or other servers." Doesn't this assume a lot about the state of the internet? I mean a phishing attack could easily harvest the user's password, then the attacker effectively has their private key. Unless every user were trained well on how to determine whether the connection can be trusted, but that's still a problem today in 2015 even with https.
- pjc50 11y agoNo, that's not a problem at all; the key appears to be derived from more than just the password. The only weak spot is if you can run arbitrary code on the user's PC. (I'm going by the textual description on the linked page as there doesn't seem to be a more detailed or formal one)
- jakeva 11y agoThe key, as I understand it, is derived from a combination of the password and other deterministic elements, like the host URL. I suppose it's supposed to be ethereal, generated only for the session and the disposed after the user logs out. But for it to work, the user would have to be able to generate the exact same key on other machines using the same password. In which case, all an attacker needs to obtain the private key is the password and the vulnerability to phishing remains.
- eximius 11y agoI think you're missing the fundamental point here - users of this technology will never enter their password online again. Instead, imagine new HTML elements and you could have <form type="cbcrypt"> <input type="username" /> <input type="password" /> </form> and the web browser would allow you to enter your credentials in a secure, NATIVE window. (At least secure from web stuff - keyloggers get a lot more powerful under this scheme.) If it works as advertised, it's quite nice. Personally, I think this is very close to what we need. I will note I still probably wouldn't use it because if your password is exposed, then you're screwed. It is very close though. A hardware element or something might mitigate this enough.
- jakeva 11y agoOk, but how would a native window prevent an undereducated user from naively entering their password into an attacker's spoofed login form? In my mind this strategy more or less kicks the ball down the field as opposed to revolutionizing security.
- btreecat 11y agoWould this not still be phishable? All an attacker would have to do is make a website look enough like the real thing, then use a plain <form> element and capture the submitted form content. I would think an out of browser app might work better for that task.
- 0x0 11y agoWell, there's always the venerable but little-known <keygen> HTML tag already... :)
- peterwwillis 11y agoIf this is traditional public-key crypto, having the password does nothing for the attacker without the private key. But I didn't watch his "technical details video" so I don't know what he's actually implemented. He mentions that getting the user's password would allow you to derive the private key, which makes no sense.
- jakeva 11y agoThat's exactly the problem. The private key and the password are effectively 1-1. So if you can phish the password, you have the private key. This solves nothing.
- peterwwillis 11y agoI still don't understand the model, then. How the hell do you derive a private key from a password?
- devit 11y agoThe hard part is getting browsers to all implement something like this (all with the same specification), which for some reason hasn't been happening, despite the fact that a mechanism like this is an obvious design that is obviously better than sending passwords.
- deleted 11y ago[deleted]
- dorfsmay 11y agoBrowser support would be better, but sites could already implement it in JavaScript.
- peterwwillis 11y agoThrow a password on SSL/TLS client certificates and you have something that sounds about the same. Nobody used it because it was confusing to users.
- joeuser3932 11y agoPassword on an x509 cert requires the x509 cert to be stored or made available to the client somehow. The whole point of CBCrypt is to allow password authentication and encryption without the user needing to change any behavior or learn anything.
- 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.
- CCs 11y agoThere's an issue with passwords/keys not sent to the server: what if the user forgets the password? No "Forgot your password?" functionality available (reset token), since the server does not store password (hashed or otherwise).
- elektronaut 11y agoYou can email the user a one-time token for setting a new password. You should never store the users password.
- CCs 11y agoWhen you email a token, you're back to square 1 and will need 2 factor auth. In addition the reset password is not possible when the data is encrypted on the client side. This is how TrueCrypt works - if you forget the password, all your data is lost.
- DasIch 11y agoData isn't encrypted on the client side only the "password" is.
- CCs 11y agoData encryption on the client side is one of the 5 features. See https://github.com/rahvee/CBcrypt https://github.com/rahvee/CBcrypt and the "Tech Details Video". "Users are able to login to servers, and encrypt all their data, without ever exposing their password or encryption keys to the server." "And if the user's data on the compromised server is encrypted using the user's keypair, then even the users' data is still protected."
- deleted 11y ago[deleted]
- Someone1234 11y agoSo essentially this is a really convoluted way of concatenating username, password, and domain then running scrypt() on it, and sending that to the server as the password instead of the raw password itself? I actually read the Github page for this, and glanced over the C#. There's no realistic example of how this would work in practice, and I have unanswered questions. This would legitimately solve some phishing scenarios and MIGHT slightly mitigate password reuse scenarios (since they know username + domain, they now need to spend time cracking scrypt() on the password). The arguments that it helps user privacy (NSA something something) are tin foil hat wearing jibberish. Overall: Meh. If they're serious about this, they need more than a vague proposal. PS - And a password manager solves all of the named issues with less complexity in my opinion.
- paulgb 11y agoThere is a (somewhat) practical version of this implemented as a bookmarklet: http://www.supergenpass.com/ http://www.supergenpass.com/ I used it for years (for unimportant things) before switching to a password manager. It's technically not secure against a malicious site that sniffs for the existence of the bookmarklet window, but it's a good way to get slightly better security on sites you'd other reuse the same password for.
- capnrefsmmat 11y agoI use a much simpler version of the idea in the form of PwdHash: https://www.pwdhash.com/ https://www.pwdhash.com/ Before submitting passwords to a website, they're replaced with a hashed version which incorporates the domain, so passwords are unique to each domain. (The hash isn't anything fancy, so it could definitely be modernized with scrypt or bcrypt or whatever is fashionable.) I've used it for years and it always works well, apart from the sites that claim my password is too long. It requires no support from the website, just a simple browser extension.
- jonknee 11y agoWhy not just use a password manager?
- aggieben 11y agoMy reaction is one of those "I'm not sure if I should feel stupid or not" moments, but: rightly-built applications already don't expose passwords to employees in that they aren't (or at least, shouldn't be) generally persisted. Usually the plaintext passwords live in volatile memory briefly while the server computes a hash of some kind for comparing with what is stored. I suppose an admin could run a web application under some sort of memory profiler, or take a dump at exactly the right moment, and capture a plaintext password, but that seems pretty far-fetched. CBCrypt seems to me to introduce a lot more complexity into the entire application space with very little real gain. I'm certainly open to being convinced (especially because I'm waffling on whether or not this is a dumb reaction).
- ybx 11y agoThe idea is that you're implicitly trusting the company (or website), as well as anyone who has (whether legit or not) access, to only keep that password in memory, and it's preferable to authenticate without requiring that trust.
- aggieben 11y agoI can agree to this: this allows a user to not have to trust that the company running the application set up password authentication properly. But still: I just can't get worked up about this at all. I'd rather see pgp get implemented in browsers before this.
- k3d3 11y agoYou can already use TLS client certificates - the UI is just terrible is all.
- Freaky 11y agoPeople generally aren't carefully clearing passwords from memory after use, and ideally GC runs aren't happening all that often. "Exactly the right moment" could easily extend out to many minutes.
- creshal 11y agoWhatever happened to challenge-response schemes in the vein of CRAM-MD5?
- dorfsmay 11y agoGood question. This would be even better.
- ybx 11y agoYeah, there are plenty of authentication systems out there for this kind of thing, and preferably something like SRP would be used.
- cvwright 11y agoAnd before SRP there was EKE. I thought the main reason it never saw wider use was because it was patented. Although according to Wikipedia, those patents expired in 2011 and 2013.
- yaur 11y agoChallenge response schemes generally require the server to have the password in a recoverable format so that both sides can generate identical hashes. IMO the current state of things is better than it would be with 1000s of random websites with DBs full of clear-text passwords.
- creshal 11y ago> Challenge response schemes generally require the server to have the password in a recoverable format so that both sides can generate identical hashes. Do they? Doesn't the server just need to share the salt and algorithm parameters it stores anyway?
- jcranmer 11y agoThe server can store the salt and parameters, although it gets really hairy if you decide that MD5 is too weak and now you want to upgrade to SHA-1 or SHA-256.
- faleidel 11y agoWhy can't we use PGP tu login to websites? That way the server only has your public key (and everyone can have it anyway).
- ybx 11y agoFrom a usability perspective, it's probably because dealing with keys that can't just be memorized is hard for most people.
- faleidel 11y agoSeems like the solution already exist : password managers. But yes, having small memorizable passwords is much more convenient.
- scott_karana 11y agoCan you imagine how easy it would be with browser integration, though? :-) "The site is asking you to sign up. What secure login key would you like to use? * Personal * Office * Contracting"
- eximius 11y agoThis is what I am planning for a project of mine called AutoAuth. It's put on hold cause I have no idea how to write Chrome extensions.
- eximius 11y agoThis is what I am planning for a project of mine called AutoAuth. It's put on hold cause I have no idea how to write Chrome extensions.
- lsaferite 11y agoWhy even have those if you are, presumably, presenting yourself as the same person in each case? You are person 'A' and you have the private key (and maybe password used to unlock the key) to prove this fact. You don't need different private keys for each and the remote end just has a public key that says the account belongs to person 'A' and that key is public.
- yaur 11y agoThe server has all the inputs except the password and enough information to validate if it has guessed the right password. So password guessing/dictionary attacks are still viable, especially with state level adversary. BUT users are given a false sense of security because "the password is never sent to the server". So we can expect users to (on average) use worse passwords and reuse passwords inappropriately. IMO, if you are going to use client certificates you should be just be using standard client certificates with whatever your OS provides to generate them.
- caskance 11y agoI'd rather just use SAML, OAuth, SQRL, etc.
- kilovoltaire 11y agoI don't see how this can claim to prevent phishing attacks. A fake site can still just steal your username and password as usual, and then go to the real site and log in with them. Am I missing something? Obviously there is still a benefit to not sending your password to the real site, but their anti-phishing claims seem… phishy.
- amelius 11y agoThis is only a tiny improvement. Any password cracker can figure out your password just from the hash anyway. What we really need is industry support for and general acceptance of two-factor passwords. I want to generate one-time passwords from my smartwatch, have them sent to my keyboard or computer directly, and be able to log in to gmail and through ssh alike. Is it just me, or does the current way we handle passwords feel archaic, even while we still use them?
- ceronman 11y agoThe main problem this project is trying to mitigate is the password reuse. If user A uses the same password for a lot of sites, a malicious person B is able to convince A to join a new service, like a cat photo sharing app or something like that. If A uses his/her same usual password, B automatically gets access to all A's accounts. The way this project tries to solve the problem is by hashing the password from the client side so that sites never get the real password, but a hash instead. As other commenters have pointed out, this is not entirely effective because the attacker still can crack the hash. It just makes the problem more difficult depending on the size of the original password. The real solution to this problem is to stop sharing password at all. Use a password manager for that purpose.
- api 11y agoA good hash like scrypt makes the password very, very hard to crack unless it's a very poor password. The real problem with this is that it'd never be feasible to convert enough sites and apps to using it to make it safe to reuse passwords
- Stefan-H 11y agoAs the page points at, the malicious website does not recieve a hash of the password, but rather a public key derivied from the password: "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." That is a very different attack to try to pull off.
- amenghra 11y agoPhising sites can bypass this by creating an input field which looks like a password input field but isn't actually one. +1 for password managers or U2F style authentication systems.
- meritt 11y agoHow is this any different than every other "hash a bunch of shit and throw in a salt" half-baked encryption idea people continually invent?
- homakov 11y agoI'm working on the same problem, and there's a working prototype https://github.com/sakurity/truefactor https://github.com/sakurity/truefactor The problem is bigger than that - we should stop making users type password at all. There should be an authentication module any website could use to store and retrieve credentials from. Check out Truefactor.
- valarauca1 11y ago> There should be an authentication module any website could use to store and retrieve credentials from. How do you plan to do that securely?
- homakov 11y agoOpen truefactor:// app. Currently there is only a Web version and it has serious downsides (web crypto is a bad idea), but think of it as a Light version. Desktop apps to come later.
- valarauca1 11y agoI was looking for more of a write up. I'm just wondering how/where the credentials get cached and how you securely know the user re-connecting is the user who previously disconnected.
- homakov 11y agoCredentials are encrypted with passphrase and seamlessly stored on the server by token=sha256(passphrase). https://truefactor.io/ https://truefactor.io/
- valarauca1 11y agoSite gives me a login page. I make a login and I get no information about the service just user options. Also where is the salt stored? SHA256 is pretty easy to brute force even salted.
- ouistiti 11y agoOr better still, just create a RESTful stateless API and implement JWT?
- mrbig4545 11y agoso the hash of the password becomes the password. i don't see the gains tbh
- nitrogen 11y agohttps://en.m.wikipedia.org/wiki/Secure_Remote_Password_protocol https://en.m.wikipedia.org/wiki/Secure_Remote_Password_proto... Does this provide any advantages over SRP?
- cvwright 11y agoLooks like a "No". It also doesn't instill confidence when somebody talks about "encrypting" passwords rather than hashing them.
- wnevets 11y agoWhats makes this different from SQRL? https://www.grc.com/sqrl/sqrl.htm https://www.grc.com/sqrl/sqrl.htm
- k3d3 11y agoSQRL relies on phone cameras and QR codes, for one
- Mimick 11y agoI think LastPass (assuming it's secure) solved this problem on a more practical way. You get a random generated password for every website, and it won't suggest to use it unless you are on that website.
- wglb 11y agoI wouldn't recommend lastpass: http://www.businessinsider.com/security-expert-describes-lastpass-vulnerabilities-posted-to-pastebin-in-2013-2015-6 http://www.businessinsider.com/security-expert-describes-las... 1password is better.
- balaa 11y agoIsn't this basically what Kerberos does?
- joeuser3932 11y agoKerberos sends the password to the server. https://en.wikipedia.org/wiki/Kerberos_(protocol) https://en.wikipedia.org/wiki/Kerberos_(protocol)
- deleted 11y ago[deleted]
- hinkley 11y agoI think the Stanford folks were on to a better solution for this problem. (I have no affiliation) Use all of the authentication data as the seed for generating a key pair. When you create a new password you send the public key to the server, where it is stored. The private key is regenerated on the client on every authentication challenge. I submit for your perusal: http://srp.stanford.edu/ http://srp.stanford.edu/
- tptacek 11y agoThe serverside authenticator, which the server stores, is crackable back to a password.
- hinkley 11y agoIn SRP? Ah that's a shame, but explains why it didn't get adopted. But now that I RTFA'd these guys seem to be using the same basic concept so I'll be keeping an eye on them.
- Tomte 11y agoCan you point me towards a short explanation?
- tptacek 11y agoThe client sends the server [salt, modexp(g, H(salt, password), n)] The exponentiation makes the brute-force attack a little bit harder than a simple salted hash, but not that much. You can obviously replace the salted hash with something else, and that's a good idea, but the point of this post is that password hashes are insufficient to protect user secrets. I disagree with the post, of course.
- Tomte 11y agoI may be dense, but is the problem the same as with the usual discussions of salted password hashing, i.e. if H were bcrypt() it would be fine, or am I missing some simple mathematical thing? Edit: okay, you just answered that. Thanks! :-)
- tptacek 11y agoTryValidateChallengeResponse at: https://github.com/rahvee/CBcrypt/blob/master/CBcrypt/CBcrypt/Challenge.cs#L51 https://github.com/rahvee/CBcrypt/blob/master/CBcrypt/CBcryp... ... appears to have a straightforward, helpfully inlined timeable comparison of challenge responses. I don't understand what this package is accomplishing. The description leads off talking about the grave privacy implications of storing scrypt password hashes. But then it stores what is in effect an scrypt password hash on the server.
- Bognar 11y ago> The description leads off talking about the grave privacy implications of storing scrypt password hashes. But then it stores what is in effect an scrypt password hash on the server. I don't think it's saying that storing the hash is bad, it's saying that sending an unmodified password to be hashed on the server is bad since that server now has your cleartext password.
- tptacek 11y agoAh, that's clearer. Then the other comments are right: they've just reinvented SRP.
- sarciszewski 11y agoWow, it looks like they went out of their way to make it leak timing information.
- bagosm 11y agoIt does one thing better than a password manager: it prevents rainbow attacks via forced localized salting. That's about it... Next HTTP can solve other problems...
- aimatt 11y agoStill just as susceptible to rainbow tables.
- joeuser3932 11y agoSee the Tech Video. Defense against rainbow tables is periodic salt changing, to put a limited time scope on brute force calculation time.
- ricksplat 11y agoAs far as my limited understanding goes, MS-CHAP v2 allows you to store a hash of your password on the server rather than storing the actual password. Then through a convoluted sequence of hashing algorithms it generates another hash and compares that with a hash you have provided. I think it's been around since at least 2003 and though it has itself been cracked (cf Moxie Marlinspike) I don't believe it's ever expected to be used outside of an encrypted tunnel (cf Matthew Gast).
- kpcyrd 11y agoI think it's amazing that there are so many security conscious people that are very sensitive about passwords and storing them as plaintext is worse then hitler, but nobody questions how we're still stuck with plain shared secrets for authentication in 2015. If the concept of passwords wasn't so fundamentally broken a password leak wouldn't be an issue, not even if it's plaintext. "Oh no, my shared secret for this site got compromised and now all my accounts are compromised because I authenticate to 50+ other sites with the same secret." This is like putting your only private key on every service and complaining if bad things happen.
- hasenj 11y agoHow does public-key authentication work? Over things like, ssh, I mean. Does the client send the private key to the server for verification? I'm not sure but I doubt it. At least I hope that's not what it does. My guess would be that the server sends an encrypted message of some sort that the client cannot decipher unless it possesses the private key. It deciphers the message then sends it back to the server in deciphered form to say: hey, see, I have the private key, here's the proof: this is the message you sent me earlier. I couldn't have deciphered it without having the private key. Can this scheme be used with passwords as well? As in, treat the password as a private key, so the client never has to send it over the network. Server ---- [garbled-message-challenge] ---> Client Server <--- [ungarbled-message-response] --- Client Does this scheme work?
- tptacek 11y agoStart here: https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exc...
- hasenj 11y agoSeems to be talking about encrypted communication. I'm talking more about authentication over a channel that's not necessarily encrypted. The point being, avoiding having the client send its "secret pass word" to the server, but still allowing the server to verify the identity of the client.
- tptacek 11y agoDiffie Hellman is the cryptographic standard solution to "share a secret (and thus authenticate) over an unencrypted channel". It's also what SSH uses. Hope that's helpful!
- hasenj 11y agoThe point is doing without sharing the secret. I don't want to share my secret with you. You just throw a test at me that only I could possibly answer. The point is, every time you should throw a completely different test at me. Not only you can verify my identity, but anyone who's listening to the conversation can also verify my identity, and I don't have to share any secret.
- ajanuary 11y agoThe website does a really poor job of emphasising that it's using asymmetric cryptography and some sort of challenge/response protocol, and how that is really where the improvement over the status quo is. It's _not_ just sending a hashed password. I actually don't know very much about challenge/response protocols, and I'm struggling to find any good resources, so take this with a grain of salt. You could build a protocol out of digital signatures (probably there are massive things wrong with this, don't do this, here by dragons, don't build your own crypto etc. etc.): 1) When the user registers with the site, the client generates a public/private key pair and sends the public key to the server, which stores it. 2) When the user wants to log in, the server sends a challenge to the client. The client uses their private key to sign it and sends the signed message back to the server. The server uses the public key stored against the user to validate the signature. Obviously this is more than just hashing the password on the client. If the server sends a different challenge each time (possibly time based like OTP?), you're protected against replay attacks. The problem is you need a key pair. You don't want to generate a random one because then the user has to manage it and keep it with them and copy it from machine to machine etc. So the problem solved on the website is how to generate a good key pair from just a site identifier, username and password. How effective it is at that, I have no idea. [edit] other posts have helped me realise the public key is just an unconventially derived hash. Even if it's used in an unconventially way for authentication, you can brute force it the way you brute force any general hashing algorithm: key == generate_key(password_guess)
- tptacek 11y agoIt is sending a hashed password; it's just sending it in the form of an ECDH key. The key is generated deterministically from the password.
- d1plo1d 11y agoI'm still trying to figure this out but isn't it sending the ECDH of the private key which would be much longer then what the average user is going to use as a password (eg. I don't know, 1024 bit or something) and therefore more secure then sending a hashed password? Edit: And then you (maybe?) use your password to encrypt the private key locally.. maybe? That's a total guess. That's what I'd do :P
- smartera 11y agoThis is all nice; and as hinkley pointed, Stanford already proposed a better protocol. The primary issue in my opinion is how to trust the JavaScript arriving from the server that it does what it's supposed to do. In my humble opinion; we need to use the blockchain to save hashes for trusted and open-audited JavaScript files to be confirmed by the user. This, however, needs to be done at the browser level to avoid an endless trust loop with JavaScript/browser extensions. blockstrap.com has figured out how to put file hashes on the chain; so technically it shouldn't be a major challenge to do the first part. The browser part is where it gets tricky!
- admax88q 11y ago> is how to trust the JavaScript arriving from the server that it does what it's supposed to do. This is an orthogonal problem. Something like CBCrypt would solve a real problem we have right now, which is most service providers don't secure their password database correctly. If a service provider gets hacked to the point that they their javascript is malicious, all your content on that service is probably already pwned.
- pg_is_a_butt 11y agoif you encrypt the password, then that encrypted value IS the password relative to the service and the shady employees you're so afraid of.
- deleted 11y ago[deleted]
- amluto 11y ago> It should be ok to reuse passwords at different sites - provided that the passwords are never exposed to those sites. > 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.
- Justsignedup 11y agoWhile true, the risk of exposure is significantly smaller if the derived key is different for every site. 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.
- microcolonel 11y agoThat's not necessarily true; If it can generate multiple outputs for the same input, it could mean that the derivation function exposes something about the secret in the degree or nature of the variation.
- lisper 11y agoOr people could start using something like this: http://www.dswi.net/ http://www.dswi.net/
- Sanddancer 11y agoClient certificates already exist. The problem is that nobody uses them, because every step of the process is a complete and utter pain in the ass. Much like how standard HTTP authentication is ugly, making the existing infrastructure prettier would be much more useful.
- lisper 11y agoI agree, but only the browser vendors can do that. The point of DSSID was to try to force the issue by implementing a usable UI over what is essentially a client cert. If enough people started using it, that just might nudge the browser vendors into doing the Right Thing.
- huhtenberg 11y agoThey are not the first to invent an "RSA-keypair-by-password" scheme and certainly not the last. The main issue with these is the fact that an estimated entropy of English language is 1.2 bit per symbol [1], so even if you are using pass-phrases, you are still generating an RSA keypair with a PRNG with only few tens of bytes in randomness in it. [1] I think this was in one of Shannon's papers, but not sure. It should be very easy to find though. Basically once you start digging around a topic of using passwords as PRNG seeds all relevant research surfaces very quickly.
- dheera 11y agoI still would not reuse passwords on different sites, unless the code that is being used to communicate with their servers is open-source and has been vetted by either myself or others who have some sense of cryptography. Unfortunately, neither mobile applications nor the JavaScript on most web pages are open source, so there's no guarantee that they have implemented this strategy correctly. You don't know what happens after you type a password into a text box. It's also too idealistic to expect that enough people will implement this kind of system such that you can advise people that it's "okay" to reuse passwords.
- z3t4 11y agoThe only thing that will save you is your enemies incompetence :P Make sure you encrypt ALL communication and not just the password or cookie.
- nfirvine 11y agoHow is this not functionally equivalent to TLS client-side certificates? Yes, I understand that there's a UX problem, but CBCrypt has to solve that in addition to the crypto problem. Also, C#? What is this, a Silverlight applet? :P
- nfirvine 11y ago"due to Third Party Doctrine, users forfeit their legal right to privacy by merely making it possible for sysadmins to access their information. This means the sysadmins can legally share users' information and passwords with additional third parties, and the NSA can legally spy on it all, without any need for a warrant or probable cause." This sounds super fishy to me; feels like a misinterpretation made through tin-foil lenses. Citation please?
- AstroChimpHam 11y agoHe keeps talking about how this is going to prevent malicious employees from getting at your data or sharing it with the NSA. It's not. Facebook, Google, and every other website you use will still have unencrypted access to all of the information you give them on their servers. The only thing this would keep them from having is the password you use to protect that other stuff they already have access to anyway.
- zobzu 11y agoPasswords is one thing, but its sending information to servers that is the issue. Things like U2F have a better chance of solving the password issue. Information though.. i'm happy with google apps processing my data but i'd rather they can't actually store the data on their servers. Ex: lets say you're a gmail user. Wouldnt it be nice if only your browser could read the contents and gmail servers only metadata? Obviously, Google wouln't want that (remember, you're the product) - but that would be nice in the grand scale of things, wouldn't it? Like you know, instead of being slaves of corporations, just have them do stuff that's good for us and what not (dreaming out loud right now)
- jtwebman 11y agoServers are far more secure then a users computer so I would trust a server over even my own computer. All things a user can do very badly if they don't know what they are doing, will. I have been in software long enough to know that. Good luck but I just don't think this is the solution as it still relies on SSL which I think is the weakest link, not the server or the make believe bad employees.
- phlay 11y agoThis looks very similar to my password authentication method PSPKA or 'password seeded public key authentication'. See https://github.com/phlay/pspka https://github.com/phlay/pspka, if you are interested.
- zaroth 11y agoAs a client-side hashing approach, I think it's a bit overly complicated but probably not fundamentally flawed. I would use a singular hash function to produce the byte stream, instead of introducing a PRNG and seeding it from the hash functoin just to get a byte stream. But the bigger conversation is, what role can client-side hashing play, either as a full-on replacement to server-side hashing, or perhaps just to augment the server-side hashing everyone is doing today? Stepping back a minute, it's helpful to consider the fundamental reality of almost any password validation scheme. In this case we are storing a "public key" on the server, but it is more aptly described as the "password validator". Almost all designs will have such a thing (a notable exception is PolyPassHash which cleverly avoids a one-to-one mapping of users to validators, and uses this to try to defeat some offline attacks, with some interesting trade-offs). If you combine public information, the password validator, and the correct password, your 'password validation function' will complete and return 1. Therefore, if you have the necessary public information (i.e. domain name, username, whatever else is stuffed in the hash) and you steal the password validator database, you now have everything you need in order to run the so-called "offline dictionary attack". In SRP, an obvious inspiration to this CBCrypt design, the password validator database is basically computed entirely by the modexp() work required to generate the pub/priv keys. There is no additional/configurable key stretching which can be applied other than choosing the bitlength of the keys. Here we have a configurable round of hashing (Scrypt or PBKDF2) which is applied before the key derivation step. This provides additional protection against offline attacks, depending on how hard the work factor is set. History has shown us, a key detail in ensuring secure password storage is actively managing the hashing function and work factors over time, or else watching Moore's law strip away any protection we thought we had.... So the next key question is, how do we actively manage and maintain a sufficient work factor? When evaluating a hashing function, one key question to ask is can we add to the work-factor of existing passwords offline (without having the password in RAM) or do we need the user's password resident (somewhere, client or server-side) in order to recompute a new hash with the new work factor? In this case, by design it's impossible to offline harden the existing passwords. You would need to first login the user, verify their password, and then recompute a new hash (perhaps transparently, perhaps with some UI component if it is too slow otherwise) and re-derive and update the key server-side, in order to change the work factor. But really, the primary consideration with any client-side hashing design, is how to support the extremely wide array of devices which will need to register/login to your site, and what's the user experience when they click the Login button? From CBcrypt.cs, where the proof of concept is written in C#.NET using BouncyCastle's Scrypt library: /* cost 4096, blockSize 8, parallel 1, cause SCrypt to take ~175-350ms on Core i5-540M, 2.5Ghz * This is in addition to the approx 100ms-200ms to generate ECDSA keypair. */ Now, in reality we are going to be running Scrypt in Javascript on a mobile device. I found what seems to be a highly optimized implementation [1] and plugged it on Dropbox [2] so I could point my browser at it to see how slow just the Scrypt ran. On my laptop it was taking about 800ms and on my iPhone 5 about 2500ms. I would say that means for about 25% of the mobile population this function runs about an order of magnitude too slow for comfort... it will impact user experience, it could impact bounce rate, etc. This doesn't even include the ECDH part of the calculation. This is definitely the hardest question to answer with client-side hashing, or even simply "sever-relief" hashing where a portion of the overall hashing may optionally be pushed to the client, particularly during DDoS type events. How do you identify which clients are sufficiently powered to reasonably perform the hashing, or what kind of UI needs to be presented if you could be potentially locking up a browser for 5+ seconds while the hashing is running? Users are not well trained to expect logins to be slow -- a stall in the browser is almost always a reason to simply resubmit the form. It would be great if users associated their browser tab locking up, their fans spinning to full speed, and their battery power plummeting with "Whoohoo, this site is ROCKING a awesome work factor!" but in the real world we see that companies want hashing run on powerful CPUs server-side, with the capability to offline-upgrade hashes over time. The final nail in any client-side hashing approach is when the claims start to cross over to "server never sees the password". I don't see this as a valid argument any time the code to perform the hashing is being sent over the same trusted connection from the server itself. There are corner cases, for example if you are shipping compiled and signed code which is hashing client-side, or if you take special precautions with browser plugins to ensure you are running a specific build of the Javascript, but that simply doesn't apply to 99.99% of use cases, and so I personal dismiss those benefits as not likely to be achieved in the real-world. What we're left with is technically a sub-optimal user experience with additional trade-offs. So in conclusion, I am currently quite bearish on client-side hashing on the web in general. [1] - https://github.com/tonyg/js-scrypt https://github.com/tonyg/js-scrypt [2] - https://dl.dropboxusercontent.com/u/42286273/site/test_scrypt.html https://dl.dropboxusercontent.com/u/42286273/site/test_scryp...