3 ms·
Obviously you shouldn't log passwords, but what kind of security mechanism have been effective to catch this error? One thing I can think of is have some produ
by hunter23 7y ago
Obviously you shouldn't log passwords, but what kind of security mechanism have been effective to catch this error?
One thing I can think of is have some production test accounts that are regularly used and have a unique password. Then have an automated task that periodically greps the production logs for the password to see if you have a log leak.
Any other approaches?
- human20190310 7y agoYou could grep production logs and other data stores for commonly used passwords like "password123".
- UncleMeat 7y agoBetter hope data isn't encoded in some other format. Better hope you have na exhaustive list of all the production logs.
- kevin_thibedeau 7y agoMore dependable would be tests that inject unique privileged information and then check for that appearing anywhere it shouldn't.
- londons_explore 7y agoYou need to do both. Real users will find routes through your app that automated tests never consider. For example, what if the users 1-year login cookie expires as they're on step 3 of a 4 step "change your avatar" process. That's highly unlikely, and probably not even tested. Yet it might well work (due to good modular design), but also log inappropriate data.
- MartinCron 7y agoI actually really like that idea, constantly scanning logs for hyper-specific red flags. I might start doing this.
- londons_explore 7y agoI do this already, for both user passwords, but also accidental leaking of internal company data into logfiles. It also checks for base64 encoded versions of the data (with various alignments). There is also an alert if data is unscannable (due to compression or encryption). The check is done at logs ingestion points, but also on outgoing http requests from webdriver automated tests (since some third party scripts might be shipping the data off to someone else's server). The scanned for words are: * the top 100 passwords, excluding things used as test strings. * A few company specific passwords. * A few testing passwords * A few random strings which are also deliberately inserted into source code files in places that should never (by design) pass between client and server.
- MartinCron 7y agoThanks so much for sharing.
- _visgean 7y agoI was also thinking about using canaries like this to detect database leaks - basically insert fake users into your DB with random emails and if you see that somebody is trying to email the accounts or log-in to their accounts you know you have been compromised. Not sure if anybody has ever used something like this...
- spyspy 7y agoIt’s a legit strategy. I’ve heard it called a “honeypot”
- xioxox 7y agoYou would miss partial or manipulated passwords (e.g. base64 encoded) with that approach, but it's a first step.