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

There are some cases when storing plaintext passwords is justified, despite all of the risks. There are cases where you can't - or shouldn't - hash passwords.

For Freeversation, we store plaintext passwords for two reasons:

1. Our passwords are group passwords, which (hopefully) aren't re-used anywhere else. If someone hacks our server, the conversations stored on it are incredibly more valuable than the passwords themselves, which aren't associated with a specific email address or account. Our approach to security is that unauthorized access to our server is checkmate. That is the worst case scenario, not stolen passwords.

2. When you create a new conversation, you can invite new users to the discussion. Those users didn't sign up for Freeversation - and in all likelihood never heard of Freeversation before - but they're expected to remember a password that someone else chose. We help them remember that password by including it in every notification email we send. (E.g. emails inviting them to the conversation, emails notifying them of new comments, etc.) We wouldn't be able to do that if we hashed passwords.

In our case, the alternative to plaintext passwords is actually getting rid of passwords altogether and replacing them with secret URLs. We chose plaintext passwords because they provide psychological reassurance that conversations on Freeversation are invite-only, and not public. The irony is that secret URLs are actually more secure than the passwords that most of our users choose. In the future, we may use a combination of the two, so that users both feel protected and are protected in the best way possible.



The catch is in the word hopefully.

Wishful thinking is not a successful way of doing things in engineering.


If someone creates and conversation and re-uses a password, that password is emailed to everyone they invited. There is no way to avoid that and still use a group password.

Edit: Furthermore, the password is not associated with a specific email address or user name. Even if someone has access to a conversation's password, they don't know who the password belongs to.


I don't know your use cases, so pardon me if this is naive, but couldn't you create a token that is unique for each user, and is consumed after use?


I'm not sure what you have in mind.

Our use case is explained on freeversation.com/about. Let me know if you have any questions.


Okay, having read that, I agree -- you absolutely don't have to worry about password theft. At least, not after the fact of a conversation having already happened.

However, what I was suggesting, is that instead of using a group password:

- create a random password for each user that is invited - as part of the 'login' process (or room join process, depending on how your code is structured), check to make sure that token exists in the database - as soon as somebody uses that random password, delete it (or mark it inactive)

This means that for each token, there can be exactly one login. That login should belong to who you sent the email to, and nobody else. It's just as anonymous as your method, and slightly (wee bit) more secure.

This also solves the problem of people sending the password to their friends, though obviously cannot plug the analog hole of allowing their friends to look at their screen.


No, it's only the worst-case scenario for you. The worst-case scenario for the users (your customers) is their password exposed. They don't care about your server.


Again, it's not a private password if they chose to share it with a group.


What if the group is that person and their dad, and they don't care if their dad knows the password to their gmail?


By definition, there is no point in having an anonymous conversation with your dad, because it wouldn't be anonymous. Right now, we're seeing freeversation used with much larger groups of people, where guessing which email matches the password is impractical, even if someone does reuse a password.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

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

Search: