Breached accounts have been raining down like confetti lately.
There have been hundreds of millions of credentials clawed out of sites and listed for sale on the dark web in recent months, from the MySpace mega-breach to LinkedIn, Tumblr, and more.
Maybe you practice good security hygiene. Your passwords are difficult to guess, and you never, ever reuse them on different sites.
But even that’s not enough to save us every time.
Some sites force us into making stupid-short passwords, and, to add insult to injured password entropy, they won’t let us use special characters.
Now, there’s a tool to comb through that enormous cache to sniff out reused passwords.
It’s called Shard, and it comes to us (or is inflicted upon us, depending on who does what with this command-line tool) courtesy of creator Philip O’Keefe.
O’Keefe told Ars Technica that Shard is designed to let people test whether a password they use for one site is also in use on Facebook, LinkedIn, Reddit, Twitter, or Instagram.
O’Keefe developed the tool after he himself found that one of his randomly generated, 8-character passwords was among more than 177 million LinkedIn passwords leaked in May.
Randomly generated it well might have been, but it was also regrettably and thoroughly reused, he told Ars:
I used that password as a general password for many services. It was a pain to remember which sites it was shared and to change them all. I use a password manager now.
Ouch.
If he’d asked us, we’d have told him why password reuse is such a bad idea.
We know that cybercrooks use breached credentials to see if they work on a variety of third-party sites, be it Facebook, Netflix or many others – including online banking sites.
That, in fact, is why both Facebook and Netflix prowl the internet looking for your username/password combos to show up in troves of leaked credentials.
If they do find customer credentials that match breached logins, they force users to change those reused passwords.
Be that as it may, O’Keefe’s tool is designed to do good, as in, helping end users to find out where else their passwords have been used.
But oh, it could do so much bad. As Ars’ Dan Goodin notes, you can see how easily it could be turned into a legitimate-credential sniffer by crooks. As it is, the tool will check an unlimited number of leaked credentials to see if they’re used on other sites.
For example, it would be a cinch to tweak Shard’s code to have it check for credentials that might work to log into financial sites, such as online banking.
With a bit more tweaking, the tool could be programmed to swap in leet speak, or to come up with variations of passwords that users increment in easily guessable ways: say, “p@$$w0rd11” on one site and “p@$$w0rd22” on another, to borrow Goodin’s example.
It could well be that crooks already have tools that automatically try the locks on sites, using botnets, and inserting all the keys that have turned up in data breaches, one after another, until they find a fit.
At any rate, maybe it’s not such a good idea to enter your passwords into some tool.
To quote Ars reader Lyme:
I ran all my passwords through the tool, and none of them … ?were? in it.. oh snap.
Another Ars reader, lewax00, noted that we have other tools to check whether our passwords are in the cache of stolen logins. One such is have I been pwned.
The nice thing about that look-up list? You don’t have to enter your precious passwords. Rather, you enter your account name/email.
Oh, snap, indeed!
Anonymous
“Some sites force us into making stupid-short passwords, and, to add insult to injured password entropy, they won’t let us use special characters.”
I always wonder why so many sites do this. Best practice suggests passwords should be salted and hashed, so regardless of their content they’ll arrive at the database as a fixed length, sanitized string. Do these sites have a really poorly-written backend which genuinely can’t handle anything beyond alphanumerics? Or is it a case of inexperienced developers simply copying the concept from other sites without considering why they (don’t) need to limit password complexity?
Bob Gustin
“Or is it a case of inexperienced developers simply copying the concept from other sites without considering..” – bingo!
Theodore
Thanks to the likes of boot strap, and the other ‘point & click’ application development environments. These environments only give you enough to make things works, but will not hand you everything so the environment developer can limit their legal liabilities.
Prebuilt CMS packages are a perfect example of this. No coding required, just download a plugin, then rely on someone else for security.
Bryan
Duck may follow up with a better-researched and comprehensive answer, but all of the above, and most of it boils down to education. Widespread ignorance of best practice–and ignorance of security principles in general–contribute well as limited budget contribute to under-engineered backends.
Few writing the paychecks understand the risk, and therefore most easily choose to hire inexperienced developers with lower salaries who don’t know or can’t produce what the site needs. Or similarly, a deadline could preclude proper testing with the same factors exacerbating the issue. Also, “if it ain’t broke, don’t fix it” prevails when budgetary requests come around, so that nine-year-old application written by a now-defunct company will be just fine.
It’s frustrating when large companies who should know better…still evidently don’t.
Laurence Marks
No, it’s arrogant but ignorant developers who think they know everything about security but don’t. I could tell you stories about my bank or private Medicare exchange but not in this venue.
Randall King
Seems like a good idea, but how does an average person use this? “Build it yourself using sbt, set assembly”. Yeah, right.
“Adding a new module is easy.” Yeah, if you’re a programmer.