username and password in url?

[Paulie]

I'm all for obscuring the password in the URL, if it doesn't cost too much to implement. That means upgrading the clients, those with dozens to hundreds of machines will be ok with that.

I just found it amusing the discussion about needing to use a cryptographically secure hash for this feature, along with the merits of MD5 over SHA-1 when the server will just accept it as a password itself.

Pad it, prefix it, xor it, make it cheap and easy and backwards compatible so won't require upgrades to support or more processing time on either the server or the clients. how about gimpsidorwssaPigimps = Password? :)

[mdettweiler]

Originally Posted by Paulie

I'm all for obscuring the password in the URL, if it doesn't cost too much to implement. That means upgrading the clients, those with dozens to hundreds of machines will be ok with that.

I just found it amusing the discussion about needing to use a cryptographically secure hash for this feature, along with the merits of MD5 over SHA-1 when the server will just accept it as a password itself.

Pad it, prefix it, xor it, make it cheap and easy and backwards compatible so won't require upgrades to support or more processing time on either the server or the clients. how about gimpsidorwssaPigimps = Password? :)

How about making the login system backwards-compatible? That is, newer client versions, as well as logging in through mersenne.org, would use the hashed version, but the older non-hashed version would be accepted as well. Possibly an extra flag on the URL could be added: ?sha1=yes would tell the server to expect a hashed password, and if it's simply left off (like with an older client or bookmarked link), it will accept the plaintext password. I'd guess that such a functionality would not be hard to implement.

[soda]

Would it not be possible to simply pass a session ID instead of username and password. For instance when the server accepts the password for the username it would calculate a unique id with a set time limit and maybe some verification of ip address. This won't stop someone from getting in by snooping your network, but at least not be able to simply login from clicking a link in ur history or searching your hardrive. Being able to login to your Primenet accoaunt via bookmarks should be accomplished by cookies and not the url paramters. Anyone agree?

[Paulie]

Originally Posted by mdettweiler

How about making the login system backwards-compatible? That is, newer client versions, as well as logging in through mersenne.org, would use the hashed version, but the older non-hashed version would be accepted as well. Possibly an extra flag on the URL could be added: ?sha1=yes would tell the server to expect a hashed password, and if it's simply left off (like with an older client or bookmarked link), it will accept the plaintext password. I'd guess that such a functionality would not be hard to implement.

If all we care about is obscuring the login/password URL from shoulder surfing, it would be easier to just make the main page a base URL, and put everything else in a child frame. Then we'll not see the URL with the password string. Takes no cycles to do this, no programming changes, no client changes, no computation on the servers part to support.

[Mini-Geek]

Originally Posted by Paulie

If all we care about is obscuring the login/password URL from shoulder surfing, it would be easier to just make the main page a base URL, and put everything else in a child frame. Then we'll not see the URL with the password string. Takes no cycles to do this, no programming changes, no client changes, no computation on the servers part to support.

It also means that getting URLs to copy/paste is a bit of a chore, and that using a bookmark to log in will still reveal your login to any "shoulder surfers". Wouldn't it all be a lot easier to just send the login data as POST instead of GET and use a cookie to keep you logged in if you want?

[starrynte]

Exactly. POST doesn't show in the URL.
@Paulie's suggestion: What about browsers that don't support frames?

[Paulie]

Originally Posted by Mini-Geek

It also means that getting URLs to copy/paste is a bit of a chore, and that using a bookmark to log in will still reveal your login to any "shoulder surfers". Wouldn't it all be a lot easier to just send the login data as POST instead of GET and use a cookie to keep you logged in if you want?

Except that the URL is also the same one for the assignment server, so what you do for the web stats system will affect the client communication.

Seriously, back to what the risks we're trying to mitigate. This is GIMPS, not a bank. Don't use the same login ID/Password combo you use anywhere else. Make a 50 character password, use PasswordSafe or Keychain to manage it, then let someone try to memorize it then. If someone for zero profit wants to compromise your account, what can they do even if they get in? Join/leave a team? Unassign your exponents? Report that you're behind me in the stats? :D

As for browsers that don't support frames, how many people are we talking? Even Lynx supports frames. If you're a hardcore GIMPster managing your farm via a 5 year old cell phone, you may just have to start crunching on that phone instead and upgrade to a new browser... :)

If it's a huge worry, put it in a frame, requires no code changes in the infrastructure. If you're personally bothered by shoulder surfers, make that 50 character password I suggested earlier. It's all busywork otherwise for the volunteers who work on this project both as coders and participants.

[Mini-Geek]

Originally Posted by Paulie

Except that the URL is also the same one for the assignment server, so what you do for the web stats system will affect the client communication.

I meant (can't you read my mind to know that? ) that both POST and GET should be supported, with POST used when you use the login form on the site.

[Paulie]

Originally Posted by Mini-Geek

I meant (can't you read my mind to know that? ) that both POST and GET should be supported, with POST used when you use the login form on the site.

I'd need several more pots of coffee before I start hearing the thoughts of others. :D

Problem with POST is you get that annoying "this is sending an unencrypted page" blah blah warning upon submit. Someone want to send a few hundred U.S. to George every couple years to get an SSL cert? Hopefully the root chain is known by those frameless browsers else you'll get a certificate warning too. :D :D :D


This was a timely blog post: http://www.schneier.com/blog/archive...lem_wit_2.html