Firefox: What's the basis for remembering login information?

views:

152

answers:

+4 Q:

Firefox: What's the basis for remembering login information?

+1 A:

If they're actually entering data into http just to be redirected to https after login, isn't that a bad scenario? You're already sending the most sensitive piece of data unencrypted across the wire.

I believe a better solution would be to redirect them to the https site and do login there...is there something I'm missing with your setup? Do they login again on the secure site?

Nick Craver 2010-02-02 13:04:22

That's not the case. The browser would remember the password while on mysubdomain.server.com and not on `secure.`. It seems that http://mysubdomain.server.com/login is just a redirect without any data entry, because it's secure.server.com where the data is auto-filled-in.

SF. 2010-02-02 13:59:43

@SF - Why is there a login/password box on the unsecured domain **at all**? There shouldn't be anywhere there for it to be auto-filling. I'm not saying that you need https for all cases, but if you have it, why wouldn't you use it for the login of all things?

Nick Craver 2010-02-02 14:38:57

Why are you claiming there is such a box there? There may be only a "You need to log in, proceed to secure login page" link/redirect in the insecure page. All the data entry (and auto-filling) occurs on the secure page.

SF. 2010-02-02 14:47:42

@SF - I see what you mean, the problem is the storage is not varying by query parameters in that case. Excellent point, I didn't see it that direction. Unfortunately, I'm not sure how to tell firefox to store `login?subdomain=mysubdomain` deifferent from `login?subdomain=mysubdomainB` though.

Nick Craver 2010-02-02 15:09:21

the way Deviantart does. Custom DNS server generating virtual subdomains: `subdomain.secure.server.com` and `subdomainB.secure.server.com`. This would certainly solve the problem but I don't know if it is worth the hassle.

SF. 2010-02-02 15:22:59

I've updated the original question with some clarifications. The situation is as @SF explains: you type in `subdomainA.server.com` and it redirects you to `secure.server.com` where the actual login form is located.

Dan 2010-02-02 15:34:00

@SF - I'd update your answer to that solution, seems like the best route, will get a +1 from me.

Nick Craver 2010-02-02 15:44:12

+2 A:

I couldn't quite decipher what your setup is, but you can enable login manager debugging and check what Firefox does. You can also inspect signons.sqlite in your profile to see what pieces of data are stored with the login.

I thought that for web forms it keyed off the form's submit URL, but my memory is shady on this.

[edit] source (nsLoginManager.js) says it only uses the form's action and the page's URL, and it uses not the action/page URL itself, but (see _getPasswordOrigin) the scheme+host+port combination.

Nickolay 2010-02-02 13:50:16

Excellent insight and links! It makes a lot of sense for Firefox to remember passwords based on the form submit URL... problem is that it doesn't make a distinction on the only parameter i can afford to vary: `secure.server.com/check-login?subdomain=subdomainA` vs. `secure.server.com/check-login?subdomain=subdomainB`.

Dan 2010-02-02 15:42:22

@Dan: bad luck then! I updated the post with the link to the source.

Nickolay 2010-02-02 16:22:08

You have exactly two solutions then.1: different ports redirecting to https://, one per subdomain.2: subdomains of `secure.` for each subdomain.

SF. 2010-02-03 09:03:32

+1 A:

AFAIK domain name (complete) is the current basis for remembering login. It wasn't always so, though. I'm not sure about protocol or port number, but a.domain.com is different from b.domain.com and domain.com, but same as a.domain.com/somewhere.

SF. 2010-02-02 13:55:51

ansaurus

tags:

views:

answers:

Firefox: What's the basis for remembering login information?

related questions