You get one that does, or if you can't, you use something like Google Authenticator except not crappy.How does that work on computers and other devices that don't support anything like that?
No, where does the website need the plaintext password instead of the hashed one? They just hash it then throw it away ASAP. Any validation can be done with the hashed one. Nearly every site uses JS for frontend, not that you need JS to do hashing.
Say I write a browser extension that hashes all passwords sent in forms before sending them, always using the same salt. With no other changes, that would work fine with every website. Heck, maybe I should do that.
So basically a utopian-like future.You get one that does, or if you can't, you use something like Google Authenticator except not crappy.
I consider Authenticator so user-unfriendly that it breeds insecure situations, mainly because it's unclear how you securely transfer keys to a new phone. They could've done a better job.
Not to be rude, but what you're saying suggests that you don't know the difference between encryption and hashing (they're entirely different, and companies don't really need to encrypt passwords in database but do need to hash), and/or you're misunderstanding the security measure I described. Yes, I'm a dev, I know what I'm doing, and there's no trust being put on the client*. If you want more clarification, there are other replies above about this.You aren't a developer, are you? Rule number 1 of making a secure product -- never trust the input you've been given by a user. This means you don't validate/hash on the client because you can't trust that they did it correctly. Furthermore, client-side encryption is not encryption. You can't just store your encryption algorithm/salts in javascript for everyone to see and think that that's somehow more secure than plain text. You can reverse-engineer that in a heartbeat. The industry standard way of transmitting form information (including passwords) is to use TLS encryption to encrypt the entire communication between server and client, and transmit plain text over that encrypted line. This is how the server knows that you didn't use enough characters, or your password is not strong enough, etc, etc. As others have said, most web applications log the POST parameters to a file, though they usually sanitize the log to keep out sensitive information. You'd be shocked how many companies out there don't even bother to encrypt your password before storing it in their database (scary, I know).
I wouldn't call it that far out. WRT hardware, only a matter of time before cheap phones all have touch or face ID and everyone using the Internet has a phone, unless that's already the case. WRT software, need to agree on some standards, which will happen eventually.So basically a utopian-like future.
This is inexcusable. Which developer had the bright idea to store passwords to a log file? That should never happen, ever. There's no reason for it.
I hope that means they fired the person responsible, or sent them back to primary school to learn basic common sense.
This is inexcusable. Which developer had the bright idea to store passwords to a log file? That should never happen, ever. There's no reason for it.
I hope that means they fired the person responsible, or sent them back to primary school to learn basic common sense.
...unless of course someone meant to do specifically that in order to gain access to people's passwords. Although, this could have been a legitimate accident. I've met countless people in the industry who really don't get security, or why they should care. I can't imagine how this specific thing could happen accidentally, but I suppose you never know.I'll bet the person responsible wasn't hired by anyone, just an open source contributor. And I can't imagine what bug put passwords into the log file, but definitely nobody meant to do that.
No, 2FA really is necessary if there's anything important due to how many users' passwords are in the wild. And you don't need a phone number for it, but that's the easiest way for most users, and phone numbers aren't very identifying anyway. Social networks want your face, name, and occupation.The only way to get your true identity (phone number) elegantly is to tell such log file BS. This is the goal of "recommended" 2 factor authentication. Only in this way Big Data can meaningfully combine all social networks.
The programmer who's to blame for this is probably just a very trusting person and doesn't believe in security. He keeps his password on a Post-It note on his monitor. And the password is "password".
Yeah, I have 2FA enabled on all of my accounts that offer it which seems to be the majority of them. I’m just hoping someone someday doesn’t find some way to make 2FA “useful” for their nefarious use.I have Two Factor Authentication turned on with my Twitter account. If they had my password, it is useless to them.
Oh, don’t forget that police can order you to use biometric methods to authenticate, but not necessarily password itself.It’s about time we confined passwords to the history books. Touch ID or Face ID or whatever should replace passwords.
Oh, don’t forget that police can order you to use biometric methods to authenticate, but not necessarily password itself.
I second your laugh btw.Haha, Honestly, if the Police tried to use Face ID to unlock my iPhone, I would just look away from my iPhone. Or close my eyes. After it fails a few times, you are good. You'll have to enter your password. Problem solved.
I would also like to point out that the cops have no reason to ever take my iPhone and want to go through it...Haha. Wow...I hate how these posts can be taken so out of context if not read properly...Haha.
Seems like a good time to leave twitter anyhow.
It took me less than a minute and thirty, the Keurig takes longer to heat upWhat a pain, a waste of time. I'm considering the possibility of getting rid of my Twitter account.
But if then if something happens it is something that you can’t change.Biometrics need to advance further...
It is essentially impossible to remember all the different passwords for everything!
Multiple biometrics?And the site is down.
But if then if something happens it is something that you can’t change.
Oh no, it won't let me add a password of more than 280 characters!![]()
Thank you for alerting me of thisGot an email from GitHub saying the same thing. I guess they're using the same library somewhere.
My question is why the plaintext password is even sent to them for password resets. There's zero reason for that. Shouldn't it just be validated and hashed by the webpage's script before sending?
I think even the guy that left the iPhone 4 in the bar wasn't firedAll of those commenting about firing the person responsible, are completely ignorant to how the business world and technology works.
Software has bugs. There are mistakes. If you fired everyone that made a mistake, you'd set a precedent that would instill fear in everyone else. No one would want to dare make a single mistake, for fear of losing their job and thus everything grinds to a halt.
These companies have become what they are by innovating and pushing forward. You fire people for mistakes (look up the definition, I didn't say malice) then you'd either fire everyone or stop all growth and progress.
People responsible in these situations aren't fired. That's simply not how it works.
Best practice is two factor. But these companies should start using better software.I have Two Factor Authentication turned on with my Twitter account. If they had my password, it is useless to them.