The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →In a 2016 controlled experiment, security company Bitglass planted phished Google Apps credentials tied to a fictitious bank customer and tracked what happened. SecurityWeek reported that the credentials and fake bank portal drew more than 1,400 visits, and that some people who accessed the Google Drive account tried the same password on the bank account. The test illustrates how stolen credentials can be reused; it does not measure how often real bank accounts are compromised.
How Bitglass set up the experiment
SecurityWeek reported on February 18, 2016, that Bitglass’s Project Cumulus was its second annual “Where’s Your Data” experiment. Bitglass created a fictitious employee identity for a fictitious retail bank, set up a functional bank portal and a Google Drive account, then placed phished Google Apps credentials on the Dark Web and monitored activity. The bank identity and portal were not real customer accounts.
The setup let Bitglass observe whether people who obtained access to the cloud account would look for other accounts and try the leaked password elsewhere. It was a controlled tracking study, not a survey of banks, a test of real customers’ accounts, or a comparison of authentication products.
What happened after the credentials were exposed?
According to SecurityWeek’s account of Bitglass’s findings, the researchers recorded five attempts to log in to the bank portal and three to Google Drive within 24 hours. Files were downloaded within 48 hours. Over the following month, the account was viewed hundreds of times, and the report said many hackers who accessed the Drive also accessed the victim’s other online accounts.
#1 Best Overall
The reported figures below describe this experiment only. They should not be read as current rates of account compromise, or as representative percentages of all stolen credentials or Dark Web users.
| Reported observation | What Bitglass reported |
|---|---|
| Visits to the exposed credentials and fictitious bank portal | More than 1,400 visits. |
| Hackers who accessed Google Drive and successfully accessed the personal banking account using the leaked password | 36 percent. |
| All logins originating from Tor-anonymized IP addresses | 68 percent. |
| Hackers who accessed Google Drive, uncovered the victim’s other online accounts, and attempted to log in to the bank portal | 94 percent. |
| Hackers who successfully accessed Google Drive and tried to download sensitive files | 12 percent. |
| Login attempts’ geographic reach | 30 countries across six continents. |
| Non-Tor visits to the fake bank portal by country | Russia: 34.85 percent; United States: 15.67 percent; China: 3.5 percent; Japan: 2 percent. |
These figures are attributed to Bitglass in SecurityWeek’s February 18, 2016 report. They are findings from one experiment, not estimates of the source countries or behavior of criminals generally.
What the experiment shows about password reuse
The key lesson is the path from one compromised account to another. A password exposed through a phished work or cloud account may be tried on a personal banking account if the user reused it. The experiment’s reported cross-account logins and attempts demonstrate that this kind of reuse occurred in the monitored setup; they do not establish how prevalent it is among real bank customers.
Bitglass CEO Nat Kausik said the experiment showed the dangers of reusing passwords and the speed with which phished credentials can spread. He called for more secure authentication and for organizations to identify breaches quickly and control access to sensitive data. The study did not test or endorse a particular consumer security product.
What readers and organizations can take from it
- Use unique passwords. A password used for a cloud or work account should not also unlock banking or other personal accounts. If one service is compromised, unique credentials limit the opportunity to reuse that password elsewhere.
- Prefer phishing-resistant authentication where available. Check the account provider’s supported sign-in methods and recovery process; this 2016 experiment did not compare authentication methods or establish a product ranking.
- Respond promptly to suspected exposure. Change the affected password and any reused passwords, review account activity, and use the provider’s recovery and security controls if you see unfamiliar access.
- Organizations should pair authentication with response controls. The report’s recommendation was to identify breaches quickly and control access to sensitive data, rather than relying on a single authentication measure.
Limits of the 2016 report
The accessible account is SecurityWeek’s report, which attributes the study and its results to Bitglass. SecurityWeek linked a Bitglass PDF report, but that document was not available for independent verification here. Treat the details and percentages as attributed reporting rather than independently confirmed findings from the primary report. The experiment is historical and cannot establish current threat levels.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
