4 ms·

I'm amazed how the author of an awesome tool like hping can get this so wrong. I know you're an incredibly intelligent and capable guy, but some of the stuff yo

by iuguy 16y ago

I'm amazed how the author of an awesome tool like hping can get this so wrong. I know you're an incredibly intelligent and capable guy, but some of the stuff you're saying here is really bad. There's almost always a UX/Security tradeoff, but in this case the user benefit is less than the loss in security - in other words the value of the tradeoff isn't sufficient to justify the lapse in security. Setting the cookies to expire in 2036 isn't a good idea at all. If the user has a shared PC then you've just introduced a 25 year window of opportunity for anyone with access to that system to compromise the account. What PoF should've done is include a password reset link in the email. No need for messing around with cookies, and those that remember their password can log in just fine.

speleding 16y ago
> but in this case the user benefit is less than the loss in security That's a highly subjective statement. Lower security makes the site more money with better user retention and it improves the user experience (as long as the site doesn't get hacked). For a bank the trade off will be different but for an online dating site I can see it makes economic sense to behave that way.
- iuguy 16y ago
  I see what you're saying but I disagree that it's subjective. I'm saying that the benefit for the user is lower than the loss in security (to the user) with this approach. You're saying that the benefit to the site owner is greater in this case, and I'm not sure whether it is or not (but if it's a deliberate policy I'm sure PoF would). What is a benefit to one side is not necessarily a benefit to another.
StavrosK 16y ago
I agree with you, but this isn't a solution either. You can, quite trivially, implement sending a one-time random hash that will log the user in when he clicks it. So, you can say "you haven't been active, click here to be logged in". This is less secure than not sending the hash, but we've already established you want the user to log in from the email. This is more secure than sending them their password and more user-friendly than having them type it in. Plus, the hashes expire after one use, so they won't be able to be reused. Storing passwords in plaintext is an extremely bad practice.
antirez 16y ago
I think that apart from our understanding of usability/security tradeoffs everyone has a different idea of what is the right ratio. I think that for some kind of applications the right ratio can be so biased to store passwords in clear texts, or alternatively to set cookies to 2036. I mean, once all we understand that storing things in cleartext is bad, doing it is a matter of design choice. I don't recommend this techniques for most applications, but for a few it can be a possible choice.

by iuguy 16y ago

speleding 16y ago

> but in this case the user benefit is less than the loss in security That's a highly subjective statement. Lower security makes the site more money with better user retention and it improves the user experience (as long as the site doesn't get hacked). For a bank the trade off will be different but for an online dating site I can see it makes economic sense to behave that way.

iuguy 16y ago
I see what you're saying but I disagree that it's subjective. I'm saying that the benefit for the user is lower than the loss in security (to the user) with this approach. You're saying that the benefit to the site owner is greater in this case, and I'm not sure whether it is or not (but if it's a deliberate policy I'm sure PoF would). What is a benefit to one side is not necessarily a benefit to another.

StavrosK 16y ago

I agree with you, but this isn't a solution either. You can, quite trivially, implement sending a one-time random hash that will log the user in when he clicks it. So, you can say "you haven't been active, click here to be logged in". This is less secure than not sending the hash, but we've already established you want the user to log in from the email. This is more secure than sending them their password and more user-friendly than having them type it in. Plus, the hashes expire after one use, so they won't be able to be reused. Storing passwords in plaintext is an extremely bad practice.

antirez 16y ago

I think that apart from our understanding of usability/security tradeoffs everyone has a different idea of what is the right ratio. I think that for some kind of applications the right ratio can be so biased to store passwords in clear texts, or alternatively to set cookies to 2036. I mean, once all we understand that storing things in cleartext is bad, doing it is a matter of design choice. I don't recommend this techniques for most applications, but for a few it can be a possible choice.