35 ms·
How Dropbox securely stores your passwords
- davedx 10y agoIs this before, or after, Condoleezza Rice uploads them to the NSA?
- 0x0 10y agoIt's nice to store passwords securely, but it's also important to remember to, you know, actually verify them afterwards ;) https://techcrunch.com/2011/06/20/dropbox-security-bug-made-passwords-optional-for-four-hours/ https://techcrunch.com/2011/06/20/dropbox-security-bug-made-...
- eropple 10y agoThat is literally five years old at this point and is at best, a cheap shot. Let's be better.
- awt 10y agoThis "promise" model of security needs to end. I "promise" I'll encrypt your password, honest.
- vinylkey 10y agoForgive my ignorance, but are there any companies that provide proof that they encrypt users' passwords?
- awt 10y agoNo. This is impossible. The whole model is broken. A less broken model is the use of asymetric keys for authentication that doesn't require the service provider to "promise" they'll keep your password secret.
- Lucretiel 10y agoThis model, of course, is broken in its own way, in that if a user loses their private key, all their data is lost; there's possible recourse or password reset. It's also broken in that, if the company believes that a user's private key was compromised by a third party, they can't completely destroy that key until the user manually logs in and changes it.
- awt 10y agoWell, one could always leave one's private key with a trusted third party. So the public key model can accomodate those who are uncomfortable with the responsibility of keeping their private key secure. The password model however does not allow for allodial title to a secret.
- cypherpunks01 10y agoIsn't this the company that authenticated all production users without checking passwords for a few hours, a couple years back?
- Someone1234 10y agoI cannot see any obvious weaknesses in this scheme. It seems to address a known pain point in bcrypt (max length), implements a pepper in a secure way (which cannot inadvertently degrade security), and is otherwise doing things which are best practices (high work factor, per user salt, etc). I know peppers remain controversial (some people claim they're pointless, and make a good argument). But ultimately nothing Dropbox is doing with peppers in this article makes your password easier to break, only harder. I'd call this scheme 10/10.
- daddykotex 10y agoCan you explain a use case where wrong usage of a pepper actually degrade security? (just curious)
- nmc 10y agoAs mentioned by someone else in the thread [0], Dropbox is using pepper with encryption. Many (stupid) people will use it with hashing instead, which means they cannot rotate the pepper without resetting every user's password. Moreover, using pepper will make some (stupider) people do stuff like hash( salt + hash( pepper + password ) ) which is very likely to increase the attack surface. More broadly, since most secure hashing functions were not designed to be used pepper, it forces people to try to come up with their own ways of making it work. They should not: DO NOT roll your own crypto [1]. [0] https://news.ycombinator.com/item?id=12548597 https://news.ycombinator.com/item?id=12548597 [1] https://www.schneier.com/blog/archives/2011/04/schneiers_law.html https://www.schneier.com/blog/archives/2011/04/schneiers_law...
- cellularmitosis 10y agoAre they stupid people, or just uneducated? (Stupid implies they can never correct that behavior)
- singlow 10y agoThe uneducated but not stupid developer would not write her own password storage system.
- martinko 10y agoA bit of an overkill, no? Doesn't bcrypt suffice?
- hellofunk 10y agoyou can't have too much security, ever. especially not when loads of personal files and potential sensitive data are getting stored under said security.
- crpatino 10y agoSecurity is not free (as in beer); there exists some level of security that costs $X. If the value of the thing you are protecting behind that security is $Y, then for every X such that X > Y, your security level is a luxury. Furthermore, there is another number Z, that represents your total operational costs $Z. You could argue that for every X/Z > 0.1^T, where T is an arbitrary threashold, X is a significant cost to the organization and you cannot affort to take that luxury without risking bankrupcy. So, yeah, Drobox stores loads of personal files... but people with real secrets to keep should know not to rely on freemium services.
- tbronchain 10y agoThey have an history about stolen passwords... I guess they learnt from it. Also, I don't think any security would be overkill when you manage perosnal and professional data of millions of people!
- martinko 10y ago> Also, I don't think any security would be overkill Thats just nonsense. After a certain point, more security makes little sense. Would you advocate 5 trillion rounds of sha512 for each password?
- mseebach 10y agoIf 5 trillion rounds of sha512 is how many you can get in 100ms, then that's the right number. In other words, 5 trillion rounds isn't overkill, it's impractical.
- deleted 10y ago[deleted]
- sandGorgon 10y agoDoes anyone know what is a good practice to create a "vault" - the kind that is used for the Pepper in this case? I have heard of it being a separate, ip restricted server with daily changing ip address, etc. A simpler use case would be to store oauth2 tokens or some kind of PII
- shawabawa3 10y agoI've heard before of it just being stored in the codebase. Doesn't add much security but it does mean both the database server and at least 1 of the app servers or the codebase have to be breached
- koolba 10y ago> I've heard before of it just being stored in the codebase. Yuck! At the very least put it in an environment variable. Best case is loaded once at server boot from an HSM, kept only in memory, and rotated on a regular basis. Having it in the code, like all other config, is a terrible idea.
- sandGorgon 10y agoIf we don't have a hsm? Apparently,neither does Dropbox. So how do you engineer one ?
- morgante 10y agoUse something like Vault: https://www.vaultproject.io/ https://www.vaultproject.io/
- kijin 10y agoA note about combining SHA512 with bcrypt: Don't feed the raw binary output of SHA512 into bcrypt. Use the hexadecimal or base64-encoded form instead. (Dropbox probably does this already, since they mention base64 in passing.) bcrypt is known to choke on null bytes. Each SHA512 hash has a 25% chance of containing a null byte if you use the raw binary format. Using hex or base64, of course, decreases the amount of entropy that you can fit into bcrypt's 72-byte limit. But you can still fit 288 to 432 bits of entropy in that space, which is more than enough for the foreseeable future.
- benmanns 10y agoThanks for the reminder. You could encode with a "base255" algorithm that just excludes the null byte to retain more entropy within 72 bytes.
- cmiller1 10y agohttp://stromberg.dnsalias.org/svn/base255/trunk/ http://stromberg.dnsalias.org/svn/base255/trunk/
- arielb1 10y agoEven hex-encoding for 288 bits of entropy is plenty good enough.
- KMag 10y agoMuch faster than all of those multiplications that invertibly maps 64 bytes to 65 bytes without nulls: replace first null with 255. Every later null, replace with the index of the previous null. Make the final byte the index of the last null (or 255 if no nulls were replaced). In this way, you've replaced the nulls with a linked list of the locations where nulls used to be. To invert the transformation, just start at the final byte and walk the linked list backward until you hit a 255. (You'd never do the inversion in practice, but the existence of the inversion algorithm proves that no entropy was discarded.) Use the time saved by not doing base 255 conversion to increase your iteration count.
- 10y ago
- oDot 10y agoWhile this is very impressive, it feels like trying to solve the wrong problem. The real problem is getting rid of passwords (Persona, anyone?). Don't get me wrong, what's described there is super-important to secure the authentication of today, but what about a word for the authentication of tomorrow? There already are various solutions. Passwordless[0] is a familiar one for nodejs, and I recently bumped into the promising Portier[1], which is, according to its authors, a "spiritual successor to Mozilla Persona". [0] https://passwordless.net/ https://passwordless.net/ [1] https://portier.github.io/ https://portier.github.io/
- kraftman 10y agoSo I have to login to my email every time I want to login to something using passwordless? Doesn't this just move the problem and create a few others?
- onli 10y agoThat doesn't have to be as annoying as it sounds. If you use Gmail for example you can login via Google Sign-In, and later a system like that can support generic OpenID. Also, once logged in the site you logged into can save your session – it's not like you log into pages every time you use them. It kind of moves the problem, yes – instead of securing password on each and every site you only have to protect your email password. But that you do have to do already, so imho it only removed one problem.
- jacobsenscott 10y agoFor most companies offloading your password management onto an email provider is the right way to go. Suddenly, for free, you get MFA, a dedicated security team, and you'll never need to do one of those "Our password database has been hacked. Here's what we're doing..." press releases. You've eliminated one point of failure (your company), and haven't added any because you are already doing email based password resets. You can delete all your password related stories from trello or whatever. You eliminate all the bike shedding around how to store passwords. You've improved your initial user experience by an order of magnitude. Everyone dreads setting up yet another account password. Don't underestimate the joy a user feels when the signup form is just "click one of these buttons or fill in the email field". (The buttons are 'Connect with Facebook' and 'Connect with Twitter'). Users would much rather flip over to email (which is always logged in anyway) and click a link (especially on a mobile device) than enter a login/password.
- OskarS 10y agoIf we use the global pepper for hashing, we can’t easily rotate it. I don't get this point. Why is it harder to rotate pepper for a hash compared to an encryption key?
- figers 10y agoHow dropbox "NOW" securely stores your passwords
- allstate 10y agoReally surprised to see they are not using a HSM yet for the global pepper. What kind of physical controls put in place for global pepper currently?
- coherentpony 10y agoMay I ask a potentially dumb question? Why store my password at all?
- adevine 10y agoHow else are they supposed to verify your password when you attempt to log in?
- username3 10y agoEmail a link with token to log in.
- Skunkleton 10y agoThat is a good way to get endless token links spammed at your inbox...
- username3 10y agoGmail tokens tab.
- stephenr 10y agoSo all of a sudden the service in question's security is only as strong as the security of the client's email service? Yeah that sounds like a big nope to me. This 'idea' has been thrashed out a hundred times, even by supposed 'experts' like Egor Homakov who also says things like "You don't need 2FA, it's pointless and annoying for users".
- sirn 10y agoThere is something like Secure Remote Password (SRP)[1] where it is possible to verify a password without password being to transmitted to the server at all. The problem is, it is tricky to implement, a little bit old, and still vulnerable to bruteforce attack (Blizzard uses it, and IIRC their verifier database was leaked once, with g and N being published, so anyone could do dictionary attack on it. I believe Apple is also using it). [1]: https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...
- aomix 10y agoCool approach, you need to compromise two separate servers just to have a usable password database you could run tools against. A key compromise can be fixed quickly and a password compromise is useless without the key.
- dsl 10y agoOf the last 10 or so security engagements I have done, I can only recall one where I wasn't able to compromise _all_ servers. Once you get the first few, the incremental work to get everything is relatively small. When breaking in, your end goal isn't the database server... it's the domain controller or the configuration management server.
- ashitlerferad 10y agoWhy won't people stop using passwords? It is 2016!
- Jahava 10y agoThe blog mentions, "We’re considering argon2 for our next upgrade". I suppose they could do in-line upgrades: as users are signing in, the SHA512 is piped through the old pipeline for verification and through the new pipeline for migration. As far as I can tell, there's no way for them to swap bcrypt out for argon2 using just their cold store.
- artursapek 10y agorekt
- CiPHPerCoder 10y agoThis is a blog post from 2016 about how they're doing things now, someone mentioned a mistake they made (and fixed in hours) over five years ago. That doesn't deserve an invocation of the "rekt" meme at all. It's highly likely that their current success was based on learning from their previous mistakes. They should be applauded for improving rather than treated with snark for having ever fumbled.
- sctb 10y agoPlease don't do this here. We detached this subthread from https://news.ycombinator.com/item?id=12548662 https://news.ycombinator.com/item?id=12548662 and marked it off-topic.
- ppierald 10y agoI would be interested in the details of the storage mechanism of the global pepper. Is this in an HSM? For AWS customers, something like KMS? There are then huge operational and redundancy issues to think about. Failovers for your HSM. Handling the possibility that AWS might not be available or corrupt the key, other cases. These things are easy to whiteboard, but when the rubber hits the road and you need to think about all the operational edge cases, things get hard quick.
- dsacco 10y agoIt's not in an HSM. Dropbox states towards the end of the article that they're exploring HSM applications for pepper storage, which I think is a great idea. If I recall correctly, Facebook is also exploring (or has already implemented) an HSM for password database secret key storage. You raise good points though. This system is significantly safer than best practices (bcrypt(password, 10)), but it has significantly more overhead. There's also diminishing returns here. For a company of Dropbox's size - sure, invest in this. For a company that came out of YC S16, no, don't bother. Just properly bcrypt/PBKDF2/scrypt/argon2 the thing and revisit much later. I love it, but I would not recommend this system to my clients for password storage unless they had a very mature operations/reliability team.
- phonon 10y agoUmmm.. "Going forward, we’re considering storing the global pepper in a hardware security module (HSM). At our scale, this is an undertaking with considerable complexity, but would significantly reduce the chances of a pepper compromise."
- aRationalMoose 10y agoNow if only their customer service had been 'quietly' improved over the years.
- CiPHPerCoder 10y agoTheir solution is very similar to the mode prescribed by [1] and implemented in [2]. There are actually two problems with bcrypt: - It truncates after 72 characters - It truncates after a NUL byte If anyone is dead set on following Dropbox's example, make sure you aren't passing raw binary to bcrypt. You're playing with fire. Additionally, if you're going to use AES-256, don't implement it yourself. Use a well tested library that either uses AEAD or an Encrypt then MAC construction. [1]: https://paragonie.com/blog/2016/02/how-safely-store-password-in-2016#why-bcrypt https://paragonie.com/blog/2016/02/how-safely-store-password... [2]: https://github.com/paragonie/password_lock https://github.com/paragonie/password_lock
- arielb1 10y agonitpick: encrypt-then-MAC is an AEAD construction.
- CiPHPerCoder 10y agoNitpick to counter your nitpick: Not necessarily. It's an AE construction, but not necessarily an AEAD construction. You can have IND-CCA3 security without additional data. The converse is also not necessarily true (i.e. an AEAD scheme could be based on MAC-then-Encrypt and IIRC there are some that are built that way), but that's a less useful counterpoint. The recommended AEAD constructions (AES-GCM and ChaCha20-Poly1305) are EtM.
- warbiscuit 10y agoNot sure I understand the purpose of a MAC in this case. What benefit does it provide to hash storage? If the attacker has write access to your database to tamper with the hash, they will mostly likely also be able to sign up as a user, and clone that (properly signed + encrypted) hash over to whichever account they want to log into. When cracking the hash, they'll just ignore the MAC.
- red_admiral 10y agoHere's how facebook does it: http://chunk.io/f/72f9c680ac2a4777b6dbf33c532e1d3c.jpg http://chunk.io/f/72f9c680ac2a4777b6dbf33c532e1d3c.jpg (Alec Moffat talking at RealWorldCrypto) Seems like the combination of strong hash + encryption on a HSM is the way to go these days. Dropbox's scheme looks good to me.
- deleted 10y ago[deleted]
- danjoc 10y agoDespite all this, at the end of the day, the password arrives over SSL just as the user typed it in, in plaintext. This is the point where a hacker or government is going to attack. I used to think client side hashing was an answer, but you still need a salt, and even hashed salted passwords are all mental masturbation if the user uses a password like 12345. I'm now at a place where I think the most effective approach is to require users have a password manager. The password has to be impossible to remember and guaranteed unique from any other password the user might have. This could be achieved by not allowing the user to choose their password, but have one randomly generated for them. "Thanks for signing up. Your password is: aix<osh~isheg4aeve%e9oo(B$eexu" Then users can use whatever password management scheme they want on the client side. It can be as simple as a notepad for many of them. What Dropbox is doing is still good. It helps to prevent an insider from getting access to passwords and abusing the system. It's just the core problem here is password reuse and weak passwords. Passwords become much less valuable if they are guaranteed only to work in a single context and impossible to crack when bcrypted.
- joepie91_ 10y agoOne concern I have here, is that people are going to perceive this post as "this is what you should do and it's easy!", because the post doesn't really address the complexities of implementing this kind of thing. As a result, we're probably going to have a bunch more issues like this one: http://blog.ircmaxell.com/2015/03/security-issue-combining-bcrypt-with.html http://blog.ircmaxell.com/2015/03/security-issue-combining-b... I'm not looking forward to having to talk people off that particular ledge for the next several months...
- Freaky 10y ago> Some implementations of bcrypt truncate the input to 72 bytes, which reduces the entropy of the passwords. Other implementations don’t truncate the input and are therefore vulnerable to DoS attacks because they allow the input of arbitrarily long passwords. Huh? BCrypt works by stuffing the password into a 72 byte Blowfish key and using it to recursively encrypt a 24 byte payload. Either it's truncating, or it's pre-hashing the password to fit much like they are. The link they use to justify it is funny: http://arstechnica.com/security/2013/09/long-passwords-are-good-but-too-much-length-can-be-bad-for-security/ http://arstechnica.com/security/2013/09/long-passwords-are-g... That's just a naive PBKDF2 implementation that's pointlessly reinitializing the HMAC context each iteration instead of just doing it once at the start. The difference between storing a 1 byte and a 1MB password with PBKDF2 should be on the order of a couple of milliseconds.
- arielb1 10y agoHaving the SHA-512 hash at the beginning simplifies the implementation because the "security" code only needs to handle 64-byte random strings (which are truncated to 54-byte strings for `bcrypt`, but still...). That removes all sorts of stupid edge cases that come with variable-length strings.
- Freaky 10y ago> Having the SHA-512 hash at the beginning simplifies the implementation The hash is there to ensure very long passwords contribute entropy to the final hash instead of being truncated. It also ensures the entropy is evenly distributed - every bit of the password affects every bit of the hash. > the "security" code only needs to handle 64-byte random strings You can't feed any typical BCrypt implementation a raw SHA-512 hash because it's not binary safe - it truncates at the first NULL byte. Well, you can, and it'll appear to work, but it'll be laughably easy to break. It's a pretty stupid sharp edge IMO. > which are truncated to 54-byte strings for `bcrypt` 72 bytes, because that's the size of the key array. 56 bytes is just where extra entropy helps less, because the last 16 bytes don't affect every bit of the output. > That removes all sorts of stupid edge cases that come with variable-length strings. It's just treated as a circular buffer. And what are we doing here, implementing our own version of BCrypt? Yeah, that certainly simplifies things :P
- evunveot 10y ago> Some implementations of bcrypt truncate the input to 72 bytes, which reduces the entropy of the passwords.... By applying [SHA512], we can quickly convert really long passwords into a fixed length 512 bit value, solving [that problem]. This part confused me. How can truncating to 72 bytes be a more severe reduction in entropy than generating a 64-byte hash?
- microcolonel 10y agoI think they're talking about entropy per bit. If they hash to 64 bytes, they integrate all of the entropy of the password, if they truncate to 72 bytes, they throw away all entropy past 72 bytes. This could be a huge problem if you're one of those people who uses a common prefix with a suffix as their password pattern for passwords they need to remember.
- Dylan16807 10y agoEspecially if your password has a lot of words, you have a very low entropy per byte. It's not the worst thing in the world at 72 bytes, but if you were choosing between a 16 byte hash of a sentence and an 18 byte truncation, the hash is going to have vastly more entropy. And 512 bits is more than plenty.
- spronkey 10y ago> And 512 bits is more than plenty. Famous last words.
- Dylan16807 10y ago"A typical supernova releases something like 1051 ergs. (About a hundred times as much energy would be released in the form of neutrinos, but let them go for now.) If all of this energy could be channeled into a single orgy of computation, a 219-bit counter could be cycled through all of its states." You're not getting through 512 bits of entropy unless your cryptographic methods are severely broken, so broken that having more bits would not meaningfully help.
- deleted 10y ago[deleted]
- cperciva 10y agoWe considered using scrypt, but we had more experience using bcrypt. Ok, fair enough... The debate over which algorithm is better is still open, and most security experts agree that scrypt and bcrypt provide similar protections. ... wait, what?
- tptacek 10y agoThey're badly expressing the idea that there may be only marginal benefits to optimizing the genus of password hashes used, so long as you're using a serious construction designed for storing (or generating keys from) passwords. The debate over whether scrypt is better than bcrypt is not really still open. The debate over whether the difference matters that much in practice might be. For what it's worth: for new systems, I use scrypt. But if someone asked, and they didn't have a very specialized application, I'd tell them that switching to scrypt from bcrypt, or even PBKDF2, would be a waste of money.
- CiPHPerCoder 10y agoTeach the controversy! Even if there isn't one. > But if someone asked, and they didn't have a very specialized application, I'd tell them that switching to scrypt from bcrypt, or even PBKDF2, would be a waste of money. Argon2/scrypt/bcrypt/PBKDF2 are fine. I think PBKDF2 is the worst choice, but is still acceptable. The real problem is the prevalence of md5($password) e.g. in software like Piwik.
- cperciva 10y agoRight, if they had stopped at "we used bcrypt because we're familiar with it and we think it's good enough for our purposes", I wouldn't have said anything. But the second sentence, claiming that there's an open debate about which provides more protection...
- tptacek 10y agoYeah, sorry, I should have led with "I agree with you". No part of this post inspired confidence with me. I use Dropbox to store and share screenshots on Twitter, and try not to use it for anything else.
- borplk 10y agoAs someone who exclusively uses a password manager with random unique passwords for each service it always amuses me to see posts like this. Years ago I relieved myself from the stress by using a password manager. Now for all I care they could be storing it in plaintext and it wouldn't make a damn difference to me. Problem solved.
- Kratisto 10y agoJust curious which one do you use?
- shaunparker 10y agoI use 1Password on OSX and iOS, it's worked great.
- FabHK 10y agoI (not OP) use pwsafe on macOS and iOS, a port of Password Safe [1] designed by Bruce Schneier. It syncs the encrypted blob to iCloud, so I can pull up passwords on the iPhone if necessary. It is fairly simple, not much browser/OS integration - you just open the app, choose a safe/blob, enter the master password, and can then browse/edit your list of passwords, and in particular copy a password. Simple, not too much functionality - not too much that can go wrong, I hope. (Often it has been the browser integration that lead to exploits in LastPass/1Pass, if I'm not mistaken) [1] https://www.pwsafe.org/relatedprojects.shtml https://www.pwsafe.org/relatedprojects.shtml
- borplk 10y agoSorry I don't reveal that.
- csharp 10y agoIt would still make a significant difference since someone could still compromise your Dropbox account... Having a password manager doesn't all of the sudden make all of your passwords secure on all of your different accounts.
- 10y ago
- tadelle 10y agoWhat is wrong with bcrypt with cost 13. It makes 8194 cycles on CPU...
- eddd 10y agotoo little, too late. Once you loose trust, you never gain it again.
- mtgx 10y agoSo when is Dropbox going to allow users to encrypt files client-side before getting synced to its servers? It should be relatively trivial from both a technical point of view and a UX one.
- wahsd 10y agoSilly question, but is that nested illustration an accurate representation?
- Dowwie 10y agoI wonder why Dropbox didn't mention its robust support for 2nd factor authentication?
- nodesocket 10y agoSo just to reiterate, taking the sha256 of the password before running bcrypt on it is recommended? Funny, this is the first I've heard of this. You'd think bcrypt would have just implemented the sha256 step into the algorithm?
- faragon 10y agoFrom the diagram, Dropbox stores no passwords: it stores an encrypted hash (hasing in two steps, SHA512 and then "bcrypt") of the password. I.e. stored = AES256(bcrypt(SHA512(password), per_user_salt, 10), global_key). I would like to know if "salted-bcrypt"+SHA512 hashing is really safer than using just SHA512 (e.g. because of the risk of making locating hash collisions easier, etc.).
- cstrat 10y agoI posted a separate comment, but will post here again... Dropbox do store one password AFAIK. It appears that they store OSX users administrator password... I am keen to see if they address this somewhere. See discussion: https://news.ycombinator.com/item?id=12457067 https://news.ycombinator.com/item?id=12457067
- angry_octet 10y agoNo, they use the admin access they obtain from you to modify the system so they can obtain admin access again in the future. They do not ever have your admin password.
- cstrat 10y agoI am wondering how they store OSX users administrator password, since it isn't being hashed - they actually store the password somewhere... it would be nice if that were addressed somewhere. See discussion: https://news.ycombinator.com/item?id=12457067 https://news.ycombinator.com/item?id=12457067
- gruez 10y agoI thought they created a setuid executable on first run (when they asked for your password), and then use that later?
- cstrat 10y agoAdmittedly I don't know what that is and I don't know a lot about how applications on OSX get permissions. From reading that thread I posted I was under the impression that Dropbox stored the password because it was able to reinstate itself as an accessibility service as many times as it liked without having to ask for the admin password. From reading, that wasn't supposed to be allowed. The only way that could work would be if Dropbox kept your password on file. In effect meaning that the dialogue you entered your admin password for wasn't a system modal - but rather a dropbox modal imitating the system one.
- danieldk 10y agoI was under the impression that Dropbox stored the password because it was able to reinstate itself as an accessibility service as many times as it liked without having to ask for the admin password That is not necessary. A SUID binary owned by root runs with root's privileges. So, they only need the administrator's password once to install the SUID binaries. Afterwards, they have their own 'backdoor' to reinstate the accessibility settings, without needing an administrator password. So, when they deny storing your password, it's probably true, they don't need it. (If you are not convinced, write a small C program that executes a shell, compile it, make root the owner, set the SUID bit. You can be in a root shell without ever typing a password. This is why it is a good practice to have as few root-owned SUID binaries as possible.)
- yladiz 10y agoRealistically, how much better is this than the standard bcrypt recommendation? I don't mean for a company the size of Dropbox/Facebook/etc., I mean in general, will this really be much more useful than just using bcrypt? Using an encryption key means that if the database is compromised, as long as the OS isn't (or wherever the key is being stored), the passwords are encrypted in a way that's effectively impossible to decrypt, which is nice. However, are they sure that hashing the password first before hashing it in bcrypt won't cause issues? Unless Dropbox employs or contracted someone to verify that this is okay (not an engineer, a mathematician/cryptographer who can understand the math behind the algorithms) I'd be hesitant about it. Same goes for other companies that do some complex sequences of hashing e.g. Facebook. Implementing the idea is engineering related, but verifying it is not, and I don't trust engineers (including myself) to verify that a specific algorithm or sequence of algorithms is valid.
- jgalt212 10y agopepper = sha256(global_randnum + user_start_dt + username + global_randnum) the above creates a per user pepper, and largely obviates the need for pepper rotation. if only password db is stolen, all users are impervious to dictionary style attacks. if only codebase is stolen, then they only know how to calculate each pepper per user. if both are stolen, you are in no worse shape than just using a salted bcbrypt, scrypt, or PBKDF2.
- ashitlerferad 10y agoIn 2016, shouldn't we be using public/private key pairs instead of passwords?
- lighthazard 10y agoThe problem is, in my opinion, that the average person will have no concept of how to manage a public/private key setup.
- TempleOS 10y agoGod is perfectly just. God says... demonstrates Carmelo's auditioning jackknifing Atlantis railed tropospheres annual's Kane grotesque redcap's proms galvanic hijackers awareness's tornado's storks announces probabilistic contracting sentinel's rotunda's deader sahib onto helpings approbations forecasters talker jeweling regent inputted