Free Download Gmail Password Dump v6. Other editions: Google Password Decryptor. License type Freeware 1. Author's homepage Visit the author's site. Date added 16 Aug Downloads 7, File size 4. Supported languages English. Version history. There were lots of well-intentioned suggestions which wouldn't fly. For example, Dropbox and OneDrive aren't intended for sharing files with a large audience and they'll pull your ability to do so if you try believe me.
Hosting models which require me to administer a server are also out as that's a bunch of other responsibility I'm unwilling to take on. Lots of people pointed to file hosting models where the storage was cheap but then the bandwidth stung so those were out too.
Backblaze's B2 was the most cost effective but at 2c a GB for downloads, I could easily see myself paying north of a thousand dollars over time. Amazon has got a neat Requestor Pays Feature but as soon as there's a cost - any cost - there's a barrier to entry. In fact, both this model and torrenting it were out because they make access to data harder; many organisations block torrents for obvious reasons and I know, for example, that either of these options would have posed insurmountable hurdles at my previous employment.
Actually, I probably would have ended up just paying for it myself due to the procurement challenges of even a single-digit dollar amount, but let's not get me started on that! Edit: Based on popular demand and a very well-articulated comment below , I've now added torrent links to the Pwned Passwords page as well. After that tweet, I got several offers of support which was awesome given it wasn't even clear what I was doing! One of those offers came from Cloudflare who I've written about many times before.
I'm a big supporter of what they do for all the sorts of reasons mentioned in those posts, plus their offer of support would mean the data would be aggressively cached in their edge nodes around the world.
What this means over and above simple hosting of the files itself is that downloads should be super fast for everyone because it's always being served from somewhere very close to them. The source file actually sits in Azure blob storage but regardless of how many times you guys download it, I'll only see a few requests a month at most. So big thanks to Cloudflare for not just making this possible in the first place, but for making it a better experience for everyone.
Sometimes passwords are personally identifiable. Either they contain personal info such as kids' names and birthdays or they can even be email addresses. One of the most common password hints in the Adobe data breach remember, they leaked hints in clear text , was "email" so you see the challenge here.
Further to that, if I did provide all the passwords in clear text fashion then it opens up the risk of them being used as a source to potentially brute force accounts. Yes, some people will be able to sniff out the sources of a large number of them in plain text if they really want to, but as with my views on protecting data breaches themselves, I don't want to be the channel by which this data is spread further in a way that can do harm.
I'm hashing them out of "an abundance of caution" and besides, for the use cases I'm going to talk about shortly, they don't need to be in plain text format anyway. Each of the million passwords is being provided as a SHA1 hash. What this means is that anyone using this data can take a plain text password from their end for example during registration, password change or at login , hash it with SHA1 and see if it's previously been leaked. It doesn't matter that SHA1 is a fast algorithm unsuitable for storing your customers' passwords with because that's not what we're doing here, it's simply about ensuring the source passwords are not immediately visible.
If you're comparing these to hashes on your end, make sure you either generate your hashes in uppercase or do a case insensitive comparison. Let's go through a few different use cases of how I'm hoping this data can be employed to do good things. At the point of registration, the user-provided password can be checked against the Pwned Passwords list. If a match is found, there are 2 likely explanations for what's happened:.
Both scenarios ultimately mean the same thing - the password has previously been used, exposed and is circulating amongst nefarious parties with criminal intent. Let's go back to NIST's advice for a moment in terms of how to handle this:. This is one possible path to take in that you simply reject the registration and ask the user to create another password. Per NIST's guidance though, do explain why the password has been rejected:.
This has a usability impact. From a purely "secure all the things" standpoint, you should absolutely take the above approach but there will inevitably be organisations that are reluctant to potentially lose the registration as a result of pushing back.
I also suggest having an easily accessible link to explain why the password has been rejected. You and I know what a data breach is but it's a foreign world to many other people so some language the masses can understand including why it's in their own best interests is highly recommended. A middle ground would be to recommend the user create a new password without necessarily enforcing this action.
The obvious risk is that the user clicks through the warning and proceeds with using a compromised password, but at least you've given them the opportunity to improve their security profile. There should not be a "one size fits all" approach here. Consider the risk in the context of what it is you're protecting and whilst that means that yes, there are cases where you certainly shouldn't allow the passwords, there are also cases where the damage would be much less and some more leeway might be granted.
Password change is important as it obviously presents another opportunity for users to make good or bad decisions. But it's a little different to registration for a couple of reasons. One reason is that it presents an opportunity to do the following:.
Here you can do some social good; we know how much passwords are reused and the reality of it is that if they've been using that password on one service, they've probably been using it on others too.
Giving people a heads up that even an outgoing password was a poor choice may well help save them from grief on a totally unrelated website. Clearly, the new password should also be checked against the list and as per the previous use case at registration, you could either block a Pwned Password entirely or ask the user if they're sure they want to proceed. However, in this use case I'd be more inclined to err towards blocking it simply because by now, the user is already a customer.
The argument of "let's not do anything to jeopardise signups" is no longer valid and whilst I'd be hesitant to say "always block Pwned Passwords at change", I'd be more inclined to do it here than anywhere else. Many systems will already have large databases of users. Many of them have made poor password choices stretching all the way back to registration, an event that potentially occurred many years ago.
Whilst that password remains in use, anyone using it faces a heightened risk of account takeover which means doing something like this makes a lot of sense:. I suggest being very clear that there has not been a security incident on the site they're logging into and that the password was exposed via a totally unrelated site. You wouldn't need to do this every single time someone logs in, just the first time since implementing the feature after which you could flag the account as checked and not do so again.
You'd definitely want to make sure this is an expeditious process too; million records in a poorly indexed database with many people simultaneously logging on wouldn't make for a happy user experience! Troy says he downloaded the archive from the Mega file sharing. Several informants promptly sent him a link to the file, but soon the archive was removed from the hosting. This archive contained more than 12, files with a total size of more than 87 GB. A link to the archive was published on one of the hacker forums, along with a screenshot confirming the contents of the archive.
Here is the complete list of files. You can see in the screenshot that the root folder is Collection 1. From the list of files, you can get some idea about the sources of information itotal.
It is too early to talk about how reliable the information from the new database is. However, Troy Hunt found his email address and password there, which he used many years ago. However, what I can say is that my own personal data is in there and it's accurate; right email address and a password I used many years ago.
0コメント