181–190 of 190 posts
Earlier quoted context omitted.
What? If it's the same scenario then the CSR does not and never did have the password, they just have domain control panels. The whole point is that they can't do that.
I mean the scenario posed by Gigabytecoin, in which a CSR can read my password in plain text.
Earlier quoted context omitted.
I mean the scenario posed by Gigabytecoin, in which a CSR can read my password in plain text.
Oh. Well why would you ask freejack in particular about that? That's not how their security is set up.
Earlier quoted context omitted.
I can confirm that they're still doing this. I recently had a conversation with their support staff about it and I don't think they'll be changing it any time soon. I like Dreamhost, but if they don't change this I'll probably bail.
Can you explain why you would leave over that? As long as you are aware of it and use a unique password how does it impact you? They would have to have a very specific and unnoticed breach that gets database and key. Is it worry that they are lax in security elsewhere?
tl;dr: guy from hover, mea culpa, new code on the way. I thought it might help to provide some further deets on that blog post. I don't think we're making a case there, or providing an excuse - it certainly wasn't my intent to try and convince anyone of anything when I wrote that, but rather, it was an exercise to explain where we were (with that and other development projects) and where we were going. We've gone bac…
Fwiw, let me share some of the less predictable consequences of what could happen if your pwd database is hacked, and why it's important to use bcrypt, PBKDF2, or scrypt to secure your users passwords. ( http://codahale.com/how-to-safely-store-a-password/ ) I was one of the folks whose email and password were compromised in the recent MtGox.com bitcoin exchange attack. Until then I had been using a three-tier passwor…
Earlier quoted context omitted.
I agree with you wholeheartedly. Unfortunately, there will always be a few services that will store passwords in plain text. Would unique email addresses for each service have helped your situation at all? For example: Facebook email: uniqueemail1@gmail.com (forwards to your real email) Facebook password: password1 Hover email: uniqueemail2@gmail.com (forwards to your real email) Hover password: password1 Bank email:…
But then even if you remember the password, you'd still need to remember the right unique email id for each service.
Earlier quoted context omitted.
DreamHost also stores passwords in a recoverable fashion, FYI.
Disclaimer: I am an ex-DH intern and my information is only as good as August 2010, but it is likely to still be accurate. At the very least, DH does not store passwords as plaintext, but it's only very marginally better than that. Passwords are stored using a custom-rolled symmetric encryption algorithm created by... I never found out if it was a founder or just one of the earlier admins, but that doesn't really cha…
Well done, hover!
Earlier quoted context omitted.
Are you sure of this? The CSR could also be comparing the hashed/bcrypted/whatever version of the password you give them over the phone to the hashed/bcrypted/whatever version stored in the database.
To activate SSH on your account, you are required to dump your password into the free-text area on a support ticket (see http://support.jumba.com.au/kb/questions/45/Do+you+offer+SSH... ). Given they do this sort of thing, even if they did do fancy hash comparisons when I called them, they still have people's passwords hanging around in plain text elsewhere on the system.
This isn't a microblogging service or pet social network. A domain registrar is storing your password in plaintext? Really? Didn't we go over this a thousand times? If I was on Hover (which I considered), I'd transfer my domains immediately. Moving to a plaintext password system to get fewer support requests is like removing the door from your house so you don't have to keep fumbling for the key.
Companies like Hover have a user/password scenario unlike e.g. an email provider: users only visit their site one/two times a year (to renew a domain or whatever). So I wonder if they should instead allow "authentication-by-email". Basically, make it work just like current reset emails (with an embedded randomized link that allows access), but prevent the link from expiring. Obviously that suggestion has a lot of hol…