Groundspeak stores the password unencrypted in the database?

January 15, 2010

hi there,

yesterday i noticed that it looks like Groundspeak is storing the user passwords unencrypted in their database - the password recovery function mails the pw in plaintext.

that is interesting for those, which are using just one password for all their accounts.

if somebody steals/hacks the database it is very easy to go shopping on amazon or ebay in case of using the same mail/password combination without having trouble decrypting it.

in 2010 in should be possible to store the pw crypted in the database ;-)

and i saved a kittens life

7.7k · January 15, 2010

yesterday i noticed that it looks like Groundspeak is storing the user passwords unencrypted in their database - the password recovery function mails the pw in plaintext.

There's a difference between encryption and one way hash.

When you encrypt data, you render it algorithmically to gibberish using a key. There's a corresponding decryption algorithm that will convert it to the original data.

With a one way hash, you convert data into a signature or checksum. Multiple sets of data could possibly give you the same checksum, but in a good checksum algorithm, it should not be possible to calculate what data set would result in a certain checksum, and brute forcing it would be extremely time consuming.

All you've determined is that Groundspeak stores your password. You do not know if it is in the clear or encrypted. But the advice of not using the same password for sensitive sites (banks, credit cards, etc.) is a good one.

January 15, 2010

All you've determined is that Groundspeak stores your password. You do not know if it is in the clear or encrypted.

Yes, you are right, we don't know it.

But if Groundspeak is able to decrypt it, the algorithm should be somewhere in the code. So if there is somebody who gets access to the database he will probably get access to the code, too.

So I think a hashed (even better with a salt) password is the securest way to store passwords - like in many other big web projects/software.

9k · January 15, 2010

But if Groundspeak is able to decrypt it, the algorithm should be somewhere in the code.

On the server end, sure. But if they can read server end source code, they have access to the server, and I'd be worried about more than just the passwords.

No, if the passwords are encrypted, the encryption algorithm if located in the server-side code, is as secure as any other sensitive code. If they get access to the database (presumably not where the algorithm is stored) they won't be able to decrypt passwords, though they may already have access to everything else.

In theory, a hash is LESS secure than you think (as mentioned above) - because more than one source text can arrive at the same hash. Store passwords in hash, and you potentially have more than one possible 'password' making brute forcing easier. Encrypt the password though, and it's still one-to-one.

In short, encryption is vastly safer than hash, so don't worry about it...

January 15, 2010

You send your password in the clear. If Groundspeak gets hacked, and the crackers change the code that handles the password page, your password is still out there. So use the normal precautions. Classify websites to their value. Don't use the same password on an unimportant site like gc.com for a valuable site as e.g. your bank.

As much as I would prefer a "you lost your password? well, here, create a new one" policy, I think Groundspeak decided to be more 'user friendly' by returning your password. It's a bit funny, since why would they give you the same password, since you've already forgotton it anyway :-)

9k · January 15, 2010

You send your password in the clear. If Groundspeak gets hacked, and the crackers change the code that handles the password page, your password is still out there.

This is standard practice however*. If you're referring to the non-use of https, that's an understandable concern. But user/pass logins with form elements is everywhere, and other than secure 'NT' login popups, there's no other standard way to handle website session logins. That, again, should be the least of our concern as users.

What you describe is a weakness across all sites that have a username/password login form not on an https page. Honestly, inconsequential, IMO. Don't worry about it... you may have more reason to worry if it were a bank that weren't using https

* using a password style input box that is, not an clearly visible regular text entry box for a password which is BAD BAD BAD, even though from the http request standpoint, both a standard text field and a password text field are both submitted to the server in the same way.

Edited January 15, 2010 by thebruce0

January 15, 2010

Usually, to ensure security, it is not possible to decrypt a password (e.g. MD5)...

If Groundspeak is able to do that, a hacker should be able to.

Edited January 15, 2010 by seblultra

9k · January 15, 2010

Usally, to ensure security, it is not possible to decrypt a password (e.g. MD5)

MD5 is a checksum. Just like on a puzzle cache, it's a simplified "test" to compare a requested string with the original string.

Think about it like this...

If I have a checksum on the word ALPHA being the sum of the letters, the value is 1+12+16+8+1 = 38.

But how many words have letters that sum to 38? If I reduce my password to a checksum, I increase the number of possible solutions.

MD5 is FAR more complex than the example above, but the practice is still the same: a checksum is the reduction of information to some degree. It's the loss of the original (ie, "38" is stored, not "ALPHA") so there's no way to check that any other checked string IS the original string, only that its checksum matches the stored checksum.

If my password is stored as checksum "38", then I could also enter "HALAP" and the server wouldn't know the difference because it seems Checksum(HALAP)=38, login OK.

In short, checksum removes the original, but increases possible matches. Encryption retains the single match, but also means a decryption algorithm exists somewhere. And any place that does proper security relies on highly complex encryption, not checksums, let alone MD5.

Which is not to say MD5 is useless - it has its place, but it's certainly not "safer" than encryption.

January 15, 2010

There are easy to use password manager programs out there so there should be no reason for anyone to use just one single password in every service. With these password managers you don't even need to know or ever see your password: you generate one, save it and then use it by having the program copy your password into the clipboard. KeePass Password Safe is what I use. There's also a cross-platform version of an older version of the same software called KeePassX, in case you use other operating systems than Windows. Notice that files created in KeePass may not be compatible with KeePassX, but the files are compatible the other way around.

The passwords are saved in an encrypted file that you can, for example, mail to yourself if you use multiple computers, or carry around in a memory stick. Of course you will still need a master password for your password file, but I since you have been able to remember one password so far it should be no problem in the future either. Give it a try.

January 15, 2010

Usally, to ensure security, it is not possible to decrypt a password (e.g. MD5)

MD5 is a checksum. Just like on a puzzle cache, it's a simplified "test" to compare a requested string with the original string.

Think about it like this...

If I have a checksum on the word ALPHA being the sum of the letters, the value is 1+12+16+8+1 = 38.

But how many words have letters that sum to 38? If I reduce my password to a checksum, I increase the number of possible solutions.

MD5 is FAR more complex than the example above, but the practice is still the same: a checksum is the reduction of information to some degree. It's the loss of the original (ie, "38" is stored, not "ALPHA") so there's no way to check that any other checked string IS the original string, only that its checksum matches the stored checksum.

If my password is stored as checksum "38", then I could also enter "HALAP" and the server wouldn't know the difference because it seems Checksum(HALAP)=38, login OK.

In short, checksum removes the original, but increases possible matches. Encryption retains the single match, but also means a decryption algorithm exists somewhere. And any place that does proper security relies on highly complex encryption, not checksums, let alone MD5.

Which is not to say MD5 is useless - it has its place, but it's certainly not "safer" than encryption.

Nevertheless, MD5 or SHA are the most used algorithms to store passwords (web servers, OS, ...)

Encryption is mostly used to transfert data throw the network.

Because as MD5 (for example) encryption algorithm is known by client, it can send the encryted pasword (checksum if you prefer) to server.

With encryption, to ensure security, only server knows the algorithm.

Thus, passwords goes uncripted throw the network...

5.2k · January 15, 2010

C'mon folks, we're talking Tupperware filled with trinkets here, not bank accounts with your life savings

18.9k · January 15, 2010

C'mon folks, we're talking Tupperware filled with trinkets here, not bank accounts with your life savings

Just what I was thinking.

If your using the same password on your Bak account as you use here - shame on you.

January 15, 2010

You should NEVER use the same password for different accounts!

The problem is, that the password ist sent via e-mail. THAT's the security risk. Your assumption that sending the password unencrypted means that it is stored in that way is wrong.

A password should be at least eight characters long and should consist of upper- lower case letters, numbers and if possible special characters as well. But tell that all the persons who run unencrypted WLans, write their PINS on EC and Credit Cards. Some basic IT-Security is the users responsibility. But sending a password via email is definitely a no-go!

GermanSailor

2.2k · January 15, 2010

Generally speaking, when you store a password in a database, you hash it (MD5). The password itself is used as the "Key" to retrieve the password... So, without the password, you cannot retrieve the password. Even the developers and site admins would not be able to retrieve the password, unless they already had the password, in which case, they wouldn't need to get the password.

See the beauty in it?

Here's the bad news... Groundspeak isn't doing it this way. Most companies have a password reset mechanism, which is the only way to do it if you forget a hashed password. The fact that Groundspeak can send out the password indicates that the encryption is reversible.

Does it matter? Not really... My question is why they are using reversible encryption versus a hash? Do they need to know the password for some reason? Would be a good question for TPTB I guess :unsure:

9k · January 16, 2010

C'mon folks, we're talking Tupperware filled with trinkets here, not bank accounts with your life savings

well put :unsure:

Generally speaking, when you store a password in a database, you hash it (MD5). The password itself is used as the "Key" to retrieve the password...

But once again, it's a tradeoff. The possible password keys that match the MD5 checksum is no longer one.

So, yes, while hashing a password in a database does mean that no one can look at the password and know what it is. But it reduces the security because more than one phrase can produce the same MD5 result. Having the password stored as a hash in the database is, by itself, not sufficient security, at least for highly sensitive content (such as bank logins). For something like GC.com, sure. And actually, I would seriously raise concern if my password were stored as a hash in a banking system as well, precisely because it's no longer a single password that will work, and my login is less secure (even though the password itself is never transmitted anywhere except my own form submission to the web server).

Point being: There is a time and place for both forms of password 'security'. Encryption is more overhead but remains a unique password validation. Hash/Checksum/MD5/etc is less overhead but more 'passwords' are now valid.

For brute force attacks, the latter is far less secure.

Anyway. Yeah. This isn't a banking system. I'm not concerned about sites that 'know' my password - if so, they'd just better have proper security on their servers so they don't get hacked. But that goes the same even for encrypted password databases, so... yeah.

When it comes to transmission security, https is encrypted communication between client and server. Anything outside of that, in theory, yes could be watched and intercepted, but it's super paranoia to shun any site that has a user/pass login form without using https. Just be smart with your logins and passwords, and breath easy

7.7k · January 16, 2010

Point being: There is a time and place for both forms of password 'security'. Encryption is more overhead but remains a unique password validation. Hash/Checksum/MD5/etc is less overhead but more 'passwords' are now valid.
For brute force attacks, the latter is far less secure.

I don't know why we're discussing this here, but since I'm interested in the topic.. :unsure:

A brute force or dictionary attack for a hash based password is only slightly less secure than one that stores a master list of password. While there are multiple instances of plaintext that will generate the same hash key, the chances of encountering it is exceedingly slim. If 1 million plaintext are tried in the bruteforce attack, your odds of hitting paydirt is still 1 in 3.4 x 10^32, if I have my math right. You can also use SHA in place of MD5, or in addition to it if you're truly paranoid.

A master encrypted file has a weakness in that if the encryption key is broken, all the passwords are revealed. Of course, one would assume that the master file would be on a server behind heavy security, well protected, etc.

Anyway, if someone were to break into my account here, the worst that could happen is that I might have to deal with some nuisance that should be easily straightened out by contacting Groundspeak.

Since I doubt Groundspeak would enlighten us on their server network architecture and security protocols, the only thing we can get out of this is : don't reuse your passwords, unless they're for a bunch of sites that don't need strong security.

9k · January 16, 2010

don't reuse your passwords, unless they're for a bunch of sites that don't need strong security.

QFT. :unsure:

January 16, 2010

don't reuse your passwords, unless they're for a bunch of sites that don't need strong security.

QFT.

... which is exactly why i reuse passwords for 90% of the sites i visit :unsure:

What do i care if someone hacks into my login for the New York Times website? I only have an account there because they forced me to get one to use their site.

9.2k · January 16, 2010

1.1k · January 16, 2010

This isn't a little more of a deal as you make it out to be.

Consider the simple "hacked database" event.

Scenario one: Plaintext

The vast majority of users use the same password everywhere. Now, the vast majority of user's on geocaching.com are compromised across multiple websites.

Yes, it's silly to use the same password everywhere... yet, if you are a dev and you ignore that simple fact then you don't deserve the trust those people put in you.

Scenario two: encrypted database

Only mildly harder to break then plaintext.... especially since the hacker can now do so at their leisure on their own computer.

Scenario three: Salted hash

Each password is hashed separately. Unlike plaintext or a encrypted database, each password must be brute forced indivisibly. Each hash can take 40+ hours. While thats not a big deal if you only need to do it once, it starts to matter if you need to do it six million times.

And the best thing... salted hashes are easy to understand and there are off-the-shelf/open source solutions that are relatively easy to implement into an existing security system.

S: (n) negligence, carelessness, neglect, nonperformance (failure to act with the prudence that a reasonable person would exercise under the same circumstances)

S: (n) negligence, neglect, neglectfulness (the trait of neglecting responsibilities and lacking concern)

5.3k · January 16, 2010

I have to go against the trend here. It is a big deal. Passwords are valuable and should be treated as such. You should "damage" them via salting them before storing them. You should never ship them in cleartext over the 'net, such as via email. A site shouldn't even *have* them in cleartext. In fantasy land, everyone would pick totally great passwords and even if I could h4x0r your password here, it wouldn't help elsewhere. History shows this doesn't really apply to reality.

My money is mostly where my mouth is on this one. The GeoWoodstock 7 site (GWS 8 did their own thing and I can't speak for them) *never* stored or transmitted a password in a recoverable form. I did some tests with a few thousand users and rainbow tables and was unable to recover a single password with the stored information. Why? Because what was stored wasn't readily reversible while what this site stores seems to be not only reversible, but trivially so. So even if you had this information that we worked hard to ensure you couldn't get, it didn't _really_ help.

What's the excuse? GWSVII didn't use https for login, so a snooped login from the coffee shop WIFI would still give you more info that I'd have liked - though much less info than what's in play here.

Any site in modern times that's able to mail you your own password as cleartext should set off mental alarms for concern of security. The act itself isn't inherently bad, but it shows a lack of thinking it through.

1.1k · January 16, 2010

My money is mostly where my mouth is on this one.

Mine too. I was an administrator for a site running an instance of mediawiki. Mediawiki stores passwords in a very sophisticated salted hash.

9k · January 18, 2010

Ok, see here we agree on some things.

But here are the weaknesses:

Encryption: if it's cracked, all is decrypted.

Hash: More than one possible solution (even highly complex hashes)

For most things, I wouldn't care (as posted above, most sites require logins I rarely visit, so having similar/same passwords for those - meh), but for places like banks:

1) If they use encryption which is "easily" broken, this is BAD

2) If they have servers that get hacked, and encryption that's broken, then how my password is stored is the least of my worries.

3) I would love to see encrypted, hashed passwords sent securely between browser/server behind firewalls, encrypted firewalls, encrypted ciphers, whatever.

The key thing to remember is that EVERYTHING can be reverse engineered, and the minimal level of security that is 'satisfactory' for any kind of website database and/or client-server communication really is entirely based on context.

GC - I'd rate it lower-mid on required minimal security. Anything more is great, but here, concern about https, secure password transmissions, encryptions (or lack thereof) vs hashing in the database - IMO not as important as just encouraging people to use unique passwords if they're worried, in this case.

Like I said, if someone's already hacked into the database (presuming logins are in the same database as the rest of the site data), then logins are the least of my worries.

But that's just MHO.

Edited January 18, 2010 by thebruce0

January 19, 2010

hi there,

yesterday i noticed that it looks like Groundspeak is storing the user passwords unencrypted in their database - the password recovery function mails the pw in plaintext.

that is interesting for those, which are using just one password for all their accounts.

if somebody steals/hacks the database it is very easy to go shopping on amazon or ebay in case of using the same mail/password combination without having trouble decrypting it.

in 2010 in should be possible to store the pw crypted in the database ;-)

and i saved a kittens life

Even if the password data was encrypted in the database, I presume the SMTP server would still send the password in plaintext over the Internet. Better approach may be a one time accessible URL to allow the password to be changed over an HTTPS connection. Does Groundspeak even provide HTTPS encryption for logins? If you are on the road and using someones wireless (like a hotel or starbucks hotspot, etc) its possible someone could be sniffing packets in promiscuous mode.

7.7k · January 20, 2010

Does Groundspeak even provide HTTPS encryption for logins? If you are on the road and using someones wireless (like a hotel or starbucks hotspot, etc) its possible someone could be sniffing packets in promiscuous mode.

https://www.geocaching.com exists. I have not tested to see if the password is actually sent over https since the code is obscured behind some code not visible in the source and I don't feel like running Wireshark right now.

5.3k · January 20, 2010

I have to go against the trend here. It is a big deal. Passwords are valuable and should be treated as such.

As usual, I agree with robertlipe. My geocaching.com password is valuable to me and having it stored, even in encrypted form, is a bad practice.

Sending unencrypted passwords via email is even worse.

The strangest part here is that I believe Microsoft knows how to do security properly, and since the site is built using the .Net framework, I would expect that the login/password handling would have been done properly by default.

The usual practice for a lost/forgotten password is to send the user a new, randomly-generated password via email and require that it be changed upon first login.

As an added note, I would be a whole lot happier if the login to the site were done via an https page.

20.7k · January 20, 2010

The way that it is currently done is fine. We are not dealing with national secrets, after all.

9k · January 20, 2010

The strangest part here is that I believe Microsoft knows how to do security properly, and since the site is built using the .Net framework, I would expect that the login/password handling would have been done properly by default.

This is not a Microsoft problem. This is HTML standard. HTML provides the password field, and the form submission simply sends form data plaintext in a post request back to the server. It is entirely up to the web dev team to determine what level of security is optimal and feasible on the browser and/or server given the site's implementation, costs and content.

The way that it is currently done is fine. We are not dealing with national secrets, after all.

This.

Honestly, in my opinion it is over-paranoia, the likes of refusing to fly for fear of a crash, to expect and demand that every website offering a user/pass login form implement full security, hashing and encryption, on any and all remotely sensitive data transmission to/from the browser.

In GC's case, if https is up and running, that should be sufficient for anyone worried about their login and pass getting sniffed in transit from the browser to the server. Just update your bookmarks to https:// instead of http://

As I said above, if the database gets hacked, logins are the least of my worries. It's simple common sense these days NOT to use the same passwords across sites, or at least use unique passwords on sites that contain sensitive information you personally want to ensure is protected on your part.

Groundspeak stores the password unencrypted in the database?

Recommended Posts

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment