241–250 of 490 posts
Earlier quoted context omitted.
Time for me to advertise my personal setup again! I use KeePassXC [1] with Syncthing [2] to synchronize my passwords between machines. No third-party! [1] : https://keepassxc.org/ [2] : https://syncthing.net/
What if you’re on someone else’s machine?
A couple of steps you can take to reduce the chances of accidentally putting sensitive information in a log. 1. Make a list of all sensitive information that the test users in your test environment will be giving to your application. As part of your test procedure, search all logs for that information. This can be as simple as having a text file with all the sensitive information, and doing a 'grep -F -f sensitive.tx…
Probably better than 2 is to use actual privilege separation between sensitive data and as much of your service as possible. Handle passwords and password changes in a separate microservice which exchanges it quickly for a session cookie, so that the bulk of your application logic doesn't have passwords in memory at all. For credit card numbers, do something like what Stripe does where one API endpoint exchanges the…
If rather than a naked string you have a Password class with literally no way to extract the plain text password then you can be positive that any code that uses it will never accidentally log the password.
In contrast, if you rely on microservice tokenization you can still accidentally log your password before your tokenization happens, just like people are accidentally logging passwords before they are bcrypted.
Both proposals have a problem of logging raw requests or raw service calls (outside of your object model).
Where plausible it would probably be best for microservice calls to only take already bcrypted passwords, and error out if it detects one that isn't, so there is zero chance of accidentally logging a plain text password when calling a microservice.
Again, an actual object (e.g. HashedPassword) shines here, because your code can automatically detect bad values the instant it hits your object model, and refuse to properly log or give access to anything that looks like it isn't already hashed.
Actual twitter post: https://blog.twitter.com/official/en_us/topics/company/2018/... "Due to a bug, passwords were written to an internal log before completing the hashing process. We found this error ourselves, removed the passwords, and are implementing plans to prevent this bug from happening again." Exact same thing that github did just recently.
For people that know more about web security than I: Is there a reason it isn't good practice to hash the password client side so that the backends only ever see the hashed password and there is no chance for such mistakes?
Earlier quoted context omitted.
So Twitter found out they had a bug that caused them to store passwords in one of their databases in plaintext. Their response is just a generic 'hey maybe you want to store your password'. Compare that to Github who just yesterday went through the exact same problem, except they're requiring users change their password. Their CTO didn't make some 'hey you should THANK US" claim.
Are they? I just signed in on a machine where I had signed out and got no prompt to change it. Is it only certain users?
> During the course of regular auditing, GitHub discovered that a recently introduced bug exposed a small number of users’ passwords to our internal logging system, including yours. We have corrected this, but you'll need to reset your password to regain access to your account.
> GitHub stores user passwords with secure cryptographic hashes (bcrypt). However, this recently introduced bug resulted in our secure internal logs recording plaintext user passwords when users initiated a password reset. Rest assured, these passwords were not accessible to the public or other GitHub users at any time. Additionally, they were not accessible to the majority of GitHub staff and we have determined that it is very unlikely that any GitHub staff accessed these logs. GitHub does not intentionally store passwords in plaintext format. Instead, we use modern cryptographic methods to ensure passwords are stored securely in production. To note, GitHub has not been hacked or compromised in any way.
Earlier quoted context omitted.
I think I, and everyone here, should check as well. If capable, security-minded companies can make such a mistake, so can you.
Yep, glad I read this thread. We were making the same simple mistake.
Now.
(We caught ourselves doing it 4-5 months back, and went through _everything_ checking... Only random accident that brought it to the attention of anyone who bothered to question it too... Two separate instances by different devs of 'if (DEBUG_LEVEL = 3){ }' instead of == 3 - both missed by code reviews too...)
Earlier quoted context omitted.
You could hash it twice, once at the client and once at the server. So your database would store a hash of a hash. But without persistence on the client side you wouldn’t be able to do salting in the first hash (where do you store the salt?)
Does it buy you anything at that point? A server-side issue, such as this, would still log the thing you need to log in, and a client-side issue would just intercept the hashed form or could derive the hashing mechanism from analysing the client. At most, it would seem to prevent weak passwords from being passed directly to bcrypt, but salting should solve that in a similar way anyway, and anyone brute-forcing a copy…
That would effectively create a one time “password” for transmission from browser to database. In a case like this one, where sensitive text transmitted from the client leaked into logs, it would be a non-issue. The sensitive string in the logs is a temporary hash that would be useless shortly after discovery, since it was derived from an expired nonce.
It effectively becomes a real time scrubbing system with 100% coverage, because the passwords are “scrubbed” by design, and do not depend on explicit detection code in some scrubbing mechanism.
If this happens in a month's time, will they have to pay out $96,000,000 via the GDPR? This came up at my place of work the other day: are data leaks as a result of bugs breaches of the act?
IANAL: No, there is a process of stuff before you will get fined. A human error does not suddenly lead to heavy fines, if you can prove that you put everything you can to prevent this from happening, i.e. follow all the processes GDPR defines like data processing agreements with third party processors, technical and organizational measures to protect against privacy violations, documentation of personal data stored w…
Earlier quoted context omitted.
The state of technology reporting in the mainstream press really makes me despair sometimes. The problem is that the mainstream press writes for mainstream users, and the state of science/technology understanding in the general public is the real problem.
I hear what you're saying, but I think — in this case — the article's just giving too much irrelevant information. I think most mainstream users I know would understand it if it were written something like: > A bug caused passwords to be written on an internal computer log, the blog said.
I highly recommend using a password manager. I finally bit the bullet and started using 1Password a few weeks ago, and I haven't looked back since. It's just so much better than having to remember a thousand different passwords. Besides securely managing passwords, you can also use a password manager to secure your digital legacy. 1Password has a feature where you can print out "emergency kit" sheets that has the inf…
I'm going to plug https://bitwarden.com/ since nobody else has yet (I'm not affiliated). Open source, clients for everything, free for personal use, imports from other managers. I had been using a GPG encrypted text file for a long time, then later KeePass (and variants) on dropbox. I switched to Bitwarden a while ago and have been very happy with the whole thing.
I highly recommend using a password manager. I finally bit the bullet and started using 1Password a few weeks ago, and I haven't looked back since. It's just so much better than having to remember a thousand different passwords. Besides securely managing passwords, you can also use a password manager to secure your digital legacy. 1Password has a feature where you can print out "emergency kit" sheets that has the inf…
Is there a reason to use 1Password over iCloud Keychain if you're mostly only on Apple devices?