361–370 of 490 posts
Earlier quoted context omitted.
In this specific case DEBUGLEVEL should be a constant anyways, and thus assignment should fail, no? Also kind of denoted by being all caps.
Conventions cause assumptions.
At work one of our most commonly used libraries prints it's connection string (including the plain text password, username and database) in the log files on debug level (which I often see as the configured level). When I pointed it out they told me it was intentional, and that attackers wouldn't go to the log files anyway if they could acces the system. I gave up on the discussion at that point
You should quit. I know you have reasons, but continuing to work at a place like this is not ethical.
Naive question - wouldn't a lot of these issues be much better if passwords were (on top of server side processing) salted and hashed client-side? Then in principle you couldn't do these cross-site attacks where people reuse their passwords.
Earlier quoted context omitted.
And how do you propose to do that when the clocks arent synchronized? Clock drift is exceptionally common. Not everyone runs ntp or ptp. Probably even fewer use ptp. Desktop/laptop clients it's typically configurable on whether or not to attempt clock sync, and ive never seen where the level of synchronization is documented for PCs. High precision ptp usually requires very expensive hardware, not something to be expe…
Well how do you think TOTP works?
Earlier quoted context omitted.
People (atleast me) ignore warnings quite often, they aren’t safe haven if you ask me.
Hey no problem, just add -Werror to your compiler flags (C/C++/Java) or ' true ' to your csproj (C#).
You will have a better, more reliable, and safer codebase once you clean up the legacy mess and turn this on..
Earlier quoted context omitted.
Well, nothing ever left Twitter's servers. The logs themselves would probably be uninteresting to outside parties and inaccessible.
Last year a contractor deleted the president’s account. The fact it didn’t leave Twitter doesn’t mean everything is good. There are still a LOT of people who may have had some kind of access to this data.
Earlier quoted context omitted.
Genuine question—how would this bug be produced in the first place? My (limited) experience makes me think that cleartext passwords are somehow hard coded to be logged, perhaps through error logging or a feature that’s intended for testing during development. I personally would not code a backend that allows passwords (or any sensitive strings) to be logged in any shape or form in production, so it seems a little wei…
Not exactly log files, but I once noticed a C coredump contained raw passwords in strings that had been free'd but not explicitly overwritten. Similar to how Facebook "deletes" files by merely marking them as deleted, "free" works the same way in C, the memory isn't actually overwritten until something else writes onto it.
Earlier quoted context omitted.
In the past, I've seen logs monitored for high-entropy strings that could be API keys or passwords. However, in a NoSQL/UUID-using environment, this could be really hard to implement.
Perhaps implement some type of “password canary” - some type of test account(s) with known high-entropy passwords. Have an automated system send periodic login requests (or any other requests which contain sensitive information that shouldn’t be logged) for this account, and have another system which searches log files for the password. If it’s ever found, you know something is leaking.