Hi All,

I forgot my password to RPOL recently, and was stunned to find that you send forgotten password requests via clear-text email.

Given that most users don't use separate password for separate sites, this is a pretty scary security hole; anyone able to observe traffic on the RPOL servers (not as hard as it sounds) can read out user passwords and email addresses.

There are two security issues here:
1) You should not store the password in your database, since if the database is compromised so are all of the passwords (instead, store the SHA-2 value of the password; for authentication, take the SHA-2 of the password the user has provided and compare them).

2) You are sending user passwords and email addresses in clear text over the internet.

This is really concerning given the number of users RPOL has - there is a pretty large financial motivation to break into your system.

I'm forced to agree with Daniel.  A much better policy if someone forgets his password, is to reset his password to something random and send him the new one.  The values you have stored should be a string that is generated from the password in a one-way encryption, so that you don't even know, nor could you generate any user's password.  (But, given the password, you could generate the encrypted value which you compare to the stored value.)

There are public domain algorithms for this, including SHA-2.

I'm neither here nor there on the above suggestions, but I do highly suggest that no one use their "secure" password that they use for banking or other important access to access other sites on the internet, no matter what they are.

Not only is your password sent in email in clear text but here at RPoL, and at any site you log into that doesn't use secure http (which is nearly all of them since the certifications are expensive), your password is also sent plain text over the internet every time you log in.

(This is why sending it to you in email has never been thought of as that big a deal, I would figure, since you send it to us exactly the same way when you create your account or log in to the site.)

So: to shorten my advice, never use the same password you'd use on a site that uses https as you'd use on one like RPoL that uses mere http, if you do care about these things.  I'd warrant that for those using webmail, even your webmail is not secure http.
This message was last edited by a moderator at 02:18, Wed 21 July 2010.

I would have to agree with all of the above myself.

It's not much (if at all) more difficult to get a password from the login request as it is to get it from e-mails being sent out (and stealing it from a database seems more difficult still, as it requires more work than just monitoring traffic), so RPoL can hardly be blamed for a stolen password in that regard.

That being said, other than the inconvenience of changing the websites code, there's no reason that passwords should be stored unencrypted. And even if they are unencrypted, there's no reason not to generated new random passwords during forgotten password requests.

There are some things the end user cannot control, and those are both such things.
This message was last edited by the user at 03:38, Wed 21 July 2010.

I have to side with Cruinne in the sense that you should have noticed that you were logging into a non https site long before you were surprised that it emailed your password to you in clear text.

In general, using the same password between sites, besides commonplace is bad practice, as unless you know how they do security, it is very possible they are storing the password somewhere that some people including hackers could potentially get to some day to your surprise.

But, if they did go the route of using SSL, I would agree that a more secure method of password resetting (account retrieval) would be in order.  I can see how it might be good in a way, to change the current method so it doesn't reveal the currently used password, and simply forces a change, but people REALLY shouldn't be using the same password for a site like this.  If anything, (and it has been too long since I set it) there should be a note, not to use the same password as any other important site.  That might be the easiest improvement to security with the least coding.  [I'm assuming it doesn't already say it which it might, I know I thought it already as soon as I noticed I couldn't go to https: as an option]

So how can we change our password (if we needed to), I don;t see anywhere in user prefs or anything to do that.

User preferences. (top left, main screen)

Change your user details (bottom left, above TOU link)

Thanks, think I went temporarily blind or something just then. No idea how I missed that.
This message was last edited by the user at 06:06, Wed 21 July 2010.

I should likely also note I have never in my decade on RPoL, or in my too-much-more-than-that time I've run another site which uses plain-text logins over telnet, experienced a case where someone's account was used by someone who got their password by packet sniffing or the like.

In every single case, it was "I trusted them, so I let them have my password" or "I didn't think my s.o. would delete all my stuff, so I left my password saved to my client."  Each and every case has been the user being careless with the password, which is really a much easier way to obtain one than playing super-spy and trying to get one off the actual transmissions between the site and a computer.
This message was last edited by a moderator at 13:57, Wed 21 July 2010.

Right.  The issue is not that somebody is going to use a high tech solution to hack into someone's RPoL account and mess with their games.  (What kind of moron wants to mess with someone else's games, anyway?)  It's that they are going to get their RPoL password and try that same password against the person's bank account.  For some number of people (not you, not me, hopefully not anyone who has read this thread), that technique will work.

Actually, to me, I see the larger problem as getting the RPoL password from having access to the person's e-mail.

Simply leaving your e-mail up on your computer, an iPod or iPhone, etc. and it wouldn't be terribly hard to find the RPoL website and request a forgotten password (that will come to you as a plain text original password!).

And I HEAVILY agree with Cruinne that the chances of anything like this happening are minimal and almost certainly entail poor choices on the user's end.

But why take the chance with something like user's passwords? Recoding things can be a pain. I know, I program in PHP quite a bit. But if there is anything worth updating ever, it's security.

You know.

Having worked in account retrieval/security for something which has a lot more money attached to it than RPOL.

I feel exactly the same Bregard.

Except, I feel it's the user's responsibility. After all, it's their stuff that's at risk.

The importance is high. But why does that make it a coding issue rather than a personal one?

To be honest... a password reset process would be far better... it for instance makes the person aware something may have happened themselves as they can no longer get in using the password they are sure they were using.

So if Jase has a robust safe password resetting system for allowing people to reset their password by getting an email and resetting the password, great.  I do however hold the individual mostly responsible at this point, so I wouldn't necessarily pull Jase off of some other project to work on this.  However, if someone provided him with a method using tools he uses that he understands, and could implement easily, great.  However, I wouldn't want to make sure there aren't any exploits built into the process.

Other than time put into the coding, why not change the code?

I agree with you that users should own up to their responsibility, as there's almost no way their password is going to get stolen (even with the current system) without some act of negligence on their part.

But, while I won't call it an act of negligence (haven't I mentioned lately how much I appreciate how much work everyone does for RPoL? =D <3 ), the users also wouldn't have a risk of loosing their password if it weren't possible to get the password e-mailed.

So, I guess in summary, yes, you're right, users should be conscientious. But is there any good reason other than effort that the website shouldn't be conscientious too?

If anything, I hope this gets put on a list of things to do, as it seems like a worthwhile change to me.

I'm only familiar with PHP myself, but would be happy to provide some code that could be utilized for this purpose.

While I understand the concern that if someone has access to your email account they can see your password then log into your RPoL account, I wonder how that's different to any other scheme which uses your email to verify who you are and to reset your password.

Anyone who has access to your email account also has access to those.  And if you're using the same password on your online banking as in RPoL, I'd bet they already know it because they used it to look at your email (where you also used it).

I suppose the work-suggestions for jase are simply for the sake of those who (a) use the same password for all their online accounts from banking all the way to RPoL, and (b) somehow manage to let someone else access their email account without actually letting that mysterious someone know their password to it, on the same occasion that (c) they've forgotten their one password (which they use everywhere), and had to ask RPoL to email it to them.

It sounds a little silly, I guess, but I might be unimaginative.

My suggestion in the minimal-work-for-jase category would be to put a note on the account creation page, and on the User Preferences password area, reminding people they should use a unique password no one else know and, for the love of all that's sane, not the same one they'd use to access their email or bank account.

The primarily difference is, they can only reset your password, they can't know what your password was to begin with.



Not true. It wouldn't be terribly difficult for someone to steal a person's iPod or iPhone and use their mail app to check their e-mail (without needing a password). Gathering passwords at that point could be a goal, and RPoL's password retrieval would be perfect in assisting them.

Once again, I'm freely admitting to the unlikely  hood of this, and to any danger of a stolen password even in this manner having some blame on the user for reusing the password else where.

I merely question, why down play the importance of protecting users? Why not take some measures to help them?



I agree with you, up until (c). It isn't necessary that the user requested their own password. It's only necessary that they have an e-mail from RPoL already. At that point, it's not reasonably  hard to imagine someone intent on getting the user's password to go to the RPoL site, request the forgotten password, and then getting it in plain text.

Once again, I freely admit to the improbability of this happening as a whole, and the user's culpability in allowing it to happen (both by compromising their e-mail, and by reusing the password), but that seems like a sketchy defense to not have some security in place at RPoL.

Resetting the password is hardly (if it all) more inconvenient to the user, and it's immensely safer, so why down play the benefit?
This message was last edited by the user at 04:01, Fri 23 July 2010.

So, we're considering someone important enough to have an account worth taking and an iPhone that has their RPoL password saved in it and someone who knows this important person well enough to try to recover their RPoL password using their saved email password on their iPhone and this person uses the same password for their bank account?

It sounds like an inside job -- I think this person needs better friends.

I think the more likely scenario being... someone has a device such as ipod set to get their email.  They misplace or have such a device stolen.  They look at what where the user had favorites, and find RPOL and decide to look around.  They find out that the site will email them the password so they do, and take that password and nose around a couple other favorites like their bank account.

Granted in this example, it is possible the bank might allow you to reset your password via email, but a lot may require additional information, so they are right... if the person who stole of found the ipod was so inclined and happened to get it from someone who had the bad habit of using the same password [or something in the same vein that once you know one, you might be able to guess the rest] then their RPOL hobby has placed them at an additional risk.  If all it did was offer a link to reset the PW, the finder would be no better off other than being able to reset the password to keep the owner from getting into RPOL until the re-reset the password.

Sorry, I still don't understand the problem.

RPOL doesn't show the password. So even if the account was logged in, they wouldn't be able to see it.

RPOL sends the existing password to the registered email address. But doesn't tell you what the email password is. So the person who's picked up the device couldn't access the RPOL password unless they knew the email password too. Or unless this hypothetical person also kept this device saved into their email.

In which case, aren't there bigger security issues at risk than the password for a roleplay site?

Like the user's willful refusal to take any responsibility for their own safety?

In a perfect world you'd be right saying "it's all the stupid noobs fault". In a perfect world there wouldn't be any need of passwords in the first place.

I don't know why it is so hard to understand that sending and storing clear text passwords is an additional and unnecessary security risk and that closing this hole is worth a little effort. "The user is stupid" is one of the fundamental rules of computer security. You can't ignore it.

I'm neither a cracker nor a security specialist, but I can think of a couple of scenarios where this would be relevant.

1. A sent password appears in several locations (network traffic, memory, email browser, hard disk, backups). You'd only need a minute of access to someone's computer (or phone, or younameit) to extract this information. How many users are there who have never left their device unattended for minute, so that someone could have accessed it?

2. The passwords are stored in clear text in a database table. I'd say is a very attractive target for a hacker. And said table could easily be stored somewhere where it could be publicly accessible. For example a backup could be stored on a private computer or could accidentally be left on a hard disk. There are prominent examples for this kind of thing happening (like Amazon or the Pentagon, if I recall correctly).

Yes, there are other ways to snoop passwords and yes, the user could and should prevent anything bad happening from RPoL's current behavior with small to moderate effort. But providing a little bit more security with very small effort is not asking much. I'm sure every halfway-decent database system provides password hash functions and resetting a password is a few lines of PHP code.

So, Jase, pretty please change this as soon as possible. Thank you.

Given that the site has been running as it currently is, with no problems of hackers or the like in the past, for the past several years, why would this suddenly be such a big thing that needs changing now?

Just make sure the password you use for RPOL isn't the same as any other password. If you do use the same password, and you get hacked, it's your own fault for not following one of the most basic tenants of internet security.

This. I'm all for placing blame on users when they make the stupid choice of reusing a password for multiple sites.

But to use someone else's mistake as an excuse for one's own mistake (IE. sending a user's password in plain text) is just... baffling.

Probably the most stressed thing I've ever seen in web development is security. Every book I've read has been jam packed with information on how to make things more secure. Every programmer I've asked help from always emphasizes how to add security (and I've been a regular at PHP freaks myself).

To see a website built that shrugs off their own security problems as the "user's fault" - regardless of the truth of that statement - is honestly dumbfounding.

I appreciate RPoL immensely and am really grateful to play here - I'm merely blown away at the fact that fixing an obvious security flaw has to be defended. I mean, really?

(PS. As it's been pointed out repeatedly, having the e-mail password is NOT necessary! There are literally dozens, perhaps hundreds, of devices out there that automatically store your password, including iPhones and iPod touches - once again, this is not the user's fault, especially if such a device gets stolen. You can place the blame on the user if you want to, but you're still ignoring your own blame if a password is stolen because RPoL sent it in plain text - I still haven't seen 1 good reason why this is being ignored).
This message was last edited by the user at 19:11, Sat 24 July 2010.

You do know quite how many sites do that, right? It's not unusual at all.

Plus, ultimately, this is a free site that jase lets us use. It's not like we're paying him to do the coding and stuff, so he has his own IRL job to do, which has to take priority over RPOL. If you don't want to have your password sent over e-mail in plain text, no one is making you come here.

Me? I'll just stick to using a unique password for RPOL that is different to every other password I have for every other site, and make sure not to have various apps store my password (which I make sure to do anyway). It's easier to do than it is for jase to do a load of recoding, and makes me pretty much as safe as all that recoding would do too.

Actually, this is the only website I've signed up to that e-mails passwords in plain text.

I know of one other site I use that stores passwords in plain text, but it's a server run by the US department of education.



Which is why I've offered to help build something they could try to adapt to the RPoL website.

Doing so would not require any special access to the site on my behalf, so no security risk, and would save jase or anyone else the trouble of doing it themselves.



That's great for you, but not everyone else is going to do that. Why should RPoL take that risk? Everyone seems to be avoiding this question, I wonder why?



I think the amount of recoding is a bit exaggerated. A password reset script is relatively easy to write. In fact, the hardest part of the whole thing will be adding a database column (or table, if that's really necessary) to store a temporary "code" (string of random letters and numbers) that is used in the URL to allow for a password change.

I'm not sure what database RPoL uses (and wouldn't really need to know), but if it's MySQL or almost any other SQL database, adding a database column or table shouldn't be terribly difficult or require much (if any) down time.

I'm fine with that answer as things stand, without any hesitation or equivocation.

This is a free to use site, there is no realistic way I can be defrauded by access to my account inappropriately.  There's no practical way of ensuring that any of the information I have provided, other than an email address, is genuine, so it's data with no value.

However, the moment the planned subscription model is in place my position changes absolutely and without room for negotiation.

At that point the passwords will have to be irretrievably unavailable to any staff member of the site (volunteer or paid, I don't make a distinction).  Passwords will absolutely have to be stored encrypted, compared encrypted, and the result of a "I've forgotten my password" will need to be a reset, not a reminder.

Until that time, requiring this alteration is an unreasonable imposition on Jase's time, in my opinion.

After that time, not having this in place is an unreasonable imposition on those who will at that point be supplying financial information and almost certainly genuine, accurate, personally identifiable information, and at that point that information needs to be strongly protected.

In reply to mananan (msg #25):

And it should be pointed out that, at this stage, we don't know how we're going to be handling subscriptions, so any speculation on the subject is just that - pure speculation.

Security for financial and personal details may, in fact, be entirely moot.

There are plenty of sites out there that are already set up to handle financial transactions without passing on sensitive information.  Perhaps RPoL does not actually need to duplicate their efforts.

If we accept payments via PayPal, for example, they would just send the payment and a message.  If that message contains the subscriber's user name, then we would know who had paid for their subscription, without ever knowing their credit card number or any other personal details.  This is exactly how donations to FoRPoL currently work.

Edit: which is not to say that we would accept payments through PayPal.  It's just an example of a third party service which already handles that sort of thing.  There are others.
This message was last edited by a moderator at 22:54, Sat 24 July 2010.

Everything Bregard said and in addition



I'd like to make it clear that I didn't "require" jase to do anything and that this is neither an "imposition" (I had to look up this one in a dictionary) nor "unreasonable".

Isn't it?  You'd be going from a system where data is stored as data like all the other data to one where some data has to be futzed up (and otherwise introducing additional overhead).

Not at all. One way encryption is a very simple process. It shouldn't add more than a couple lines of code, if even that much.

Converting everything over would require some work, but once in place, the webpage would operate almost identically to how it does now, no additional overhead.
This message was last edited by the user at 02:58, Mon 26 July 2010.

Uhm...

After reading a fair bit

-1

On committing recources to the access code change. We are a hobby site not an international bank.

Given the complete lack of any financials on this site, anything beyond simple security is a waste of time.

As mentioned countless times, if someone has access to your primary email, they're going to do a lot more things then crack your RPoL account.

They're going to hit paypal, they're going to hit your favorite MMO to sell all your hard earned stuff for cash. They're going to hit ebay or paypal or what not.


They are not going to care at all about your precious rpol games.

The only way for someone to steal your password is to already have access to your email.

Once financial info is up and running, yeah RPoL needs to crack down on it, but until then it's pretty ridiculous to get worried that evil hackers are going to delete your pbp game :D

Well, to be fair, the original poster's scenario wasn't about hacking an email account, then using that to recover an RPoL password but rather the opposite of that -- getting an RPoL password then using that to gain access to the email account.

The scenario was about someone hacking the RPoL servers then using the emails and passwords from that in a mass attempt to gain access to as many email accounts as possible (presuming that most people foolishly use the same password for everything).

Actually, it wasn't.

It was about using an email account to get an RPoL password, and then using that to gain access to bank accounts because of poor personal security practices.

No mention was made of hacking the RPoL server.

I'm pretty sure he was talking about hacking the RPoL servers ("observe traffic on the RPoL servers ... if the database is compromised so are all of the passwords"), then using the stolen RPoL passwords from the hacked RPoL servers to attempt to gain access to the corresponding email accounts ("given that most users don't use separate password for separate sites").