Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> For goodness sake, marketers typically have query access to the DB.

That's a bit of a straw man, don't you think? Even if marketers have access to the database, they shouldn't have read access to the passwords table in a properly configured system. If they do, it's time to fire your DBA.

> The problem there is that if I gain access to your email account, I can quickly search "password" to discover your private passwords

Sometimes it's worse than that. I recently had to do a password recovery on a site, and they sent the password not only in plain text but also as the very beginning of the email. As such, gmail helpfully showed "example.com" as the sender, with "Password: P@ssword1" right in the body preview snippet. You could see it without even having to open the email.

It may not be a common exploit, but if I was checking my gmail at work, a coworker that knew I had an account on this website could just send a recovery request and glance over my shoulder at just the right time and grab my password without my knowledge. Not good.

I wish Google would implement some sort of algorithm that could determine password-looking text and a) not show it in the preview, and b) require user interaction to display it when viewing the actual email body.



The odds of having a properly configured database in a company that stores password in the clear don't seem very high.


> they shouldn't have read access to the passwords table in a properly configured system. If they do, it's time to fire your DBA.

I can guarantee that it happens. A lot. And firing the DBA is a poor solution.


Password are not usually stored in a separate table, they are usually just a column in the users table.

What you do is make a view that does not include the password column, and give them access to the view, but not the table.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: