Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
All 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.
 
How does that work on computers and other devices that don't support anything like that?
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.
 
Last edited:
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.

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).
 
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.
So basically a utopian-like future.
 
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).
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.

* edit: other than trusting the client to check password length and such, which is simple and far less error-prone than having the plaintext password go to the server. Commonly used end-to-end encrypted systems do trust the client in similar ways.
[doublepost=1525400877][/doublepost]
So basically a utopian-like future.
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.
 
Last edited:
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.

Yep. I would hope at some point either the tech industry shuns companies that do this so bad it hurts the bottom line. Hoping that as a first step before government regulation has to step in.

Make app start up for companies like display a big warning that the app and site are known to be potential harmful due to know security weaknesses. Will keep any nontechnical people from being afraid to hit continue completely.

The lawsuits can have a good effect too, of course. Well deserved law actions in this case of course.
 
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.

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.
 
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.
...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.
 
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.
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.
 
Last edited:
I have Two Factor Authentication turned on with my Twitter account. If they had my password, it is useless to them.
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.
 
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.
 
Oh, don’t forget that police can order you to use biometric methods to authenticate, but not necessarily password itself.

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.
 
  • Like
Reactions: iapplelove
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.
I second your laugh btw.
People who knows nothing just throw out BS thinking they are smart while they are not. Needless to say, I sometimes am one of them, just in a different situation.
 
And the site is down.
Biometrics need to advance further...
It is essentially impossible to remember all the different passwords for everything!
But if then if something happens it is something that you can’t change.
 
Got 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?
Thank you for alerting me of this
[doublepost=1525448585][/doublepost]
All 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.
I think even the guy that left the iPhone 4 in the bar wasn't fired
 
Just another reason to use a password manager. With 1Password, it was about three clicks and I had a new password, and one that would be almost impossible to guess... ain't technology great!
 
  • Like
Reactions: H3LL5P4WN
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.