When will login be encrypted?

November 10, 2007

These days a cleartext login isn't a great idea for any website and GC.com is no exception. It forces me to keep a sacrificial, non-premium account around for situations when I need to log into GC.com from a system that I don't trust (eg. a kiosk at a library, hotel or webcafe) and don't want to risk my real GC account's credentials from being sniffed off of the wire or via a keystroke logger on the terminal itself. Even then, that's only useful for searches; I still have to wait to get to a reasonably secure trusted machine to post my finds via my real account.

Note: if it's a backwards compatibility issue, you could always offer both cleartext and ssl-enabled pages and let users choose which one they prefer.

What's the likely timeframe for a secure login page? - Wash

P.S. Not intended as a troll post, just asking when it'll be an offering.

2k · November 10, 2007

Good question, except that I can't imagine someone trying to break in to your accout.

Edited November 10, 2007 by simpjkee

November 10, 2007

Good question, except that I can't imagine someone trying to break in to your accout.

That doesnt mean it still shouldnt be protected.

5.2k · November 12, 2007

... keystroke logger ... ssl-enabled pages ...

SSL ain't going to do squat to protect you from a keystroke logger on the library computer.

November 13, 2007

... keystroke logger ... ssl-enabled pages ...

SSL ain't going to do squat to protect you from a keystroke logger on the library computer.

That's true, but SSL will protect your session if the client is trusted but the network you're on isn't (hotel, cybercafe, freebie wifi on the metro train or airport, etc).

SSL just seems like a basic precaution that should be in place to protect our accounts from a trivial method of compromising them.

Edited November 13, 2007 by Wash

November 13, 2007

...and so it should be obvious that you shouldn't use the same password here as anywhere else. Don't let a password compromised from this site leave you vulnerable elsewhere. Practice safe computing! :unsure:

June 24, 2008

Any news on this topic so far? A year ago I sent an email to GC asking about the same thing...

4.4k · June 24, 2008

I agree. HTTPS login please!

Although this identity of mine isn't of much value to anyone else, it's of huge value to me. I put a lot of time, effort, and passion into my geocaching identity. I'll bet you guys have too.

Geocachers travel. Travelers geocache. Travelers log geocaches using open, unprotected WiFi in hotels. (You do want us to promptly update those TBs, right?)

June 24, 2008

... keystroke logger ... ssl-enabled pages ...

SSL ain't going to do squat to protect you from a keystroke logger on the library computer.

That's true, but SSL will protect your session if the client is trusted but the network you're on isn't (hotel, cybercafe, freebie wifi on the metro train or airport, etc).

SSL just seems like a basic precaution that should be in place to protect our accounts from a trivial method of compromising them.

Technically, even that's not really completely/always true... there are still a few other (albeit currently less common) attacks that may allow someone to compromise or snoop on a rudimentary SSL session. (though it certainly blocks out a large percentage of the scr1pt k1dd1ez)

But overall, I agree... SSL would be a nice addition, even if they start with a self-signed certificate for now (though GoDaddy and a few others have some pretty cheap ones out there with a CA that should be integrated in to most modern browsers, by now).

Edited June 24, 2008 by russellvt

June 24, 2008

Technically, even that's not really completely/always true... there are still a few other (albeit currently less common) attacks that may allow someone to compromise or snoop on a rudimentary SSL session. (though it certainly blocks out a large percentage of the scr1pt k1dd1ez)

But overall, I agree... SSL would be a nice addition, even if they start with a self-signed certificate for now (though GoDaddy and a few others have some pretty cheap ones out there with a CA that should be integrated in to most modern browsers, by now).

Generally, such SSL MITM attacks will pop up a big security warning error message. Don't ignore those!

I've done it to myself for test purposes - it's pretty scary. I was able to sniff my own credit card info while surfing my cc company's site. But like i said, i had to click through a huge 'invalid certificate' warning from the browser.

Anyway, Groundspeak could get an SSL cert for $99 which would work fine. Probably a few hours to implement the ssl in the code. No problem.

-Ben

June 24, 2008

Technically, even that's not really completely/always true... there are still a few other (albeit currently less common) attacks that may allow someone to compromise or snoop on a rudimentary SSL session. (though it certainly blocks out a large percentage of the scr1pt k1dd1ez)

Generally, such SSL MITM attacks will pop up a big security warning error message. Don't ignore those!

I've done it to myself for test purposes - it's pretty scary. I was able to sniff my own credit card info while surfing my cc company's site. But like i said, i had to click through a huge 'invalid certificate' warning from the browser.

Generally, perhaps... though many browsers come with certain features such as that one (and a few others) disabled or turned off by default... so the uninitiated/unwary tend to be the ones hurt worst. I think that's largely the case only because a lot of developers still seem to make the mistake of "half encrypting" a page which tends to cause similar nasty alarms. But this is also all probably getting outside the scope of the original discussion...

Anyway, Groundspeak could get an SSL cert for $99 which would work fine. Probably a few hours to implement the ssl in the code. No problem.

They're not even that pricey these days, unless you choose to go with someone like Verislime (disclaimer: may or may not bear any resemblance to any known or fictitious company)

2.2k · June 24, 2008

From a scale of 1-10, 1 being unsecure information and 10 being extremely sensitive information, the information that is contained within geocaching.com would rank as a 1. Credit card information? No. Social security numbers? No. In fact, I can't think of a single bit of information that is sensitive on the site. Therefore, why use an SSL cert?

I think its a bit paranoid personally. Use different passwords for different sites. Change your passwords often. You've got a bigger chance of having your home broken into and computer or laptop stolen than someone gaining access to your geocaching.com account.

There are also disadvantages to using SSL on a site. Performance is the largest drawback. Why degrade performance if there are not any good reasons to do it?

Edited June 24, 2008 by ReadyOrNot

June 24, 2008

From a scale of 1-10, 1 being unsecure information and 10 being extremely sensitive information, the information that is contained within geocaching.com would rank as a 1. Credit card information? No. Social security numbers? No. In fact, I can't think of a single bit of information that is sensitive on the site. Therefore, why use an SSL cert?

I think its a bit paranoid personally. Use different passwords for different sites. Change your passwords often. You've got a bigger chance of having your home broken into and computer or laptop stolen than someone gaining access to your geocaching.com account.

You took the words out of my mouth. Exactly what is it that people are scared of losing on GC.com? And how many people are going to try and hack your GC account and steal your finds or your caches? I suspect that's the reason GC has never implemented a higher security model than they have. If they stored other info, it would be a different story. IMO

June 24, 2008

From a scale of 1-10, 1 being unsecure information and 10 being extremely sensitive information, the information that is contained within geocaching.com would rank as a 1. Credit card information? No. Social security numbers? No. In fact, I can't think of a single bit of information that is sensitive on the site. Therefore, why use an SSL cert?

Well, it at least generally contains real name and address (and ICBM address), which some people feel a bit sensitive about, along with possible IM accounts (with an account to turn off public display of it -- which would beg the question why it's there, anyway). So not sure I agree it's a "1" ... but probably not more than a 4 or 5 at worst/best?

I think its a bit paranoid personally. Use different passwords for different sites. Change your passwords often. You've got a bigger chance of having your home broken into and computer or laptop stolen than someone gaining access to your geocaching.com account.

There are also disadvantages to using SSL on a site. Performance is the largest drawback. Why degrade performance if there are not any good reasons to do it?

Well, you make good points but, really... how many folks actually have good password practices? (for that matter, how many sysadmins really even practice what they preach?) Anyone having worked in IT can tell you of the nightmare you can have implementing even a corporate security policy that includes strong passwords and/or even a regular password rotation, as you very rightly recommend.

More to the point, were Groundspeak's network to be somehow compromised and the sniffing were to occur on larger scale... just because an individual user of group of them may already be irresponsible with their password practices shouldn't make it okay for the corporation-level folks to assume that they can be equally lax (and more-over, argument can be had that a responsible corporation would just step up and do it anyway).

BTW... with the advent of things like SSL accelerators, these days the only big performance hit is really during the establishment of the SSL session. Over an extended session the low-grade encryption isn't really that big a deal, even from a slow device such as a cell phone... you can further mitigate the issue by simply encrypting the login, and leaving the rest of the work to browser sessions (which they already use, anyway). Many sites on the Internet already do this exact thing and are plenty fast.

In my own previous "production lives" we've never had a problem forcing a few hundred thousand clients to re-establish SSL sessions on a regular basis, short of one or more of the load balancers deciding that they weren't happy with life. I suspect the tougher technical issue for Groundspeak, here, is having a large number of clients computationally querying tens of thousands of records out of their DBs on a nearly continual basis... especially with a windows front-end (*grins*).

So my argument would be more like why not do it if a simple solution like this might provide a modicum of users peace of mind and, at the same time, the company appears as though they care about the security of their users.

Edited June 24, 2008 by russellvt

2.2k · June 24, 2008

So my argument would be more like why not do it if a simple solution like this might provide a modicum of users peace of mind and, at the same time, the company appears as though they care about the security of their users.

I think we could probably both agree that it doesn't sound like a $99 solution any more does it There are "Real" reasons NOT to do it, but as always, there are going to be many reasons based on perception and unwarranted fear to implement a solution. I tend to take the pragmatic approach though. If we focus on real issues, there really aren't any good reasons to do it.

June 24, 2008

So my argument would be more like why not do it if a simple solution like this might provide a modicum of users peace of mind and, at the same time, the company appears as though they care about the security of their users.

I think we could probably both agree that it doesn't sound like a $99 solution any more does it There are "Real" reasons NOT to do it, but as always, there are going to be many reasons based on perception and unwarranted fear to implement a solution. I tend to take the pragmatic approach though. If we focus on real issues, there really aren't any good reasons to do it.

There are essentially always lots of immeasurable costs in "free" solutions... but those costs also don't tend to appear on the budget/planning sheets that go up the chains of command to scare away the potentially more-costly ideas, either. So yeah, I guess it could be said that it goes both ways... and yeah, you're right - it's not really a $50-$100 solution, overall (but the certs are certainly oodles cheaper than what they used to be).

Overall, my general assertions (for clarity):

SSL cert costs are just a drop in the bucket, annually *
Overall, the performance degradation is probably negligible
A competent sysadmin should be able to add a cert to a fleet of load balancers or SSL accelerators in under an hour **

* Programming man hours are likely dependent on architecture, though shouldn't be huge

** If you decide/have to buy additional hardware, this obviously can boost the cost significantly.

"The day before a breach, the ROI is zero. The day after, it is infinite." - Dennis Hoffman, RSA vice president of enterprise solutions

Edit: added assertions to help clarify the point

Edited June 24, 2008 by russellvt

9.2k · June 24, 2008

Exactly what is it that people are scared of losing on GC.com?

My mojo, of course.

2.2k · June 25, 2008

"The day before a breach, the ROI is zero. The day after, it is infinite." -

We recently had a security audit at the company I work for. They gained access to our servers as well as confidential employee information. How did they do it? Sniffin' packets? No. High technology? They found email addresses of several employees and found contact information of IT staff. They sent an email pretending to be one of the IT staff (you'd be amazed how stupid some users are) and they gave their passwords to the impersonator. Good ol' fashioned con-games. And these weren't low level-users, these were users will high level access to important information on the network...

The only way to secure anything is to lock-out all humans from accessing the resource In the real-world, noone is going to hack into your geocaching account (unless someone has a personal vendetta against you) and if they take the time to sit in your front-yard with their laptop so they can sniff the packets on your unsecured wireless network (you did secure your wireless network right?), then you've got bigger problems than someone deleting a couple of your finds.

June 25, 2008

The only way to secure anything is to lock-out all humans from accessing the resource

Unfortunately, I think it current "best practices" come down to things like biometrics, and/or good password security policies with single-use passwords (OTP). But yes, essentially total security boils down to turning off a computer and unplugging it from the wall.

(and yes, I know you can defeat fingerprint readers, too)

In the real-world, noone is going to hack into your geocaching account (unless someone has a personal vendetta against you) and if they take the time to sit in your front-yard with their laptop so they can sniff the packets on your unsecured wireless network (you did secure your wireless network right?), then you've got bigger problems than someone deleting a couple of your finds.

Actually, in the real world, that's exactly where such a hack is probably going to start... probably during part of the process (aka "hack") referred to as enumeration. It's likely to be a place such as a reasonably "low-level" social site (such as a forum or similar) where the security is likely weaker or "not really a concern" (ie. the "low hanging fruit"). Typically, that's one of the best places to find things like unsuspecting users or software glitches that may allow intrusions, SQL injections or privilege escalation type operations (agreed, most of that's outside the realm of SSL). Basically something they'd likely not be able to get away with right away at some place like a financial institution or some other "high security" site (at least they'd likely be detected reasonably quickly). And again, based on all the things mentioned above, it's likely that it'd only be a matter of "following the chain" there-after...

BTW... many/most "secure" wireless networks also are only there to keep honest people honest, so-to-speak. Most of the weak encryption can be broken by someone determined enough to do so (see the password rotation discussion, above). Short of securing a router in a DMZ and running a VPN across it for "real" access, you're likely not going to be able to tighten even that down so that a determined (or knowledgeable) person can't get in to it...

Yes, none of this likely applies to someone who actually religiously follows good password guidelines... but really, how many folks actually do? (that's really what we're talking about, here) And with the proliferation of "login required" websites on the net, how many folks re-use credentials at "non-important" sites? Think about that one for a second and feel free to answer it for yourselves (and no, changing one or two letters/numbers or something between sites does not count as using different passwords, I'm sorry to say). If someone really follows good password security guidelines, I commend you -- count yourself as one of the very, very few.

Edit: "low hanging fruit"

Edited June 25, 2008 by russellvt

9.5k · June 25, 2008

Actually, in the real world, that's exactly where such a hack is probably going to start... probably during part of the process (aka "hack") referred to as enumeration. It's likely to be a place such as a reasonably "low-level" social site (such as a forum or similar) where the security is likely weaker or "not really a concern" (ie. the "low hanging fruit"). Typically, that's one of the best places to find things like unsuspecting users or software glitches that may allow intrusions, SQL injections or privilege escalation type operations (agreed, most of that's outside the realm of SSL). Basically something they'd likely not be able to get away with right away at some place like a financial institution or some other "high security" site (at least they'd likely be detected reasonably quickly). And again, based on all the things mentioned above, it's likely that it'd only be a matter of "following the chain" there-after...

I'm going to have to agree wtih this. I'll refer you to a book called The Cuckoo's Egg for a perfect example of how easy computer trusts are started from low level security aspects. It was recommended reading before I could begin to manage my first PBX back in 1990.

Edited June 25, 2008 by TotemLake

2.2k · June 25, 2008

Just to hop back to the topic for a second.... SSL does not address any of the social security issues that you mentioned in the last reply. Good password management, I agree, is the only good solution. I'll be honest with you, I use the same password for almost every site I visit because it makes my life easier. I have a different password for online banking and obviously at work, my admin password is different and gets changed often.

Bottom line again, SSL is not necessary and does nothing to deal with most of the issues you brought up. The only purpose it would serve is to make the "Computer Iliterate" feel better about themselves while they use "password" as the password on all the sites they visit. If somone asked me to spend thousands of dollars to make someone, who probably doesn't know any better anyways, feel better about themselves, the answer would be NO. When they start asking for and storing sensitive information, I'll jump sides

June 25, 2008

[...]
I'll be honest with you, I use the same password for almost every site I visit because it makes my life easier. [minus financial/work passwords]

[...]

Bottom line again, SSL is not necessary and does nothing to deal with most of the issues you brought up. The only purpose it would serve is to make the "Computer Iliterate" feel better about themselves while they use "password" as the password on all the sites they visit.

Well, if you actually read my response, I indicated that SSL wouldn't address many of those social issues I pointed out. However, it would address an issue such as an upstream sniffer (trivial man in the middle) or other sort of similar or potentially "social" compromises (eg. bribing or compromising links along the chain).

Groundspeak also stores passwords (as compared to hashes), so SQL injection through something like URL munging (or similar) is also a consideration. Remember, you don't actually have to compromise the site in-question, but only some link along the way (or have a crafty phish/proxy/etc)... and SSL is great for preventing prying eyes from prying (ie. keeping honest people honest) in those scenarios. Even compromise of the browser is possible (though that's obviously a spot where only good password practices might help you).

(...but "computer illiterate" who... do the exact same thing? Sounds a bit harsh, to me...)

My previous posts were largely directed at your assertions that [insert "worthless" social site here] is not worth an attempt at compromise from a hacker's standpoint. That's a pretty common misconception. Personally, I think it's pretty clear that folks at this site in-particular might tend to fall more in to the "disposable income" category, so it's certainly a security concern.

Note: This is not saying someone should go and hack geocaching.com or any other social or hobby site or similar. It's merely giving you an idea of how some identity theft and related compromises tend to play out in real world scenarios. And yes, education of your user base also plays a very definite role... social engineering can be a huge problem. I don't think a forum operator's job, however, is "user education" (that's more of a workplace thing).

Bottom line: SSL's not expensive nor difficult/costly to implement unless you're planning a whole new infrastructure around it (ie. new/big hardware). Frankly, I think someone with Groundspeak's traffic already has to have a reasonably impressive network presence as-is just to keep the Windows boxes from falling over. And honestly, I've not implemented SSL across IIS though I believe Microsoft's pretty much gotten it down to a "single click" solution/purchase at this point (that might be slightly optimistic, though).

Given the current round robin solution on the site, it's unclear if there's already some sort of load balancer in the stream that could easily offload any/all IIS servers... though throwing SSL accelerators in front of the current farm(s) probably isn't tough or really that costly, either, in the grand scheme of things. But really only Groundspeak to speak to those points.

Any more dead horses?

2.2k · June 26, 2008

How do you know how they store their passwords? I usually hash the password using the username as a salt. I think that's pretty common. I would assume that Groundspeak at least does that. If they don't, then I certainly have a problem with that, because I should be the only one with access to my password...

You a disgruntled ex-employee or something? (just kidding about that, but seriously, how do you know how the passwords are stored in the database?)

June 26, 2008

How do you know how they store their passwords? I usually hash the password using the username as a salt. I think that's pretty common. I would assume that Groundspeak at least does that. If they don't, then I certainly have a problem with that, because I should be the only one with access to my password...

You a disgruntled ex-employee or something? (just kidding about that, but seriously, how do you know how the passwords are stored in the database?)

Nope... never worked for them... just a rather "paranoid security curmudgeon," I guess...

As far as the cleartext password issue, though... it's pretty clear if you ever click on the "forgot my password" link. Most database front-ends I've written with user credentials usually use my own password hashes (see below) with a select statement that only returns rows if there's a single, definite match (slightly different from outright comparison). Unfortunately, many sites take the aforementioned route (I'll refrain from listing "common violators" but it's not too hard a list to find elsewhere).

BTW, passwords with salts tend to be fairly easily brute-forceable. Unfortunately, it's getting so that even md5 hashes are pretty much trivial these days, too. It's getting to be that the only "secure" method of storing passwords are through your own proprietary mechanisms, such as a salt-like md5, but that tends to cause a lot of programming overhead... yet more reason to always try to implement OTP solutions in my book (wanna talk about "cost" though... *laugh*).

August 6, 2008

Still no progress on this - to bad. GC is changing the websites layout, changing tiny icons and stuff like that to make it more 'comfortable' for the user but they don't seem to care about security issues... :-(

9.2k · August 8, 2008

All of the (very few) incidents of unauthorized access to this site that I've been aware of, have been of a type that encrypted log-in would have no affect on. This usually happens when someone allows someone else to shoulder-surf while they log on, or the couple who split up, and one (or both) try to cause problems for the other.

August 9, 2008

BTW, passwords with salts tend to be fairly easily brute-forceable. Unfortunately, it's getting so that even md5 hashes are pretty much trivial these days, too. It's getting to be that the only "secure" method of storing passwords are through your own proprietary mechanisms, such as a salt-like md5, but that tends to cause a lot of programming overhead... yet more reason to always try to implement OTP solutions in my book (wanna talk about "cost" though... *laugh*).

Anything is better than what Groundspeak does, like storing passwords in cleartext (evidently, as you can request your password by mail at any time rather than getting a new one) and ignoring the case of letters (aBc123D is the same as abc123d ...).

Anyway, I agree that login should be encrypted, no matter what site we are talking about ...

-nik

Edited August 9, 2008 by The Hawks

3.8k · August 9, 2008

I just use ******* as a password. That way anyone looking over my shoulder thinks the site is protected.

7.2k · August 9, 2008

The amount of worry I have over an unauthorized person getting into my Groundspeak account is pretty much zero.

Maybe they do get in, what are they going to do? Cause me a few minutes of pain by contacting Groundspeak and having them restore my caches to the previous versions? Return my account to me? Delete some bogus logs? Oh, I know, peek at the solutions for some puzzle caches.

I just expended way more energy writing this post than I do worrying about account security here at Groundspeak.

2.3k · August 9, 2008

The amount of worry I have over an unauthorized person getting into my Groundspeak account is pretty much zero.

Maybe they do get in, what are they going to do? Cause me a few minutes of pain by contacting Groundspeak and having them restore my caches to the previous versions? Return my account to me? Delete some bogus logs? Oh, I know, peek at the solutions for some puzzle caches.

I just expended way more energy writing this post than I do worrying about account security here at Groundspeak.

I tend to agree with you, CoyoteRed. I've never spent much time worrying about someone stealing my Groundspeak password. There really isn't that much damage they could do. Now, if I used the same password to access my on-line checking account, I might be concerned.

Uh oh.

Excuse me for a minute while I go change my password ....

--Larry

August 9, 2008

I just expended way more energy writing this post than I do worrying about account security here at Groundspeak.

I tend to agree with you, CoyoteRed. I've never spent much time worrying about someone stealing my Groundspeak password. There really isn't that much damage they could do. Now, if I used the same password to access my on-line checking account, I might be concerned.

Uh oh.

Excuse me for a minute while I go change my password .... :rolleyes:

The new GC design has one major flaw in that unless you actually "log out", you stay logged in, even though you are no longer on the internet. I was on gc.com at work, clicked on red X in upper right corner to get out really quick when boss approached. I didn't come back to the wetsite until the following day and I was still logged in! My work computer is multi-user. While I'm not concerned about my co-workers ethics, some are geocachers and if they came to GC website via that computer, they could have inadvertantly posted their finds on my account. The new design of gc.com is the first website I have ever encountered that doesn't automatically log you out when you exit the website and/or internet. I was still logged in at home after a power failure. If a member inadvertantly stays logged in that easily, what's the purpose of additional encrypted logins?

In addition, it would seem to me that if we unknowingly stay logged in, it would slow down the website as a whole.

::::retraining brain::::: log out, log out, log out

August 9, 2008

The new GC design has one major flaw in that unless you actually "log out", you stay logged in, even though you are no longer on the internet. I was on gc.com at work, clicked on red X in upper right corner to get out really quick when boss approached. I didn't come back to the wetsite until the following day and I was still logged in! My work computer is multi-user. While I'm not concerned about my co-workers ethics, some are geocachers and if they came to GC website via that computer, they could have inadvertantly posted their finds on my account. The new design of gc.com is the first website I have ever encountered that doesn't automatically log you out when you exit the website and/or internet. I was still logged in at home after a power failure. If a member inadvertantly stays logged in that easily, what's the purpose of additional encrypted logins?

In addition, it would seem to me that if we unknowingly stay logged in, it would slow down the website as a whole.

::::retraining brain::::: log out, log out, log out

This is how many websites work - they store a cookie on your computer to indicate you're logged in. I imagine this happens on gc.com if you click the "Remember me" box when logging in.

2.3k · August 9, 2008

This is how many websites work - they store a cookie on your computer to indicate you're logged in. I imagine this happens on gc.com if you click the "Remember me" box when logging in.

That's also the way Google Mail works. I'm retired, and I use a computer at home that no one else has access to. Even after restarting this computer a zillion times, I can't remember the last time I actually logged into Google Mail to check for messages. If the computer you use is also used by others, the only option is to log out when you're finished.

This applies to a whole lot of Web sites I visit. As Corey said, it's the way a lot of cookies work.

--Larry

Edit to add: I could be wrong, but I doubt whether it adds any overhead to a Web server for users to stay logged in.

Edited August 9, 2008 by larryc43230

When will login be encrypted?

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

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment