How Dropbox securely stores your passwords
blogs.dropbox.com
blogs.dropbox.com
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.
Moreover, using pepper will make some (stupider) people do stuff like
hash( salt + hash( pepper + password ) )
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
[1] https://www.schneier.com/blog/archives/2011/04/schneiers_law...
In any case, if you pepper is exposed and you don't have a good pepper rotation scheme, you are no worse than if you started with no pepper at all.
Okay, but the suggestion was not to just concatenate everything but involved hashing parts before further concatenating and hashing them again. The length extension attack will still apply, you could for example use it on H(pepper || password) in H(salt || H(pepper || password)). Is this useful? Where would you get the length of and a hash for pepper || password from? I don't know but why would you risk that someone figures out how to do and abuse it if there are alternatives? And last but not least constructions like H1(H2(message)) or H1(message) || H2(message) may look innocent but they are not and they may weaken your system. See for example this Cryptography Stack Exchange question [2] or the answer by ircmaxell on this Stack Overflow question [3].
[1] https://en.wikipedia.org/wiki/Length_extension_attack
[2] http://crypto.stackexchange.com/questions/270/guarding-again...
[3] http://stackoverflow.com/questions/348109/is-double-hashing-...
Peppering has always meant, to me, doing something like this:
// Hashing
$preHash = base64_encode(
hash_hmac('sha512', $password, $_ENV['pepper'], true)
);
$storedHash = password_hash($preHash, PASSWORD_DEFAULT);
// Validation
$preHash = base64_encode(
hash_hmac('sha512', $password, $_ENV['pepper'], true)
);
if (password_verify($preHash, $storedHash)) {
// You're in!
}
I can't recall it off the top of my head, but Facebook has a similarly impressive system with more secret sauce involved for performance at scale. I believe what they do is the following:
1. Hash the password with MD5(password).
2. Generate a 20-byte (160-bit) random salt (this is well over the 64 bits you'd need to defend against birthday attack collisions).
3. Hash with hmac_sha1(hash, salt).
4. Send this value to a separate server for further operations (mitigates offline brute-forcing).
5. Hash in a secret key with hmac_256(hash, secret). Note this operation is on a separate server. The secret key might be colloquially termed a "pepper".
6. Hash with scrypt(hash, salt) to make local computation slower.
7. Shrink the final value with hmac_256(hash, salt) for efficient database storage.
If any Facebook engineers are around, please correct me if I've missed or misinterpreted any part of that.
People sometimes complain that migrating passwords is a pain, but if you wrap the older scheme with a newer hash* it kind of works out.
Today, I would consider argon2 which came out of PHC.
* you need to carefully study the security properties of the combined hash.
I kind of figured that, thanks for confirming :).
Personally I wouldn't consider Argon2 yet for production, but only because I'd like to see it run at scale for a few years. PHC or not, I'm hoping it becomes more battle-tested in production use.
That said, I'd fully respect any team for using Argon2 and have no personal qualms with it.
(and yes, the researchers made two different algorithms with the same name)
(I don't work there myself but I went to the talk.)
I wouldn't want anyone to read this and get the impression that "secret peppers" and multiple hashing rounds and HMAC were important components of a password storage system. They are not: they're things that message board nerds come up with.
If you want to be a step better than just storing passwords with bcrypt, your next step is to create an authentication service that runs on separate hardware with an "is this password valid" and "enroll this password" API and nothing else. The stuff people do instead of this is basically cosmetic.
Yep, I mostly agree. As I said elsewhere in the thread, I wouldn't really recommend this sequence to any company unless it were very large and had a mature ops team to handle it. There's a lot of diminishing returns here.
Good clarification.
With the caveat that you have to make sure you're hashing the entire password. Don't silently truncate.
I think this is a suboptimal approach. Can you tell me what the benefit of your layered approach is over simply adding to your KMS servers the APIs for validate(user, password) and change(user, oldpassword, newpassword)?
If your KMS service did password validation directly, you wouldn't need any of the layers in this architecture. HMAC would add nothing (it would be tautological, since anyone who could directly attack the hashes must have also owned up the KMS service). I still don't totally understand the MD5 step. You could just use scrypt and nothing else, and you could probably ratchet the work factor up because you wouldn't be billing the front end servers for those cycles.
I generally like, have recommended, and have built a few times the "software HSM" KMS approach you're describing here --- but only for "seal/unseal" and "sign/verify" APIs.
Yes, although I don't work for Facebook any more, that was and probably still is the case.
>who use back-end KMS services to do some (but not all) of the crypto.
In fact, the backend service does a tiny amount of the crypto.
>I think this is a suboptimal approach.
Of course you do, it's not like I've not argued with you before, Thomas. :-)
>Can you tell me what the benefit of your layered approach
...Facebook's layered approach...
>is over simply adding to your KMS servers the APIs for validate(user, password) and change(user, oldpassword, newpassword)?
If you want your hash to be ... hashed, rather than lodged in some questionable silicon, not putting a fat crypto load onto the backend avoids the "thundering herd" problem when some fraction of 1.7 billion people want to log in.
>If your KMS service did password validation directly, you wouldn't need any of the layers in this architecture.
Quite, and if everyone flew instead of drove, we wouldn't need cars with layers of bumpers, crumplezones, seatbelts and airbags; but it's merely shifting the problem for 1.7 billion people.
Have I mentioned "scale"? I should mention scale. Scale is a thing.
>HMAC would add nothing (it would be tautological, since anyone who could directly attack the hashes must have also owned up the KMS service).
Yes. Fucking huge KMS service. HUGE. Trumpiness levels of -HUGE- and eating lots of power and redundancy.
1.7 billion people. That's a lot. Like 0.01% of it is 170,000 people. All logging in together. All over the world.
>I still don't totally understand the MD5 step.
Yeah, but I'm not betting that Mark's/whomever's coding at the time was focused on the future of password authentication.
>You could just use scrypt and nothing else
Yes, but where's the fun in that?
>and you could probably ratchet the work factor up because you wouldn't be billing the front end servers for those cycles.
The frontend servers are approximately precisely where you want the cost/chokepoint. There's a metric fucktonne of them and they are closest to the request, so by definition they are scaled to the load.
>I generally like, have recommended, and have built a few times the "software HSM" KMS approach you're describing here --- but only for "seal/unseal" and "sign/verify" APIs.
Cool. What's your biggest deployment?
You comment early in the talk that the MD5 step is somehow helpful for password dumps. That was the bit I didn't follow. If it's there because that's how password hashing worked before your team got to it, that makes a lot more sense. But then: it's not a "layer" of the onion so much as a sheen of dirt that needs to be washed off the onion. :)
I get that your auth problem is huge. Yuge. So big you wouldn't believe it. I totally believe you. No, wait, I don't believe you, that's how big I know your authN problem to be: unbelievably huge.
But here's the thing: you're already scrypting passwords. We're not debating whether you can use expensive password hashes. You already use expensive password hashes. I'm saying: the model where the KMS does a small bit of the password hash step and defers the heavy lifting to front-end servers seems like a suboptimal way to structure this:
* You have to bill cycles from the front end to do it
* You can't change password hashing without updating all the front-end servers
* It's harder to track usage because it's spread across a zillion machines
* You're more constrained in how you scale it (for instance, if you wanted to double or triple the work factor) because whatever your new scheme is, it has to fit with the existing front-end resources.
I'm not saying "wow, it's dumb that you built it this way". I'm saying, if other people are reading this thread thinking about how to do it:
* DO split authentication out into its own service
* DON'T have that authentication service be "HMAC as a service" and then do scrypt on your front-end service
YOUR MOVE, ALEC MUFFETT. I keep going until you unfriend me on Facebook so I can't see you wincing about these posts.
† I've assessed Facebook-large variants of this, though.
I just spent 3 years living it for 50h/week. Hence why I am taking a vacation.
>If it's there because that's how password hashing worked before your team got to it, that makes a lot more sense.
That. It wasn't even me, it was done before I arrived, but it was done by a team of geeks with a tremendous nose for making the best of the database that they had available to them without pulling the old password-migration "log in with one password, parallel-encrypt with a new algorithm, and save the new hashes" - thing, because some of those billion people might never log in again for years. You would never stop migrating people.
I remember internal pasword algorithm migrations at Sun, at least there you could force the matter for 10,000..40,000 people.
But you can't force everyone to migrate at FB scale.
>But then: it's not a "layer" of the onion so much as a sheen of dirt that needs to be washed off the onion. :)
You can take that approach, but - again - when will you finish the task? Whereas wrapping one algorithm in the next is a finite task which is completable in a reasonable amount of time.
>I get that your
...Facebook's...
>auth problem is huge. Yuge. So big you wouldn't believe it. I totally believe you. No, wait, I don't believe you, that's how big I know your authN problem to be: unbelievably huge.
Well channeled. :-)
>But here's the thing: you're already scrypting passwords. We're not debating whether you can use expensive password hashes. You already use expensive password hashes. I'm saying: the model where the KMS does a small bit of the password hash step and defers the heavy lifting to front-end servers seems like a suboptimal way to structure this:
>* You have to bill cycles from the front end to do it
Yes. 0.1% of frontend cycles. <blank expression> And?
>* You can't change password hashing without updating all the front-end servers
...which happens three times a day, weekdays, and is moving to moreso.
>* It's harder to track usage because it's spread across a zillion machines
"Facebook has tools for that sort of thing":
http://conferences.oreilly.com/strata/stratany2012/public/sc...
...and to be honest it's not hard to do anyway.
>* You're more constrained in how you scale it (for instance, if you wanted to double or triple the work factor) because whatever your new scheme is, it has to fit with the existing front-end resources.
Yes. For a site with wildly heterogeneous architectures in front-end deployments, I can see how that might be a concern; but even AWS leads people to standardise on having approximately-the-same-kinds-of-hardware-doing-approximately-the-same-things.
>I'm not saying "wow, it's dumb that you
...Facebook...
>built it this way". I'm saying, if other people are reading this thread thinking about how to do it:
>* DO split authentication out into its own service
...or some component of it...
>* DON'T have that authentication service be "HMAC as a service" and then do scrypt on your front-end service
Why not?
>YOUR MOVE, ALEC MUFFETT. I keep going until you unfriend me on Facebook so I can't see you wincing about these posts.
Wince?
> I've assessed Facebook-large variants of this, though.
Did they buy it?
Responses: (when I say "your" let's just stipulate I mean Facebook)
* Your password validation overhead is .1% of current front end resources, but could be ratcheted up, and would be easier to ratchet up if they weren't shared by other things.
* I totally understand why you keep the old MD5 cruft around --- but would add that it's cruft that would be even less obvious if it lived behind an authentication server.
* I think it's safer, simpler, cleaner, probably easier to scale, and definitely easier to change authentication if it lives in its own service rather than being implemented (in part) on a generic application server. As usage shifts from HTML front-end to all API, you might even be able to keep app servers from even seeing passwords.
* By "assessed", I mean, worked on other people's systems at this scale.
So I guess I'd wrap up with a question: if you had this to do over again, from scratch, the way you wanted to, would you have app servers do a password hash and then entangle it somehow with an HMAC operation from a crypto service, or would you have the whole password hash done on the crypto service directly?
Putting the authentication service into a nice tidy centralised box does not actually achieve much, and may have architectural downsides.
Not the least of which is: if it's wholly in a service, then you have to authenticate the service; that's not such a big step from "if the hashed passwords are stored in a directory, then you have to authenticate the directory" of course - but if we were to equate the two systems because of the need to authenticate the {directory, service} then the service-based solution still has the downside of being a CPU hotspot and a potential single point of failure.
We're much better at distributing directories of data which is self-protected / needs no special treatment, than we are at building humongous scalable "secure" services with an enormous TCB and a physically enormous attack surface / footprint.
Yes. If I was doing this, sure, I would do this again. Curiously I am a big fan of password hashing rather than all-singing, all-dancing authentication services.
General notes: http://dropsafe.crypticide.com/muffett-passwords
I like password hashing too. That's all my password validating service would do.
Yes.
But, to look at the Facebook approach, what is the risk surface presented by the HMAC service?
Done properly in the FB approach the password is irreversibly hashed before it arrives at the HMAC component, and cheaply HMAC'ed and returned, where the onion of hashing is completed.
It's good to bidirectionally authenticate access to the HMAC service, but in terms of protocol it strikes me as less critical than in your scenario.
Either the HMAC is done properly (in which case the eventual hashes will verify for legitimate users) or - if someone inserts a "fake" hashing service - the HMAC'ed results will not validate, and a bunch of legitimate users will experience login failure.
( edit: there's a risk of exfiltrating the input to the service, but it's meant to be a shitload of work to achieve any evil with that input anyway, which also can be shorn of user-metadata and other clues thereby making it a bit less valuable )
Maybe I have missed something but to my mind this threat scenario fails (by dint of fake services, exfiltration, etc) in a "safe" manner.
=== Now === consider your "authentication service" approach.
Plaintext goes into... what?
The real service?
A fake service that returns "true" in all circumstances?
A MITM that exfiltrates the plaintext?
Where do you put the root of the trust chain to this service? In an SSL Certificate? Pinned? From which CA?
Simply: I feel that in centralised password authentication services there are a lot more potential shenanigans to defend against.
( ps/edit: and - I know you would not, but - don't get me started on "three strikes": http://www.crypticide.com/article/42 )
Seriously, though, it's a complete fallacy to think that more complicated password hashing schemes with lots of fancy steps are better. I was at the talk where this scheme was presented, and Alec Muffett himself said the only reason it was so complicated is because they had to layer stronger hashes on top of existing ones instead of revoking all outstanding session cookies (forcing every Facebook user in the world to re-authenticate).
Specifically, this means "wrapping" insecure hashes in more secure hashes and the addition of an encryption key stored in an HSM on a separate server.
Anyway, not trying to dismiss their efforts here -- they're good. But this is only half of the equation.
I certainly wouldn't rely on symmetric encryption alone to store passwords. If the password leaks, you expose all passwords in mere seconds. Plus you can see your user's plaintext passwords (since you have the key), which you should not be able to do. But as an extra measure symmetric encryption has already proven itself to be useful.
the only difference I do, is I perform the Sha512 hash client-side, so that the user's plain-text password isn't sent to my servers. Any thoughts on that?
FYI I also do recaptcha for signup+resetpw.
This is the unsafe mentality of "roll your own" and it's always a bad idea. There's a reason why we have to practically blindly follow the best practices; the attack vectors are so diverse we cannot predict them.
How would you handle 3rd party phishing schemes attempting to register users with weak passwords for example?
Ultimately, if you are writing A SaaS you have to roll your own at some point, but I agree it shouldn't include things like key derivation functions.
Maybe I'm dense, but I just don't see how enforcing password strength on both the client and server is making me safer from hackers.
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.
Use the time saved by not doing base 255 conversion to increase your iteration count.
> For ease of elucidation, in the figure and below we omit any mention of binary encoding (base64).
https://techcrunch.com/2011/06/20/dropbox-security-bug-made-...
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.
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)
If the DropBox passwords are leaked I am going to change my DropBox password whether it was hashed properly or not. The difference is that I won't have to change my password on dozens of other sites.
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?
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.
> 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.
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.
Wildly off-topic, but I just upload screenshots to twitter directly and let them figure out the hosting. Is your usage of dropbox for this simply a legacy of when twitter didn't have support for uploading images?
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.
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-b...
I'm not looking forward to having to talk people off that particular ledge for the next several months...
When breaking in, your end goal isn't the database server... it's the domain controller or the configuration management server.
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
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.
This part confused me. How can truncating to 72 bytes be a more severe reduction in entropy than generating a 64-byte hash?
And 512 bits is more than plenty.
Famous last words.
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.
Let A be a 72 character long string, and B be A + X. Regardless of what X is, when bcrypted the result for A and B will be the same.
Assuming C, where len(C) < 72, I don't know if it is possible at all to chose some value of Y such that:
D:= C+Y
Entropy(bcrypt(D))< Entropy(bcrypt(C))
- Pre-hashing makes this less likely.
- Encoding the pre-hashed value to prevent NUL bytes is important.
I don't get this point. Why is it harder to rotate pepper for a hash compared to an encryption key?
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.
Thats just nonsense. After a certain point, more security makes little sense. Would you advocate 5 trillion rounds of sha512 for each password?
In other words, 5 trillion rounds isn't overkill, it's impractical.
Using pepper prevents that from happening, and storing it separately from your database makes it much harder to get both.
I'm sorry, but how? You'd need data centers worth of effort for many years.
(I should say I'm not a professional security engineer so I'm probably wrong about everything and would appreciate corrections. )
Just want to tack on one footnote: 100 ms is based on a single CPU core. Most CPUs have 4-8 cores. So instead of 10 passwords a second you could argue 40-80 passwords a second is believable with concurrent operations (which all popular hash cracking software supports).
It is definitely viable to break a single user's hashed password no matter what the scheme or work factor. Strong hashing algorithms with high work factors just stop you breaking multiple user's passwords quickly (and gives you 1-3 days of delay). It is a stop gap, not impenetrable defence like some believe.
All technical people need to take a day and learn how to break password hashes. Not just the theory, but go download the software and actually do it.
And now that hashcat and oclhashcat have merged[1] and are open-source[2] it's never been easier to install hashcat and start cracking passwords!
[1] https://hashcat.net/forum/thread-5559.html [2] https://hashcat.net/forum/thread-4880.html
If you are not using salt, you are vulnerable to rainbow attacks within the same database.
No, not really. It truncates large passphrases, which is just … foolish.
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.
"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."
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.
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.).
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
There are actually two problems with bcrypt:
- It truncates after 72 characters
- It truncates after a NUL byte
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...
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.
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".
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.
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.
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-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.
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
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.
See discussion: https://news.ycombinator.com/item?id=12457067
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.
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.)
Setuid 0 means that whoever executes the tool, it always runs as user 0 (aka root). That is what enables them to continuously re-add their bullshit into accessibility settings.
So they aren't storing a password, they're installing a program that has permanent unlimited (barring System Integrity Protection on newer versions) access.
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".
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_protoco...
That said, the title could have been chosen more carefully.
Why can't they store my public key and authenticate me the way Github/Bitbucket/SSH all do?