It was pretty neat to read Troy's line there about sending emails out near the end, raise an eyebrow, tap over to my inbox and hear an immediate and satisfying ding. I highly recommend the HIBP service, hiding your e-mail from showing up in public searches (important for opsec), and donating whatever you can to Troy.
Truly essential service and I'd be happy to pay more. Even with good password discipline it's useful knowledge on your exposure.
This is a really good reason to be careful about what you log to log analytics platforms. I just recently implemented an ETL system that has the credentials (along with other stuff about the job) for data access passed into it from a PaaS framework. While I want to log the information, I don't want to log my DB connection strings! It's very easy to overlook such things and produce them as part of application logging/exhaust without realizing it, especially now that we have mass adoption of things like Splunk, Logg.ly, CloudFront, Cortana Analytics, Elmah.IO, LogEntries, Seq, and a dozen others.
> It's very easy to overlook such things and produce them as part of application logging/exhaust without realizing it
Very true. It is a constant battle between debuggability and not leaking credentials.
In Erlang for example, when processes crash they dump their state, their neighbours, links to other processes, and other such useful stuff. That's very helpful, however it means it could dump credentials as well.
I'm actually fixing an issue with this right now. My logging framework is capturing user passwords, so I've delayed the release one day while I blacklist certain known-sensitive information from the capture.
Alternatively use managed service accounts. You shouldn't even know or be able to expose the db connection credentials - let AD manage that for you. This is Windows specific advice and obviously doesn't count if your services don't support this (log a bug in the product if it doesn't).
Also Linux kernel logs. Kernel ASLR requires kernel addresses to be secret, yet dmesg is full of them sometimes and you usually ship those out over unencrypted syslog.
Completely agree. Here's another example: BitDefender (antivirus) passes your email and MD5 of your password in the hash when you want to go to your dashboard. When I contacted them more than 1 year ago about it, their "senior e-threat analyst" said it's nothing to worry about. Absolutely ridiculous.
What to do when the company is ignorant and continues to use something as stupid as that?
I think it's worth making a distinction between knowing what password is and knowing how it works. I just think it should be on the list of security features of a service just like airbags should be on the list of features of a car, and people should have some idea of what it is and why it's important to have.
Of course, any site can claim to have hashing but not actually do it or implement it terribly. The same is true for airbags, but for that we have regulations....
The preceding comment suggested that using a website without understanding authentication is like buying a car that has no airbags. That's unhinged. You know those "IQ tests" where they go "the foot is to the leg like the hand is to the..." type analogies? This person would fail hard.
I know the article explicitly and consistently says 'encryption' everywhere. I simply cannot fathom that they were encrypting instead of hashing. While I suppose it's possible that the SHA-1 versions were encrypted, I refuse to believe that the dropbox security team would transition from that to bcrypt 2-directional encryption over bcrypt 1-directional hashing. With that assumption I find it safe to say the tech journalist is being inaccurate.
> "it does not appear that the encryption protecting them has been cracked"
Please Techcrunch, you are making it sound like you are talking about actual encryption while you are really talking about hashing. From that sentence people would believe that it takes a single "crack" to get them all.
The magic of bcrypt (and hashing in general) is that probably some low-hanging fruits have been picked already while any non-trivial password remains secure.
And worse, when you actually need to talk about someone screwing up and encrypting passwords (see http://www.xkcd.com/1286/ ), this mis-education of your readers will have to be carefully undone first.
As a recent convert, I highly recommend using a password manager (Lastpass, Dashlane, 1Password, etc.).
For sites where I don't really care about security (present company included :), I use a passphrase, usually in the form of a mnemonic. As an example, the password I may choose for this site would be "Hack_G1bson_RedPill_KungFooey" Much easier to remember and it only makes sense to me. Also, for apps like Dropbox, you better be using multi-factor authentication.
I can't do this for every site because of their tyrannical password requirements. I wish they used overall password complexity as an entropy threshold instead of 1 lower, 1 upper, etc.
I've walked away from signup at sites where I'm mildly curious, and when I go to sign up - I have a 25 char random password-safe generated string rejected as a secure password due to stupidly enforced lowest-common-denominator rules. (Or worse still, rejected as "too long").
If Im feeling "community minded" that day, I might email their contact address and tell them why I didn't complete the signup process - if I'm in a stabby mood I'll more likely just lampoon them as morons on Twitter. doubt either action on my part makes any difference.
You should absolutely use a password manager and two factor auth whenever you can, but the problem is what to do as a service provider and/or employer if people won't use either of the things. A lot of people are pretty careless about their digital security and don't care for password managers or 2fa; and then of course they reuse passwords because nobody can be arsed to remember a different password for each service.
You could argue that if someone doesn't care for their digital security that's their problem, but we live in a time when one single careless employee can screw over 60 million people, as it was the case with Dropbox.
I use the 1Password Teams service, having converted from PasswordSafe, and it's excellent. Easily worth paying for. Syncing, browser integration, etc - saves a lot of pain.
The problem with that is you never know at signup whether this site is going to be "one you don't care about" 2 or 5 years later.
I had a "stupid" multiply re-used password exposed in a breach of PerlMonks (which I didn't really care about in 2007 or so) which I also used when signing up to check out yet another new social media site in 2008. A couple of years later my Twitter account was sending Acai berry spam to my friends...
(And even if new-site-de-jour doesn't turn out to be something you stick with, it's now got your name (or regular handle) with the risk of damaging your reputation when it gets exploited without you even knowing...)
I recently had a fight with password selection on the Azure portal.
They have some truly awful password rules, and I've ended up using something that isn't completely terrible but is much worse than normal, because I simply couldn't get it to accept anything decent.
Thinking about it, my account was added by a company using Azure, perhaps they are able to set the password restrictions for their sub-accounts...
Perhaps someone could come up with a service saying "sorry, this password has already been used somewhere on Internet, are you sure you want to proceed?". Sites would have to adopt it, a-la re-captcha
SSH keys all day. They can be troublesome for even an "expert" to look after, so I guess there's no hope for your average idiot. Still, logging in without using a password is the bomb
I definitely don't store my SSH keys on stranger computers. I however used passwords on my relatives or customers devices on numerous occasions. Don't pretend you never did, I'm not going to believe you.
Sure, I've used other machines in the past. I prefer not to though in most circumstances and assume that any account / password that I use on said machine is compromised from then on.
This was something I changed when I realized that a tax related government agency's machine I was using about 10 years ago man in the middled SSL connections to my online banking. Who knows what was logged and what the retention on that was? I don't have time or the inclination to ensure every relative's / customer's devices are secure, so I use my own or go without.
In theory yes, although with caveats. You'd need to match the degree of anti-tamper measures currently present in POS terminals to all consumer devices.
In practice, it would mean replacing most of the world's user-facing computer infrastructure.
You can get computers with smartcard readers from virtually every major manufacturer (except Apple, because Apple). The most frequent use case is government users who need to support the DOD Common Access Card (CAC) standard.
The card reader doesn't have to be any more tamper-resistant than the rest of the computer. On a public terminal, it should probably be built like an ATM's card slot (and the rest of the machine should be similarly armored), but on a personal computer it doesn't need to be any more robust than the keyboard a user would otherwise type passwords in with. The card-computer communication is all encrypted anyway, so even if it's built like any old USB peripheral it's still better than typing into a keyboard.
Yea this seems easy to set up. But, what about <insert generic website>? Like... HN.
I have an encrypted file with website|username|password on my laptop to allow for unique passwords across sites. But it's a pain, and definitely not something everyone will do.
We can certainly do without passwords for every stupid little website. Unless you're rightfully a central force in the user's life - say, their main bank - you really should have users log in through Google, or Facebook, or Twitter, or someone else who almost certainly can guard their passwords better than you can.
It's shameful that it's so much easier to find tutorials on how to store passwords "securely" (including several tutorials that tell you crazy insecure things, like storing with unsalted commodity hashes) than it is to find tutorials on how to integrate your brand new battling-fairies website game with OAuth for authentication.
Authy codes (as well as Google and Microsoft equivalents) can be the first factor, which would eliminate the need for passwords. Grandparent's question was about usage by groups and teams at the enterprise level, which Authy also supports.
1. Mandate that all publicly disclosed passwords are collected in a compiled set.
2. Require that any Internet service vendor check against this set on password change revisions, and against different portions of the file, as maintainable, on each authentication.
Known passwords are rejected when set, and mandate changes when detected on login.
Asking a 76 year old mostly-computer-illiterate pereson to come up with a never-been-used-before password simply doesn't work.
This also means mandating password safes on all consumer-grade OSes. Apple already does, Microsoft and Android. For Linux, you might be semi- on your own, though most distros offer several options.
I'd also like to see 2FA via a keyfob generator rather than contact token (e.g., phone, email).
Coming up with appropriate password for ordinary user's is hard enough right now.lets imagine you are not being sarcastic-for the sake of argument-, then I think it is almost impossible to create good enough password, yet rememberable.
Don't store passwords at all if you can avoid it. Then, bend over backwards to avoid it.
Do all login through OAuth or the related proprietary "login with" mechanisms Facebook and Twitter have. Offer your users a choice of mechanism, in the signup flow, and don't require that they first set up a password that they then replace with login-with-(whatever).
If you can't imagine what this looks like, open an incognito browser and go through the signup-for-an-account flow at stackoverflow.com. That should be what you're aiming for.
Well, first off you make this (USE UNIQUE PASSWORDS) part of orientation, and maybe have part of orientation involve rolling dice and using the diceware list.
Then, you reinforce that by using some sort of SSO setup/service (you can outsource this to someone like okta.com if necessary), so that all internal systems never have a place to set a password. (e.g., don't make people set up separate accounts with passwords on the corporate jira or bitbucket server)
Basically, not training people to reuse passwords internally can help them to not reuse their one internal password externally.
Another possibility is to simply buy a password manager subscription for every employee and have it as a perk. That's a per-employee overhead of $20-30/year.
Indeed, or any major password manager. I use lastpass, which will automatically generate (and even fill in the appropriate fields) long, random passwords. I'm sure the others have a similar option.
If two-factor authentication or single sign-on is not an option, should you force at least partly random passwords for employees to prevent password re-use?
In the past this would have been considered as bad practise, since nobody can remember that kind of passwords but nowadays it is pretty clear that everybody (in IT) is either using some password manager or reusing their passwords between systems.
(And to clarify, I'm not talking about end users of service like Dropbox, but people who are working with security sensitive stuff on the backend)
I really wish HIBH would actually send me the data related to my email. I currently have no way of know the current password except by going on to some shady website and downloading a dump. Why not provide the option to send it to the user's email address?
You have no way to know the password you set on sites you signed up with, except from pastes of breaches?
I don't think that's a problem Troy needs to fix...
I think he's chosen very smartly to explicitly and publicly _not_ know anything about the passwords, and only store email addresses. If you think 60mil Dropbox passwords sounds like a spectacular fail, imagine the headlines if an attacker got into HIBP and exfiltrated 1.3_billion_ passwords (or password hashes)! It's be the first "Unicorn credential breach" ;-)
So how does this work? Did the hacker go "Hey look, i managed to hack Dropbox, here are the data related because I trust you!" Or was it that HIBP managed to find where the data was?
> Some of the stolen passwords were encrypted with SHA-1, while 32 million were encrypted with bcrypt, Motherboard reports. The passwords were also secured with a salt, a random data string added to strengthen the encryption. Even though these passwords have now been dumped online, it does not appear that the encryption protecting them has been cracked.
Whenever I've seen passwords stored without a salt it's either because there is no salt or the salt is derived from the username. If it's the latter, it's only a matter of time till the specifics are figured out.
I'd be very surprised if there is a random salt for each of the SHA-1 passwords that's stored separately from the hashes themselves.
The report doesn't contain much details, but 2-factor auth might have helped.
What is also not apparent is whether the stolen credentials were utilized to pull off data from the accounts? Users might have had sensitive documents stored!
You would think Dropbox doesn't behave like a startup anymore...Proves again that simply passing the responsibilities to a "cloud" provider doesn't fix the security issues.
Well, the leak is from 2012. But unfortunately, startups are hardly unique in mishandling their passwords, there are plenty of large companies on http://plaintextoffenders.com/
I've been waiting for light to be shed on this incident for a long time, as I have known for years and with zero doubt that invented email addresses used only for Dropbox must have been stolen from Dropbox. I have said so, publicly, too, but I never heard Dropbox admit to a serious incident like this.
Dropbox admitted in 2012 that the emails were stolen. The new information coming to light now is that encrypted passwords were also leaked.
Exact phrasing from 2012 blog post:
>A stolen password was also used to access an employee Dropbox account containing a project document with user email addresses. We believe this improper access is what led to the spam. We’re sorry about this, and have put additional controls in place to help make sure it doesn’t happen again.
