![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
usernamenumberPeople who use RCN's my.rcn.com site for cable/net billing and whatnot take note: I forgot my password and called their support line per instructions on the site. After asking me two security questions they'd set up with me when I started the service (one of which I got wrong when trying to answer this time), the rep proceeded to read me my password over the phone.
Moral of the story: if you have a password with RCN, don't use it anywhere else.
I want to be clear that the rep was quite refreshingly friendly and helpful, so this isn't a complaint about their service per se, but I'm reeeeally not a fan of any system that stores passwords like that, because it makes it way easier for someone who has broken into RCN's systems to then get to go on field trips looking for other sites where RCN customers have used the same username/password combos.
A note for non-technical folks who might be wondering how else you could do this... I'm glad you asked! Would you believe that there's actually an elegant and (relatively) secure way to validate passwords without having them stored anywhere but in users' heads?
Many systems use something called a hashing algorithm. "Hashing" is fancy talk for doing some math that turns a password into a long string of numbers and letters, which we call a hash. For example, every time you run "blahblahblah" through the SHA1 algorithm you get back the hash "968af690a7bcca77c9261e395885af77bc661d1c". This hash gets stored instead of the original password.
You may be thinking that this looks a lot like encrypting the password, but there's a big difference: encryption implies the ability to decrypt, and hashing is strictly a one-way trip. At least in theory, you can't reverse the process to figure out what the original password was if you have a hash (though people have figured out ways to "cheat" some hashing algos). Think back to my concern above about people breaking into RCN and you can see why this is helpful.
But if all that's stored is a hash of your password instead of the password its self, how can they tell when you've entered it correctly? Remember that running the same password through the same algorithm should always produce the same hash, so if I type "blahblahblah" at the password prompt, the system just SHA1's what I've entered and compares the result to the hash they have on-file. If what I typed hashes to "968af690a7bcca77c9261e395885af77bc661d1c" then they know I entered the right password, even though that password isn't stored anywhere. Brilliant!
This system has the disadvantage of meaning that tech support folks can't just read you your password if you forget it, but that's easily solved with other mechanisms like password-reset emails, and the benefits make those very worthwhile IMO.
Oookay, so there's an impromptu lesson on hashes that I didn't expect to write when I sat down this morning; and that's just scratching the surface-- I haven't even gotten into random salts, hash collisions, or the implications of modern computing power vs brute-force attempts to crack hashes. All of these, just to be clear, would really be needed for this to be considered complete even as an introduction to the subject, but I only have so much time so there we are. :)
In completely unrelated news, for the last two days I have spent almost literally every waking minute (excepting rehearsals) developing training materials at work. I think I am going mad.
Moral of the story: if you have a password with RCN, don't use it anywhere else.
I want to be clear that the rep was quite refreshingly friendly and helpful, so this isn't a complaint about their service per se, but I'm reeeeally not a fan of any system that stores passwords like that, because it makes it way easier for someone who has broken into RCN's systems to then get to go on field trips looking for other sites where RCN customers have used the same username/password combos.
A note for non-technical folks who might be wondering how else you could do this... I'm glad you asked! Would you believe that there's actually an elegant and (relatively) secure way to validate passwords without having them stored anywhere but in users' heads?
Many systems use something called a hashing algorithm. "Hashing" is fancy talk for doing some math that turns a password into a long string of numbers and letters, which we call a hash. For example, every time you run "blahblahblah" through the SHA1 algorithm you get back the hash "968af690a7bcca77c9261e395885af77bc661d1c". This hash gets stored instead of the original password.
You may be thinking that this looks a lot like encrypting the password, but there's a big difference: encryption implies the ability to decrypt, and hashing is strictly a one-way trip. At least in theory, you can't reverse the process to figure out what the original password was if you have a hash (though people have figured out ways to "cheat" some hashing algos). Think back to my concern above about people breaking into RCN and you can see why this is helpful.
But if all that's stored is a hash of your password instead of the password its self, how can they tell when you've entered it correctly? Remember that running the same password through the same algorithm should always produce the same hash, so if I type "blahblahblah" at the password prompt, the system just SHA1's what I've entered and compares the result to the hash they have on-file. If what I typed hashes to "968af690a7bcca77c9261e395885af77bc661d1c" then they know I entered the right password, even though that password isn't stored anywhere. Brilliant!
This system has the disadvantage of meaning that tech support folks can't just read you your password if you forget it, but that's easily solved with other mechanisms like password-reset emails, and the benefits make those very worthwhile IMO.
Oookay, so there's an impromptu lesson on hashes that I didn't expect to write when I sat down this morning; and that's just scratching the surface-- I haven't even gotten into random salts, hash collisions, or the implications of modern computing power vs brute-force attempts to crack hashes. All of these, just to be clear, would really be needed for this to be considered complete even as an introduction to the subject, but I only have so much time so there we are. :)
In completely unrelated news, for the last two days I have spent almost literally every waking minute (excepting rehearsals) developing training materials at work. I think I am going mad.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2012-05-02 02:57 pm (UTC)no subject
Date: 2012-05-02 03:40 pm (UTC)Somebody's got a serious case of teacher-mode today. Being immersed in developing training materials makes sense.
no subject
Date: 2012-05-02 08:54 pm (UTC)no subject
Date: 2012-05-03 03:11 am (UTC)Just make sure your password is at least 12 characters long, preferably 14 or longer, and not a word found in the dictionary, or a simple 133t translation of a word in the dictionary, or a word with 1 at the end. The latter things are the sorts of things that brute-force searches look for. Well, that and correcthorsebatterystaple.
Once you get past 14 characters that aren't dictionary words, you're at the far end of the bell curve in the password strength category.
Can you tell I sit with crypto folks around me?
no subject
Date: 2012-05-03 09:53 pm (UTC)no subject
Date: 2012-05-05 12:12 am (UTC)