Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Twitter urges users to change passwords after computer 'glitch'

reuters.com

Post reply on HN
Print view View original

441–450 of 490 posts

Re: Twitter urges users to change passwords after computer 'glitch'

#441

Post by acomjean »

kiallmacinnes wrote: post #365
_sh wrote: post #319

Earlier quoted context omitted.

Hey no problem, just add -Werror to your compiler flags (C/C++/Java) or ' true ' to your csproj (C#).

This! Treat every warning as a failure, ideally in your CI system so people can't forget, and this problem (ignoring warnings..) goes away. You will have a better, more reliable, and safer codebase once you clean up the legacy mess and turn this on..

I agree. Having worked in a project with warnings as errors on (c++) I found it annoying at first but it made me a better coder in the long run.

Plus you get out of the habit of not reading output from the compiler because there are so many warnings...

Re: Twitter urges users to change passwords after computer 'glitch'

#442

Post by amhokies »

amelius wrote: post #440
overlordalex wrote: post #398

Earlier quoted context omitted.

We made this mistake - the trick is determining what fields are sensitive, what are sensitive enough that they should be censored but included in the log, and the rest of the crud. It turns out that this is non-trivial - when censoring how do you indicate that something was changed, while keeping the output to a minimum? blank/"null" was rejected because it would mask other problems, and " * THIS FIELD HAS BEEN REDAC…

You prevent a lot of these problems by hashing passwords as soon as possible (i.e., on the client).

Wouldn't that make it easier for someone that has access to hashed passwords in the case of a database leak? They would just have to submit the username and the hashed password (which they now have).

Re: Twitter urges users to change passwords after computer 'glitch'

#443

Post by nl »

jstanley wrote: post #354
brownell wrote: post #291

Earlier quoted context omitted.

So let me make sure we're on the same page... -- Server stores hashed-password, hash-salt, and random-salt. Server sends hash-salt, and random-salt to client. Client uses user password and hash-salt to generate hashed-password. Client hashes hashed-password using random-salt. Client sends hashed-hashed-password to server. Server grabs stored hashed-password and hashes used stored random-salt to check for match agains…

No, random-salt is not stored permanently but generated at random by the server every time a client is about to authenticate. Alternatively a timestamp would be just as good.

You have to store the salt somehow, because you need to check that the salted, hashed password matches.

Re: Twitter urges users to change passwords after computer 'glitch'

#444

Post by lhnz »

sumeno wrote: post #427
lhnz wrote: post #417

Earlier quoted context omitted.

Why not automate this? Create a user with an extremely unusual password and create a script that logs them in once an hour. Use another script to grep the logs for this unusual password, and if it appears fire an alert. Security reviews are important but we should be able to automate detection of basic security failures like this.

This only works if you automate every possible code path. If you're logging passwords during some obscure error in the login flow then an automated login very likely won't catch it.

True, but it is more effective than doing nothing.

Re: Twitter urges users to change passwords after computer 'glitch'

#445

Post by nl »

mehrdadn wrote: post #221
jrochkind1 wrote: post #156

Earlier quoted context omitted.

nah, that just makes the "hashed password" the equivalent of the cleartext password. Whatever it is your client sends to the server for auth is the thing that needs to be protected. If the client sends a "hashed password", that's just... the password. Which now needs to be protected. Since if someone has it, they can just send it to the server for auth. But you can do fancy cryptographic things where the server never…

Not really... it's not that simple. You could use the time of day as a seed for the hash, for example. There are tradeoffs to be made, which is partly why they don't do it, but the story isn't as simple as "the hash becomes the password".

If the client knows to use the time of day then an attacker also does.

This is exactly the same: the seeded hash is the password.

Re: Twitter urges users to change passwords after computer 'glitch'

#446

Post by nl »

lorenzhs wrote: post #414
ealhad wrote: post #173

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/

Does anyone have a recommendation for a good keepass client for iOS? Is MiniKeePass still the best option? I've been wanting to switch to KeePassXC + something for iOS for a while but I'm not sure what the best way to go is.

I use MiniKeePass. Don’t love it, but don’t know a better option.

Re: Twitter urges users to change passwords after computer 'glitch'

#447

Post by nl »

dcsommer wrote: post #127
calebh wrote: post #99

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…

KeePass and Dropbox works great for me as a free alternative. I use the Kee plugin on Firefox and KeePass2Android on my phone. I set it up to need both a private key and password to unlock my password DB. The private key moves around on a thumbdrive only (never in Dropbox). I like that the only parts of this system I have to trust are open source.

How do you manage the private key on your phone?

Re: Twitter urges users to change passwords after computer 'glitch'

#448

Post by nl »

osteele wrote: post #169
springbrunnen wrote: post #140

Earlier quoted context omitted.

I'm skeptical whether it is really worth it to trust yet another party that can potentially be bribed by intelligence agencies and what not; or even hacked. No. I sit down once a year and think of CorrectHorseBatteryStaple-like passwords [1] for each important service, where each password is a relatively complex function (involving deletions, insertions, swaps, associations, numbers and special characters) of details…

How long have you done this, for how many sites, do you rotate passwords (when sites are breached, and/or on a schedule), and have you had to access sites in a mentally compromised state (distracted, sleep-deprived, post-concussion)? Every once in a while I hear someone explain their system for this (and I used to use a simpler scheme), and I can think of arguments about why it won't work for long, but I'd be happy t…

My question with these schemes is how do they deal with sites which have weird password requirements which don’t match the scheme.

Typically they don’t remind you when you are logging in that *we made you use 8 character passwords but you can’t use some special characters” or whatever. So you have to have some way of remembering what crazy password rules they had 3 years ago when you registered...

Re: Twitter urges users to change passwords after computer 'glitch'

#449

Post by bonyt »

fatratchet wrote: post #6

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.

Sounds like the same kind of thing that happened with APFS encryption passwords recently, too.

https://www.mac4n6.com/blog/2018/3/30/omg-seriously-apfs-enc...

Re: Twitter urges users to change passwords after computer 'glitch'

#450

Post by larkeith »

amelius wrote: post #440
overlordalex wrote: post #398

Earlier quoted context omitted.

We made this mistake - the trick is determining what fields are sensitive, what are sensitive enough that they should be censored but included in the log, and the rest of the crud. It turns out that this is non-trivial - when censoring how do you indicate that something was changed, while keeping the output to a minimum? blank/"null" was rejected because it would mask other problems, and " * THIS FIELD HAS BEEN REDAC…

You prevent a lot of these problems by hashing passwords as soon as possible (i.e., on the client).

While there is merit to clientside hashing, you should always hash serverside as well, lest a leak prove catastrophic.
Post reply on HN