Finance company stores DB credentials in helpfully labeled spreadsheet
- Reference: 1777536012
- News link: https://www.theregister.co.uk/2026/04/30/finance_company_stored_their_db_pwned_column/
- Source link:
The tale comes to us courtesy of Stanislav Kazanov, head of strategic practices at [1]Innowise , a software development firm. A few years ago Kazanov and his group were hired to perform compliance and data architecture audits on a fintech startup where execs had invested more than $1 million to develop a "military grade" security system complete with biometric MFA, endpoint detection, and a ton of physical security.
During the audit, Kazanov logged onto the company's SharePoint site and found a folder called "DevOps_Handoff" on the company-wide intranet that any employee could access. Within that folder was a spreadsheet with the very obscure and deceptive filename Prod_DB_Root_Creds_DO_NOT_SHARE.xlsx . Clearly, this naming convention would throw off any would-be hackers.
[2]
On the bright side, the Excel file was password-protected. So, at least there's that, but was there really that much protection?
[3]
[4]
When Kazanov asked the lead engineer for the password, he was so embarrassed that he looked at his feet and mumbled the answer: "It's the [company name] + [year]." We don't know the actual name of the company, but let's just say it was Contoso. The password would therefore be contoso2026. That's not exactly "admin123" but it's close enough to guess.
The lead engineer explained to Kazanov the reason for the file's existence. Apparently, the internal DevOps team and an external DBA team had a disagreement about which enterprise-grade password manager to use. To "temporarily" solve this disagreement, they dumped the root DB credentials and master AWS IAM keys into this spreadsheet, which had existed for a whopping eight months at the time our hero found it.
[5]The company's biggest security hole lived in the breakroom
[6]Using the password 'admin123' wasn't as bad as sharing it on Slack
[7]Server-room lock was nothing but a crock
[8]Sticky-note security turned gym into hall of '80s horrors
Our story ends here. We assume this problem was resolved after Kazanov's intervention and before tragedy struck. However, it shows that disagreements over how to secure resources can lead to dangerous compromises.
In this case, the internal DevOps team should have had the final say over what password manager the contractors and they would use. At no point should they have allowed this conflict to result in putting the secrets into a spreadsheet, even if the spreadsheet had strong password protection.
[9]
The most basic principle of cybersecurity is to give individual access and credentials to only those who really need it. But here the file was on an intranet that was accessible to all employees and even contractors like Kazanov. Since this was a fintech firm, the data involved could have related to millions or even billions of dollars of people's money. This is a serious situation and anyone who is this sloppy with security doesn't deserve to handle a dime in assets or transactions.
Have a story about someone leaving a gaping hole in their network? Share it with us at [10]pwned@sitpub.com . Anonymity available upon request. ®
Get our [11]Tech Resources
[1] https://innowise.com/
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2afMoPuw7XsGDslzBAWMbCQAAANI&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44afMoPuw7XsGDslzBAWMbCQAAANI&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33afMoPuw7XsGDslzBAWMbCQAAANI&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[5] https://www.theregister.com/2026/04/02/pwned/
[6] https://www.theregister.com/2026/04/23/sharing_isnt_caring_pwned/
[7] https://www.theregister.com/2026/04/16/pwned_server_room_lock_lol/
[8] https://www.theregister.com/2026/04/09/pwned/
[9] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44afMoPuw7XsGDslzBAWMbCQAAANI&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[10] mailto:pwned@sitpub.com
[11] https://whitepapers.theregister.com/
Not a gaping hole in the network, but . . .
Once upon a time I was called in to take over security for a new customer.
My company was selected and I was the frontend to replace a very well-known company in Luxembourg which I will not name for obvious reasons.
The time for handover came and the previous responsible gave me a USB key with an Excel file that had the passwords that I needed.
Sorted in a table by the company name.
With all the other companies' data just a click away.
What kind of fuckwit doesn't realize that you don't just give away confidential data like that ?
It's beyond me.
I'm likely to get flamed for this... but based on personal experience, this is a common problem caused by poor management and more specifically by giving people conflicting objectives.
If you run a "DevOps" shop, you are asking some of your technology people to both support production environments and have developer-level access to the code they have in production. Everywhere I've seen this done, I have seen higher levels of unauthorised changes, higher levels of post-change incidents, higher levels of downtime. In fairness, that would be less than 5 organizations, so I acknowledge my experience is limited.
But in shops where developers have no access to UAT or Production and where robust controls were in place to safeguard those environments, stability and reliability were much higher. And yes, we're talking big financial institutions, where the stability and integrity of production code wasn't just important, it carried legal implications for executives [think Sarbanes-Oxley Act, False Claims Act, etc.]. I recall watching one DevOps Analyst-Programmer in particular - a pretty smart guy - get a clean compile out of some code he'd just written, give it a *single test run* on the *production* data, sample the output and then move the code to Production libraries... All because our manager had set up an incentive structure that drove that behavior. Or as we would say, "Work faster, not smarter". Doing that in a shop where roles and responsibilities are amorphous is just asking for trouble.
If you want people to behave in a particular way [sensibly] then you have to incentivize them to do so. Setting year-end goals to "Get X in Production" or "Implement Feature Y" is not an incentive for your developers, it's handing them a loaded gun and asking them to aim at *your* foot, close their eyes and pull the trigger.
DevOps is like giving them a gun with a full clip and asking them to keep shooting at both your feet until the clip is empty.
And DevSecOps is like dropping a tactical nuke in your boxer shorts and hoping it won't go off...
You see, that's why I don't wear boxer shorts..
[1]That's amazing, I've got the same combination on my luggage
[1] https://www.youtube.com/watch?v=7rSmMm-7SVA