I've been trying to pitch hubski to my friends, and one of them(a opsec nut who virtualizes his firefox browser and is extremely paranoid) brought up that there is no SSL support for hubski. Is there a reason why there is no SSL now? Not worth the effort, technical difficulties? It would definitely calm the extremely paranoid and would be a nice security feature overall.
I'm not trying to be nitpicky, just genuinely curious about this, and how it will be done in arc in the future.
You don't need to be super paranoid to find SSL useful. No SSL means your login data is transmitted unecrypted, which means it's easy for anybody to read it, especially if you log in from a public wifi. If you're using the same username password combination on other sites you're in big trouble. So I agree, this should really be fixed. Edit: Even if you don't log in from public wifis it's easy on this site to steal the accounts from users you share the network with.
Agreed. The sheer volume of online password protected services the average user engages with practically demands re-use of passwords if they are to be memorable. Capture one site's credential and you've often captured at least a few more by proxy. I always appreciate SSL no matter how trivial the service using it may appear to be for this reason.
Thing is, it really is convenient. If you do not want to set that up, you can always have a password like ThisIsAPassword-Hubski for hubski, or ThisIsAPassword-Facebook, it is slightly safer, makes the password stronger, and it actually helps discover where a leak of passwords came from, as usually someone will dump the passwords on pastebin without a source, and passwords like that will help identify it.
It is slightly more secure than using the exact same password everywhere, as when one site is compromised, the password can be put in a wordlist for brute forcing or hash cracking. So instead of using ThisIsAPassword for every site, you have a slight variation but it is still extremely convenient to remember it.
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.