Ask Slashdot: Dealing With Passwords Transmitted As Cleartext? 251
An anonymous reader writes: My brother recently requested a transcript from his university and was given the option to receive the transcript electronically. When he had problems accessing the document, he called me in to help. What I found was that the transcript company had sent an e-mail with a URL (not a link) to where the document was located. What surprised me was that a second e-mail was also sent containing the password (in cleartext) to access the document.
Not too long ago I had a similar experience when applying for a job online (ironically for an entry-level IT position). I was required to setup an account with a password and an associated e-mail address. While filling out the application, I paused the process to get some information I didn't have on hand and received an e-mail from the company that said I could continue the process by logging on with my account name and password, both shown in cleartext in the message.
In my brother's case, it was an auto-generated password but still problematic. In my case, it showed that the company was storing my account information in cleartext to be able to e-mail it back to me. Needless to say, I e-mailed the head of their IT department explaining why this was unacceptable.
My questions are: How frequently have people run into companies sending sensitive information (like passwords) in cleartext via e-mail? and What would you do if this type of situation happened to you?
Not too long ago I had a similar experience when applying for a job online (ironically for an entry-level IT position). I was required to setup an account with a password and an associated e-mail address. While filling out the application, I paused the process to get some information I didn't have on hand and received an e-mail from the company that said I could continue the process by logging on with my account name and password, both shown in cleartext in the message.
In my brother's case, it was an auto-generated password but still problematic. In my case, it showed that the company was storing my account information in cleartext to be able to e-mail it back to me. Needless to say, I e-mailed the head of their IT department explaining why this was unacceptable.
My questions are: How frequently have people run into companies sending sensitive information (like passwords) in cleartext via e-mail? and What would you do if this type of situation happened to you?
Responses (Score:5, Informative)
"How frequently have people run into companies sending sensitive information (like passwords) in cleartext via e-mail?"
Not *that* often, but more often than you would think. (See plaintextoffenders.com - they've got hundreds of examples.)
"What would you do if this type of situation happened to you?"
What I do when this happens:
1. Take a screencap of the email, black out the username and password, and send it to plaintextoffenders.com
2. Contact the site admin, let them know that you just did that, and why it's such a bad idea. Link them to http://plaintextoffenders.com/... [plaintextoffenders.com]
3. Immediately change your password on the site to something stupid that would definitely not even *remotely* help an attacker guess what sort of passwords you might use on other sites, since if their password security is that awful, chances are their security is awful in other ways too.
Re:Responses (Score:5, Interesting)
"How frequently have people run into companies sending sensitive information (like passwords) in cleartext via e-mail?"
I see this and people sending both public and private PGP keys to outsiders more than I should from other companies. I assume it's because in general American businesses have devalued IT for so long that they're getting exactly what little they pay for now with barely trained and barely competent people who don't know anything about security.
Re: (Score:2, Insightful)
Re: (Score:2)
For the second example- so what? It's a one-time temporary password that you picked yourself. The risk of a compromise is minimal, the reward for a hacker is minimal. Is it poor security practice... maybe? But you have to weigh the cost-benefit ratio.
For someone who knows not to use the same password for multiple sites, it's a one-time temporary password.
For someone who DOESN'T know better, it's probably the same password they use for many or all other sites.
In this particular example, HOPEFULLY everyone applying for an entry-level IT position falls into the first of those categories. But if that site is used to collect applications for IT positions and other positions, the applicants for those other positions may fall into the second category and the s
Re: (Score:3)
What's your estimate on the time lost by all employees for dealing with such precautions? Try to document that, with proof, and get a meeting with your boss(es). After they see the money wasted on being over-precautious, IT will probably calm down a bit. Even a new password every month would annoy the hell out of me.
All the time for resetting a password. (Score:2, Insightful)
Really? Of course they will send you a reset password in email. The other option is that or a link.
Ideally it is only good for a single use and you then enter a new password.
How else would you do password recovery?
Re: (Score:2)
4. Report them to the Feds for a Federal Education Records Protection Act violation.
Re:Responses (Score:4, Insightful)
My site, on account creation, generates a password and sends it to you in email in cleartext before putting it in the DB. In that email is a link to reset the password; you can't log into the rest of the site until you've done so. The updated password (and the original) are stored encrypted in the DB.
If anyone has a better suggestion, I'm all ears.
Seriously? Let the user enter their own password at account creation and send them an email with a link (containing a random hash that's indexed to that user in the DB) to verify the email address (if that's even a necessary step... it isn't always).
Why would you need to generate a password for them, especially if you're going to email it plaintext and make them change it anyway? What possible benefit does that serve?
Re: (Score:2)
Why would you need to generate a password for them, especially if you're going to email it plaintext and make them change it anyway? What possible benefit does that serve?
For example, it prevents you to create a throwaway account with the e-mail address of someone else.
Re: (Score:2)
send them an email with a link (containing a random hash that's indexed to that user in the DB) to verify the email address
Did you read before replying?
Re: (Score:3)
What's that got to do with cars?!
Re:Responses (Score:4, Funny)
If you don't salt your hashes, you're less likely to rust the undercarriage.
Re: (Score:2)
Stop stalking APK, join the discussion or go away please.
Re:Responses (Score:4, Interesting)
Ok, here are some possible benefits over chihowa's proposal, for specific use cases.
- If the use case implies a system/"real" account rather than a virtual one (which I admit is a bad idea most of the time), the implementation practically comes for free: simply create an initially disabled account with a generated password. Particularly useful if the bunch of account creation doesn't actually use an e-mail account at all (say, university students accounts, with account names and initial passwords printed)
- You don't have to develop a different UI to differentiate account validation and regular password change.
- Some (web)mail applications are breaking URLs. Often times systems using generated URLs contain a link, plus a textual representation of the URL in case the link doesn't work (which usually means a text client), and sometimes some kind of pretty printer likes to add spaces after punctuation signs. With a short static URL and a password, you're minimizing copy/paste issues.
Re: (Score:3)
Not all accounts are created directly by the user. Half the systems I work with on a daily basis have no signup feature. Accounts are created by site admins. The most common way I see this handled is for the site to generate an OTP and send it via email to the user.
Re: (Score:2)
Re: (Score:2)
Real admins have macros. Every headshot triggers a script that creates a new account from a list (automatically built from incoming ticket contents of course).
Re: (Score:2)
I know of the doom version of PS for cou process deletion. But I didn't realize some made a counter strike admin portal. What happens when you tea bag some one?
It is "a random hash" (Score:2)
and send them an email with a link (containing a random hash that's indexed to that user in the DB) to verify the email address
But how would you encrypt "a random hash" on its way to the e-mail recipient?
Why would you need to generate a password for them, especially if you're going to email it plaintext and make them change it anyway?
Because this one-time random password serves precisely the same purpose as "a random hash" that you mention.
Re: (Score:2)
The idea is that the user set his password via (presumably) secure https. The purpose of the random hash is so that you provide the legitimate email user a transient secret that must be used *in conjunction* with the password they had chosen (or some session cookie sent via https to avoid making them log in twice when clicking on the email).
So here the password is to authenticate that the original person that accesses the site, the hash authenticates a valid email account. Both together are required to ve
Re: (Score:2)
This way someone intercepting SMTP doesn't get access to hijack account
Then how would a reset work? Or do all subscribers to your service additionally need to subscribe to mobile phone service on a supported carrier?
Re: (Score:2)
It would be bad form to reset the password when anyone clicked 'reset this accounts password' anyway. So until the link is followed, no action should be taken with regard to the account password anyway. This way a malicious person can't just denial of service a valid account by clicking 'reset my password'.
This means if an attacker is able to intercept your SMTP, they could still hijack your account through requesting a password reset at will, so it's not perfect, and yes some 2 factor authentication woul
Re:Responses (Score:5, Informative)
My site, on account creation, generates a password and sends it to you in email in cleartext before putting it in the DB. In that email is a link to reset the password; you can't log into the rest of the site until you've done so. The updated password (and the original) are stored encrypted in the DB.
If anyone has a better suggestion, I'm all ears.
Don't send the fucking password in plaintext.
Don't store the fucking password. If your database/application can read it, then it's decrypted at some fucking point. Don't fucking do it.
User creates account.
User provides password, username, email, etc.
You generate salt.
You generate a UUID (emailverificationUUID).
You create DB entry with username, email, HASH(password + salt), salt, emailverificationUUID, emailverified (0).
You email the user "Your account has been created, please click this link to verify your email address.".
Link contains the UUID. When clicked, the site performs normal login processes (prompt login if not logged in already) and then verifies that the UUID matches the UUID stored for the logged-in user, and sets emailverified to 1 for that user if so.
Re: (Score:2)
So how do you encrypt this UUID? And what do you send for a password reset?
Re: (Score:2)
The UUID is discarded on first login. Additionally, the UUID is useless without the password/credentials.
Re:Responses (Score:4)
[quote]So how do you encrypt this UUID?[/quote]
You don't. It's just a GUID or some other low collision rate hash.
[quote]And what do you send for a password reset?[/quote]
You send them a new UUID in a link. When the link is hit, the UUID resolves back to their account and they are directed to enter a new password, just like a first time user.
The combination of time (the UUID can be time boxed), activity (a successful login nullifies the UUID), and possession (control of the account's registered email address), and if you want to get really wild, knowledge of a security question, creates a scenario where there are no good purely technical solutions for the attacker.
An attacker could, in theory, create a colliding GUID for an account they know the name of (but not password), manually enter the UUID link, and set the new password (assuming there is no security question).
But if an attacker manages to consistently generate colliding GUIDs*, they have accomplished something so monumental that they should be heralded as the second coming of Steve Jobs or something.
(*Assuming the coders didn't decide to come up with their own GUID generation algorithm that is easily reverse engineered and seeded)
-Rick
Type 4 UUIDs (Score:2)
The combination of time (the UUID can be time boxed), activity (a successful login nullifies the UUID), and possession (control of the account's registered email address)
My concern is how to keep someone between your server and the subscriber's MUA from compromising "possession", or how to establish "possession" the first time.
Assuming the coders didn't decide to come up with their own GUID generation algorithm that is easily reverse engineered and seeded
I just use a PRNG [php.net]. If I need it as a GUID, I request 120 random bits and format them as a type 4 UUID [wikipedia.org]. Is that good enough?
Re: (Score:2)
My concern is how to keep someone between your server and the subscriber's MUA from compromising "possession", or how to establish "possession" the first time.
If you follow the same model with account creation, then you already have possession established. If someone compromises your email account, and knows your user account for this site, and knows your security answers, then yeah, you're borked. But if someone has all of that information already, I'm pretty sure you've been borked for a while and in significantly worse ways than someone having your college transcripts. ;)
I just use a PRNG. If I need it as a GUID, I request 120 random bits and format them as a type 4 UUID. Is that good enough?
"Good enough" is a question that is best answered by the asker. Security isn't a Boolean i
Re: (Score:2)
The difference is if you generate a
Re: (Score:2)
Or to put it shorter: "Passwords and password reset codes go in separate fields."
I've implemented a similar system that keeps the hashed password and the one-time-use code in separate fields of the user table. I just wondered if there was any good way to protect the "login ticket" (the mail containing the one-time-use code) from interception in the 24 hours between when it is sent and the expiration time that we store.
Re: (Score:2)
I just wondered if there was any good way to protect the "login ticket" (the mail containing the one-time-use code) from interception in the 24 hours between when it is sent and the expiration time that we store.
For account creation, you can do this by requiring that the user authenticate with their username and password to use the "login ticket". If they know all of the authentication details and have control of the email account, there's really no way to distinguish them from a legitimate user (from your limited perspective). That said, acquiring all of the account details (including the password) and gaining access to the user's email account in a short time window represents an attack that's only likely for an
Re: (Score:2)
No encryption -- generate a random string and store it in the DB as associated with the login id. All you care is that the user with email X receives the email and can provide the random string.
Re: (Score:3)
So how do you encrypt this UUID?
You don't need to. Paranoid about it? Wipe the UUID field from the database upon successful verification of the email so it can't be queried against in the future. However it would be better to just do a sanity check in the code that if there's a boolean 1 in the "emailConfirmed" field after querying for the UUID, just notify the user that the account has already been confirmed and doesn't need to be again.
And what do you send for a password reset?
An email to the address on file that has a link to the password reset possibly pre-filling the userI
Don't encrypt! (Score:2)
Don't ever store passwords (reversibly) encrypted. Don't even (just) hash them; hash functions are way too fast (and yes, fast is bad here). There should be no way for anybody to get the password out of the info stored in the database, even if they know all your keys.
Use a slow key derivation function instead. PBKDF2 is popular, because it's easy to understand and widely supported; it's basically just taking a value (the password), salting it (you are using a strong, cryptographically random, per-user salt.
Re: (Score:3)
There are actually valid reasons for using two-way encryption in some scenarios. It's not ideal but it can be quite secure if managed properly. For example, most privileged user management systems and password escrow systems need to use reversible encryption. There are also reasons to do so in certain credential synchronization/SSO scenarios. Yes, just dumping encrypted passwords in a database is a bad idea. However, done right you can have two-way encryption and maintain security.
Not 100% of Internet users have unlimited SMS (Score:2)
If you want a bit more security than this you could do something like text the user the token instead of baking it into the URL.
But how do you send a text to the number "I don't have a cell phone" or to a land line? I tried to send the code to a land line on a couple sites and got "Unsupported carrier".
Simple (Score:5, Insightful)
What would you do if this type of situation happened to you?
I'd continue using different passwords for different accounts and not being a whiny bitch about it.
Re:Simple (Score:5, Insightful)
Don't mod down the angry bro just because he uses bad words.
The only safe assumption is to assume that no one handles passwords correctly. So you use a different password for every service. Use a password manager and let it generate random passwords for you.
The question one then to answer for themselves is if I assume they are not properly handling passwords, how much personal information is one willing to provide. You're on your own for that as everyone values information differently.
Re: (Score:2)
I assume that you speak of the word bitch in his post. I would like to point out to you that a female dog is a bitch, and yes, bitches whine.
This happens all the time (Score:2)
FAO auditors the information + company regulator? (Score:3)
If the company is big enough to have an auditor - and that's pretty small - they should be informed
If it's a European company, then the Information commissioner https://en.wikipedia.org/wiki/... [wikipedia.org] or the equivalent should be notified. This is clearly unsatisfactory behaviour
Comment removed (Score:5, Informative)
Re:Pearson is guilty of this (Score:5, Interesting)
One of the last companies I worked for was undergoing a single signon project. In their presentation they made it quite clear that they were actually encrypting passwords with a two way function. After the main presentation I pulled the presenter aside and asked why when hash functions are the industry standard.
His response was kind of hillarious (and kind of sad).... too many IT managers were afraid of the repercussions of not being able to actually recover an executives password if he actually lost it and had used it for something important that couldn't just be reset.
It's most likely a sign of code age... (Score:2)
It used to be scarily common, but I believe that it's slowly phasing out in favor of hitting a website where you can (re)set the password yourself after a couple of security questions.
I believe it's just a sign of old code (or an old coder) on the site. There may be cases where the guy writing the sitecode is inexperienced or incompetent, but I like to think that such cases are rare.
I think I only see a cleartext password sent via email like once every 10 requests now.
Re: (Score:2)
It used to be scarily common, but I believe that it's slowly phasing out in favor of hitting a website where you can (re)set the password yourself after a couple of security questions.
I believe it's just a sign of old code (or an old coder) on the site. There may be cases where the guy writing the sitecode is inexperienced or incompetent, but I like to think that such cases are rare.
I think I only see a cleartext password sent via email like once every 10 requests now.
Hey, watch it pal. I was born and raised on '12345' and it's always worked out great for me. Now get off my punch card machine, er, I mean, lawn.
Re: (Score:2)
(insert South Park pal/buddy/guy/friend reference here)
(insert Spaceballs reference here)
KeyPass (and similar) (Score:2)
Security (Score:4, Insightful)
Your first example is acceptable in my opinion, as that password was probably random and (essentially) single use. After logging in, you should immediately change the password to something you can remember.
The second example, however, is a big no-no in my books. I develop web based applications for a living. The only time we send a password over e-mail (or SMS) is when a user has locked themselves out of their account, and are using the account recovery tool to regain access. This is how we handle it:
1. Click on "Forgot Password"
2. Enter your e-mail address (and username if different from e-mail address), click "Begin Recovery"
3. Send an e-mail with a verification URL for them to continue the process, this is to confirm they actually are the owner of the email address, and also to weed out people trying to use the recovery process maliciously.
4. Upon following the URL you will be prompted to answer two security questions you set up on registration from a set of predefined questions. You must answer both correctly to proceed. Internally, when this URL is hit, the account in question is flagged in the DB that it is now in Recovery Mode.
5. Upon answering the questions correctly, you will be e-mailed a single-use password you can log in with.
6. Upon logging in, you are required to change your password to something you can remember (or store in a password DB, like you should be doing).
I know it's long and cumbersome, but it works.
Re: (Score:2)
4. Upon following the URL you will be prompted to answer two security questions you set up on registration from a set of predefined questions. You must answer both correctly to proceed. Internally, when this URL is hit, the account in question is flagged in the DB that it is now in Recovery Mode.
That one would leave me out. Given how "security questions" have been handled in the past, i.e. to be anything but, my response to that sort of thing is to type in random text and usually a lot of it. I also don't see how it increases the security. If the email address of the user has been compromised, it is likely that the intruder would have an easy time finding the correct answers to the questions. In your example, there is actually also no need to send a password to the user. If the questions are answer
Re: (Score:2)
I see your point. We make it abundantly clear what the security questions are for upon registration, and encourage the users to answer correctly. The questions we ask are not something that would normally be found in a users inbox, and most average users do not index and archive their e-mail. I do, personally, but I archive anything older than 2 years locally on my workstation(s).
We'll consider the idea of skipping of sending a new password to the user. Thanks for your input.
Facebook defeats security theater questions (Score:2)
The questions we ask are not something that would normally be found in a users inbox
A lot of time, the answers to security theater questions are things that would be in a user's Facebook timeline, such as the name of the middle school that the user attended.
Re: (Score:2)
Re: (Score:2)
Not necessarily in these days of social media... A lot of people have Facebook accounts and will have added relatives or people they went to school with...
For your example, you already know the school, so you find out a list of their teachers (often published online) and try them all, and if the attacker knows your age they can narrow it down further... Either way there's a relatively small number of possible answers.
Re: (Score:2)
Model of first Vehicle -> Futurama
Where did you get engaged -> IsaacAsimov
Name of first grade teacher -> polyamory
Favorite book -> Ethernet Cable
and so on.
Re: (Score:2)
Re: (Score:2)
OTOH, I don't even remember who my first grade teacher was.
Re: (Score:2)
And your method won't work if somebody "fixes" the question because of a typo/change of phrasing/to make it clearer/whatever reason.
Re: (Score:2)
Use a password manager.
For secret questions, make up an answer, note the answer in your password manager.
Good luck with monitoring emai
Give Obama's answers to security questions (Score:2)
You're right that it's normally easy enough to find the answers to questions like "what high school did you go to?" I make that much more secure by secretly replacing "you" with "Barak Obama".* I don't enter MY high school, I enter Obama's. I enter Obama's mother's maiden name. So anyone who goes on my Facebook** to get answers will get wrong answers.
* I actually use another famous person, not Obama.
** You won't find much on my Facebook page, because I don't use Facebook. But if I did, it wouldn't sh
Re: (Score:2)
Security theater questions (Score:3)
Send an e-mail with a verification URL
How do you encrypt this unique verification URL on its way to the subscriber to your service?
security questions
I'm sorry; I misread this as "security theater questions" [wikipedia.org]. See "The Curse of the Secret Question" by Bruce Schneier [schneier.com] and "Wish-It-Was Two Factor" by Alex Papadimoulis [thedailywtf.com].
Re: (Score:2)
There's generally no way to send the user a secure (i.e. encrypted) message. All you can do is make the token short-lived and hope that nobody is intercepting server-to-server email traffic (and that the user's email account is secure, both from malicious clients and from server-to-client interception). It sucks, but until email encryption of one sort or another becomes more ubiquitous, it's the only workable option.
Re: (Score:3)
You haven't been developing web apps very long, have you?
Steps 5 and 6 are horrible from a UX perspective and actually lower security a tiny bit.
By emailing out a single use password you make it possible for someone to eaves drop on the email train and login to your site using the single use password that you sent over email ... in clear text, over a system that may end up easily being stored on disk and snoop-able on many computers.
There is absolutely no reason to email them the password, you've already ve
Have to do this all the time. (Score:3)
In ham radio command and control over remote digital ground stations all have clear text passwords because it's against the law to encrypt on ham radio bands. So every password is a single use.
Today, if I connect to the digipeater that is near me I will use the password S4tA12fDg
and it will work once and only for a certain window for that single login to happen.
Any company worth anything would do the same. Here is your link, here is your one time use password, you had better get the file in the next 20 minutes or that password will not work.
Perfectly secure for simple crap that really has zero value like a school transcript.
Re: (Score:2)
No, it isn't, at least in the US. It's illegal to use transmit "messages encoded for the purpose of obscuring their meaning," but the meaning of a password exchange is not obscured when it's encrypted. The meaning is user authentication, not the actual text of a password.
Re: (Score:2, Interesting)
I just thought I should clarify this a tad bit for non-hams. (but the rotating password you provide is a good way to go)
It is not permissible to encrypt the message in a way which obscures the meaning, but can in a non-obscure way to verify the user is authorized. This is still not common, but possible. One such method with digital modes is to have the user use a private key to sign the message, and the control operator maintaining the station can have the corresponding public key. In a fashion similar to E
I used to see that all the time (Score:5, Interesting)
Before NMCI came along, I was tasked with taking over a mapping application for the Navy and discovered the app was sending admin credentials in clear text in the URL string. Instead being of grateful I found the obvious sloppy coding they accused me of trying to pad my billing with make work and blaming the previous programmer. When I explained their application was crap and a giant security hole they would say, "Well, it works for us."
So I totally understand how apps like that make it online.
FAO of inspector general - copy to Congress (Score:5, Interesting)
Re: (Score:3)
Whistle blowers are prosecuted vigorously and do not get the benefit of the doubt.
When dealing with a government entity you should probably do nothing, as the risks outweigh the rewards at this time. If you still feel like speaking up, raise the issue with your boss in one email, carefully and politely, and file a hard copy of the email somewhere safe. Do not go up the food chain, do not go to the press. If there is a crap storm the hard copy may save you, but even that is not assured.
The default positio
Re:FAO of inspector general - copy to Congress (Score:5, Informative)
If you point out government waste or find out that the security practices required by the government contract were not met you can actually receive a % payment for the value of the difference won back in court. Try and work that route instead of just whistle-blowing. If you find the government was over-billed for services that weren't rendered (i.e. security) then you have a real case and there are official channels through which you can work.
Concern not warranted (Score:3)
If you check with black hats, you will noticed that there are two tactics that they use approximately never:
- network packet sniffing, and
- break-ins to email
What they're saying by this is that passwords sent in the clear are not an interesting target.
Just trying to bring this conversation back down to earth.
Re:Concern not warranted (Score:5, Informative)
Re: (Score:2)
Re: (Score:2)
Really secure systems use HSMs (https://en.wikipedia.org/wiki/Hardware_security_module )
This means you can't steal the key from a live system.
Re: (Score:3)
Re: (Score:2)
Right - the "head of the IT department" was like, "OMG another self-righteous clueless nerd who doesn't understand risk analysis."
There is something that needs fixing here, though - the OP needs to get counselling for his control issues.
never reuse passwords (Score:2)
It's your only defense. Once a password is sent in the clear it's ruined for other uses. So you must assume this will happen and never reuse one.
Re: (Score:2)
Generally the passwords I reuse are the ones that don't matter much. If someone cracks my /. pw, they might have the access to several unimportant accounts, but not my main email or banking accounts, all of which are unique.
Passwords (Score:3)
1) Treat them like worthless things - only having them to satisfy those weirdos that want something called 'privacy', whatever that is. What the hell, use the same default 123 for all passwords.
2) Here is your top secret password. It must be 23 digits long, have symbols, letters, cyrillic characters and at least one unicode symbol whose name you don't know. Nothing can EVER be repeated, and it must change every 60 minutes. Also do NOT write it down - even though these conditions mean you absolutely have to write it down in order to remember it.
Honestly, you are talking about your transcript for a University. I can not honestly think of a situation where someone that you don't want to see it would care enough to see it - unless you yourself are planning on committing fraud.
If I was in charge (and I am not), the university should not use a password. They should let ANYONE see your transcript - but also notify you that someone has requested to see it.
Re: (Score:2)
I assume the password was for decrypting a password-protected PDF. Just a guess.
Re: (Score:2)
Instead, it's the real legal prosecution that would follow anyone attempting to claim they are him, and/or get it. Because I absolutely guarantee that people could crack whatever password protection they use to protect it.
policy (Score:4, Interesting)
You don't control the security policy of most things that you need to interact with.
You should be assuming that every single site that is not under your direct and personal control is doing the same thing. Even if they swear that they are not.
Every password that you give to a remote system should be a unique random password given only to that system and saved in your personal password safe.
The one exception is having a common password for things that you don't care about. The trick to taking advantage of the exception is making sure that you really, really don't care about any of the systems in that category, and never will.
Happened to me once with a magazine subscription (Score:2)
Re:Happened to me once with a magazine subscriptio (Score:4, Insightful)
They didn't salt and then hash their copy of the passwords - they are still stored plain text. They just stopped including it in your email.
Re: (Score:2)
The KDE mailing lists do this.
Maybe not... (Score:2)
In my case, it showed that the company was storing my account information in cleartext to be able to e-mail it back to me.
You don't know that for sure. It's entirely possible that the password was generated, sent to you in the clear, stored hashed and the clear version discarded. They can only do that once. If they can do it more than once, it's not being hashed before storage.
The problem with passwords is that at some point, it has to flow in a form it can be read by a human. We're not to the point where everyone on the planet can do everything with key pairs that prevent it.
Hard Problems (Score:2)
"Don't you know my name yet? That's the only answer. Tell me, who are you, alone, yourself and nameless?" — Tom Bombadil in Tolkien's Lord of the Rings
"There are only two hard things in Computer Science: cache invalidation and naming things." — Phil Karlton
This is one of the true hard problems in modern end-user computing, and it comes up all the time. What do you do when you get a phone call like, "hi, this is Don with $MORTGAGE_COMPANY. For security validation, please tell me your address."
Ho
Obfuscation by Social Engineering (Score:2)
I use "[password redacted]" for my password for this very reason!
Re: (Score:3)
The best password: ********
Re: (Score:3)
That just shows up as asterisks here...
Yep. I can type in my password all I want and you can't see anything but asterisks. So I can hunter2 all I hunter2 want and you can't hunter2 it
How else are you going to do it? (Score:2)
This is not a new problem. For the entire history of secure information transmission (cryptography), one of the hardest issues to solve is the issue of initial secret (key) exchange. This problem has been around a lot long
Comment removed (Score:4, Insightful)
A URL is not a link? (Score:2)
I thought a URL was a link, what other kind of link are you referring to?
Re: (Score:3)
In 2015, passwords should be stored in a one-way hash. Preferably in the PBKDF2 format.
Re: (Score:2)
There's better options than PBKDF2, like scrypt. Also, both require you to chose some parameters; PBKDF2 with a salt of String.Empty, hash algorithm of MD5, and iteration count of 1 is... just an MD5-hashed password. Obviously, those are terrible and stupid parameters, but if people were *good* at choosing secure options then this whole thread wouldn't exist. At least scrypt *only* has the work factor, and it's pretty straightforward.
Re: (Score:2)
If the password can be retrieved in an automated fashion then even if its encrypted, everything necessary (i.e. the key) is present, so if the host is compromised the passwords effectively are plaintext as the attacker can simply run the same process to decrypt the password.
And even if you use SSL to check your mail, that doesn't change how the email has been transmitted from one mail server to another, which is often done without using SSL, and most mail servers will fall back to plain text even if they do
It's to confirm control of your e-mail address (Score:2)
In the message the portal not only assigned my username, but it also listed a temporary password that's good for 30 days! All of this transmitted cleartext.
This use of a one-time, soon-expiring autogenerated password is common in flows that include the step "To reset your password, confirm your e-mail address" or "To opt in to e-mail notifications, confirm your e-mail address". Is there an alternative, other than to either A. mail all customers a second factor of authentication used to reset a password, or B. require all customers to subscribe to mobile phone service with unlimited texting to receive resets through SMS?
Re: (Score:2)
Or you can use pdftk to remove the arbitrary pdf restrictions and get a plain normal pdf file out of it...
Re: (Score:2)
That is Mailman [gnu.org], and is fixed in Mailman 3.
Re: (Score:2)
Get your passwords out of the DB and into and decent LDAP directory. It's really not that complicated and it will scale a lot better. As you can tell from my user ID...it's what I do.