There’s been a huge uptick in a type of low-effort hacking, where bad actors crack accounts of people who reuse passwords. They simply feed off of data from previous credential breaches.
Just last week, DraftKings disclosed that 68,000 accounts had been compromised in one such credential stuffing attack. But the site’s developers could easily have prevented it.
Prevented how? By checking user passwords against public databases of leaked credentials. Enforcing multi-factor authentication is also handy — if you can. In this week’s Secure Software Blogwatch, we urge dev teams to do more.
Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: Dodie’s sixth.
I’ll choose a mask to look like you
What’s the craic? Sergiu Gatlan reports — “DraftKings warns data of 68K people was exposed in account hacks”:
“Credential stuffing attacks are quickly growing”
Sports betting company DraftKings revealed [67,995] customers had their personal information exposed. … In credential stuffing attacks, automated tools are used to make a massive number of attempts … to sign into accounts using credentials … stolen from other online services. This tactic works exceptionally well against user accounts whose owners have reused the same login information.
…
The attack was conducted by a threat actor selling stolen accounts with deposit balances on an online marketplace for $10 to $35. The sales included instructions on how the buyers could … withdraw all of the money from hijacked DraftKings user accounts.
…
As the FBI warned recently, credential stuffing attacks are quickly growing in volume due to readily available automated tools and aggregated lists of leaked credentials. [DraftKings] is now advising customers never to use the same password for multiple online services, never share their credentials with third-party platforms [and to] turn on 2FA.
Sounds bad. How can I help? Duncan Riley drives the point home — “Personal information of 68,000 DraftKings users exposed in credential-stuffing attack”:
“Companies can reduce the risk of credential-stuffing”
Nasdaq-listed sports betting company DraftKings Inc. has revealed that nearly 68,000 customers had their personal information exposed in a credential-stuffing attack. … The attack method relies on the unfortunate fact that many users use the same password for multiple sites.
…
Though there [is] no evidence that login credentials were obtained from DraftKings, the bad actors were able to log into certain accounts [and] could have viewed the account holder’s name, address, phone number, email address, profile photo, information about prior transactions and the last four digits of payment cards.
…
The case highlights the risk of reusing passwords across multiple sites. However, there are ways companies can reduce the risk of credential-stuffing attacks. … Organizations, especially those that handle large amounts of sensitive information, must have up-to-date cybersecurity procedures.
What sort of “procedures” would those be? Checking for reused passwords, for starters. Here’s Troy Hunt — “Understanding Have I Been Pwned's Use of SHA-1 and k-Anonymity”:
“Baked into everything”
HIBP's [implements] a really cool k-anonymity model courtesy of the brains at Cloudflare … used by Mozilla, 1Password and a handful of other paying subscribers. It works beautifully; it's ridiculously fast, efficient and above all, anonymous.
…
[It] is best explained by walking through the process of how the API is queried. Let's take an example of someone signing up to a website with the … password P@ssw0rd. … This will pass many password complexity criteria (uppercase, lowercase, number, non-alphanumeric character, 8 chars long) but is clearly terrible. … The API then responds [it’s] been seen over 83k times
…
Pwned Passwords is now doing in excess of 2 billion queries a month and has an ongoing feed of new passwords directly from the FBI. [It] is baked into everything from browsers to password managers to identity theft services.
Speaking of SHA-1, you should stop using it for storing hashed passwords. Thomas Claburn tells us when — “How about right now? Right now is good”:
“SHA-1 remains widely available”
The US National Institute of Standards and Technology (NIST) says it's time to retire Secure Hash Algorithm-1 (SHA-1), a 27-year-old weak algorithm. … As soon as possible isn't necessarily all that soon: NIST says you should be rid of SHA-1 from your software and systems by December 31, 2030.
…
By the end of 2030, FIPS 180-5, the next revision of government's hash standard, will no longer include SHA-1 as a supported specification. … Hashes are not supposed to be reversible but simple message inputs like "password" can be pre-computed and put in lookup tables. … Despite its known weakness, SHA-1 has shown up in recent years propping up legacy applications and providing shoddy password storage.
…
SHA-1 remains widely available. NIST's Cryptographic Algorithm Validation Program, which validates cryptographic algorithms for vendors, includes 2,272 cryptographic modules … that still support SHA-1. … So companies incorporating any of these modules in their products should be looking for revised versions. … Modules still using SHA-1 after 2030 will be ineligible for purchase by the federal government.
The end of 2030? That’s eight years away! miga is shocked — shocked — to find the federal government working slowly:
That is the date after which purchase of new software with SHA-1 will be forbidden, which seems late given that it takes only two months on a GPU to find a signature collision with a chosen prefix. Sounds like the deprecation schedule is too slow and unsafe.
As is Lil Endian, who’s in the wrong order:
SHA-1 has been known to be broken since at least 2005! So NIST are saying that a 25 window to stop using it is okay?
Other things you can do include encouraging or even requiring 2FA/MFA. Here’s AKA:
[DraftKings] has two-factor authentication — it used to be optional before this hack (they and other books made it required soon after the hack). No idea why anyone wouldn’t enable it on an account with money in it.
What are the odds that’ll stop the problem? Ol Olsoc muses thuswise:
I wonder — Is Draftkings taking bets on this?
Meanwhile, a cloudy u/john_the_quain sees the silver lining:
Someone got an early present with being able to blame the hackers that stole his money that he absolutely did not lose by gambling!
And Finally:
Six years of Dodie’s holiday songs
You have been reading Secure Software Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites … so you don’t have to. Hate mail may be directed to @RiCHi or ssbw@richi.uk. Ask your doctor before reading. Your mileage may vary. Past performance is no guarantee of future results. Do not stare into laser with remaining eye. E&OE. 30.
Image sauce: Dan Dennis (via Unsplash; leveled and cropped)
Keep learning
- Find the best building blocks for your next app with RL's Spectra Assure Community, where you can quickly search the latest safe packages on npm, PyPI and RubyGems.
- Learn how you can go beyond the SBOM with deep visibility and new controls for the software you build or buy. Learn more in our Special Report — and take a deep dive with our white paper.
- Commercial software risk is under-addressed. Get key insights with our Special Report, download the related white paper — and see our related Webinar for more insights.
Explore RL's Spectra suite: Spectra Assure for software supply chain security, Spectra Detect for scalable file analysis, Spectra Analyze for malware analysis and threat hunting, and Spectra Intelligence for reputation data and intelligence.