No reason in particular. Just no call for it. I'll put it on the short list.
Any update? I tried https://hubski.com, no go. Even if it's something like reddit does where it's hidden (and partially broken, although HTTPS Everywhere can force it most of the time and it's mostly working) under https://pay.reddit.com, it'd be appreciated. They at least use https://ssl.reddit.com for the login sequence, which means the plaintext password is encrypted before delivering the hash.
Didn't notice but 147 days after that comment... http://hubski.com/pub?id=114052 It keeps coming up.
It's an idea well-worth-having. At the very least, for logins it should be mandatory (because otherwise people's passwords are passed around unencrypted, and despite all warnings to the contrary, many people continue to use the same password for multiple sites). Ideally it should be possible to use SSL the whole time, to prevent cookie theft. Cookie theft is not as dangerous as password theft, because it only allows the attacker to steal the victim's Hubski account and not all of the accounts where they use the same password and a similar username, but it's still pretty bad. While we're talking about security: you really ought to require that people re-enter their existing password when changing their password. Otherwise an attacker who does the aforementioned cookie theft attack could change the victim's password, thereby locking them out of their own account. In fact, an attacker could change the password of anybody who made the mistake of leaving their computer logged in when the attacker is nearby! That's the major reason that most services require that you re-enter your password in order to change it. Finally: I assume that you're hashing the password on the database side, and not just storing them plaintext. If not, that really needs fixing, unless you want to be involved in the kinds of attack that got LinkedIn, Sony, eHarmony etc. over the last 18 months. You're doing great work, mk: please don't think I'm nickpicking! Security's important, and it's worth getting right. Shout me if you need any clarification on any of my points.
A follow up, as promised: https://hubski.com/pub?id=146000
Good point. I'll implement that as well. Yes, they are hashed. Thanks. I have no problem being cautious, or sensitive to privacy. In a place where we want people to speak freely, it doesn't hurt. I'll follow up.While we're talking about security: you really ought to require that people re-enter their existing password when changing their password.
Finally: I assume that you're hashing the password on the database side, and not just storing them plaintext.
You're doing great work, mk: please don't think I'm nickpicking! Security's important, and it's worth getting right.
Or better yet, use bcrypt, PBKDF2, or scrypt. Salted hashes slow a cracker down by a day or two, but an actual work factor turns that into years or decades. I'm not too sure what has been implemented (well) in arc, so that may or may not be the deciding factor on the matter, but any of the three is better than a simple salt.