Using URL question - phishing protection?

[tanstaafl]

Is it more secure (to prevent phishing risks) to set the 'When URL Contains' field to something like:

.google.com/ (note the preceding '.' and the trailing slash)

instead of just

google.com ?

I've been doing this, so that if the target site gets hijacked and I get sent to a site like google.fraud.com or fraudgoogle.com, the password would be different (and hence not work).

Am I unnecessarily complicating this? Or, does PM already take this into account?

I recall there was talk of providing a 'When URL IS EQUAL to' option, for when Auto-Submit was implemented for this very purpose, so my guess is no.

[Miquel 'Fire' Burns]

Hmm, good point. Never thought of that.

[Romeo]

Those are very valid points.  This is why I said before that may be the when URL equals should probably be changed to when dmain is equal to.  But it shouldn't just stop at the cosmetics, the verbage.  It should actually make sure that the domain realy is what you say it's supposed to be, before the PW is entered.

I think doing this would eliminate a lot of the confusion. - Eric, what do you think?

If I am not mistaken, the domain for URL mail.google.com would reduce to the domain google.com, while the URL google.xyz.com would reduce to the domain xyz.com, correct?

[quixin]

This related item is on the request list:

Public key of secure sites chached and verified upon re-visits

Can the Public key of secure sites be cached, and then verified against the site certificate when re-visiting the site to ensure the password is really being entered into the same site? This would prevent devulging passwords to imposter phishing sites that use things like DNS or ARP posioning.

[Romeo]

correction:

The unique name that identifies an Internet site. Domain names have two or more parts separated by dots. For example www.kansasmedicare.com

That means that google.com.xyz.net would also be a domain name.  Neither here, nor there; may be we should call it when URL ends in and, of course have it function that way too.

edit:google definition.

[Eric H. Jung]

Is it more secure (to prevent phishing risks) to set the 'When URL Contains' field to something like:

.google.com/ (note the preceding '.' and the trailing slash)

I've been doing this, so that if the target site gets hijacked and I get sent to a site like google.fraud.com or fraudgoogle.com, the password would be different (and hence not work).

Makes sense for custom accounts. This is one of the advantages of using the Default Settings: the url always affects the password, so fraudgoogle.com would never produce the same password as google.com.

I think doing this would eliminate a lot of the confusion. - Eric, what do you think?

I think I'm a little confused. Are you saying you want auto-populate to change so it only works when the domain name equals a URL (rather than contains a URL)?

[Romeo]

I think I'm a little confused. Are you saying you want auto-populate to change so it only works when the domain name equals a URL (rather than contains a URL)?

I think it should say and do autopopulate only when domain, or URL ends in.

In other words, if you say when domain or URL ends in google.com, you would eliminate the risk of the PW being entered for URL google.com.xya.net, correct ?  To the best of my knowledge, the last two patrs of the domain, ie. google.com can only be used by the company, which registered / paid for the domain.

correction That would not eliminate the risk of someone using xyzgoogle.com.
I am not sure what you would call the last two pieces of the domain name, google.com.  Would anyone know the terminology?

[tanstaafl]

top-level domain?

[tanstaafl]

Maybe the most secure thing to do is:

Change the 'When URL Contains' to 'When Domain Equals'.

Code PM so that it if I put 'google.com' in this field, PM evaluates it in the following manner:

http://www.google.com/anything = true
https://google.com = true
http://fraudgoogle.com/ = false
http://www.fraud.google.com = false
http://www.google.com.xyz.net/ = false

Hopefully you see the pattern...

[Miquel 'Fire' Burns]

I say allow entering RegEx in that field, like how Adblock does it now. Maybe have a checkbox or something in which a user can have it do domain or full url checking (in case they want two passwords for one domain, but the path name is what determines which password to generate, like some password entry on a Geocities site).

Still not sure how to handle new users though since Regular expressions are a pain to learn. Well, they can be.

[tanstaafl]

Supporting regex would be a good thing for power users, but I don't think its necessary, and would probably be difficult to implement (or maybe not? hard to say for a non-programmer)... but what is it we're trying to accomplish? First, make PM as secure as possible, right? Second, keep it as simple as possible?

There are two ways of looking at this:

User enters 'google.com' (minus the quotes) into the 'When URL Contains' field...

1. Leave the URL entry as a 'contains' argument like it is now

Code PM so that it evaluates URLs according to the pattern I described before - specifically, it only allows for characters preceding what the User enters into the URL field if they are separated by a '.' (dot), e.g., for the above given URL:

mail.google.com is valid
mailgoogle.com is NOT valid

and only allow characters after what is entered into the URL field if they are preceded by a '/' (slash), e.g., again for the above given URL:

mail.google.com/login.asp is valid
mail.google.com.xyz.net/login.asp is NOT valid

 O_o

OR

2. Change it to 'When Domain Equals'

I don't like this option - pages get moved around and changed, and things start breaking - and although I guess it does provide much more rigid protection - but is it really necessary?

I think option 1 is more than adequate, and it gets my vote - if this is going to get changed in the first place.

[Miquel 'Fire' Burns]

I think adblock only does RegEx if the string is surrounded by '/'

But having PM use option 1 sounds good for when RegEx is not in use. Wording will be hard to figure out for the label if I want something like this: somefreesitehosting.com/name1
Then I want the following to apply:

somefreesitehosting.com = false
whatever.somefreesitehosting.com/name1 = true (though a way to make this false would be nice, only with RegEx I think, as www can be whatever.)
somefreesitehosting.com/name2 = false
somefreesitehosting.com/name1/moo = true

[tanstaafl]

But having PM use option 1 sounds good for when RegEx is not in use.

As I said, I think supporting regex here is way overkill and unnecessary - but don't see anything *wrong* with it if Eric wants to do it. I think there are a lot of other features that should be a higher priority though...

Wording will be hard to figure out for the label if I want something like this:

somefreesitehosting.com/name1

Then I want the following to apply:

somefreesitehosting.com = false
whatever.somefreesitehosting.com/name1 = true (though a way to make this false would be nice, only with RegEx I think, as www can be whatever.)
somefreesitehosting.com/name2 = false
somefreesitehosting.com/name1/moo = true

All of these evaluate as you want with my suggestion 1, except for your desire to make the second one false... though if Eric also allowed a second choice for the 'When URL Contains' mode, and allowed *either* 'When URL Contains' or 'When URL Equals', this would allow you to do what you want.

I guess the evaluation pattern could also be made optional on both/either sides of the provided URL - ie, have checkboxes to disable pre-URL and post-URL validation (where URL is the text entered into the 'When URL Contains' field by the User), but again - what is gained? I don't see a lot of benefit... if you enter 'somefreehosting.com/name1', then 'somefreehosting.com/name2' would evaluate as false.

I'd prefer to just have PM do 'smart' URL validation and be done with it. Most likely it wouldn't be too difficult to provide the 'When URL Equals' choice, so don't see why that wouldn't provide the best of both worlds.

[Miquel 'Fire' Burns]

I guess the evaluation pattern could also be made optional on both/either sides of the provided URL - ie, have checkboxes to disable pre-URL and post-URL validation (where URL is the text entered into the 'When URL Contains' field by the User), but again - what is gained? I don't see a lot of benefit... if you enter 'somefreehosting.com/name1', then 'somefreehosting.com/name2' would evaluate as false.

Suppose if I want somefreehosting.com/name2 to be false (If a Geocities site have a reason to use passwords, then I don't want to risk that password being used someplace else)

Also, I want RegEx because of a special situation here at my job. There's a site I can access with the computer name, and the full domainname. Using mail.google.com as the example domain, that means I can hit it with mail and mail.google.com. Then there's the fact some web apps here use different passwords methods, one of which the dropping ot google.com works, but at times, I want the full mail.google.com to be used in some directories.

[tanstaafl]

I guess the evaluation pattern could also be made optional on both/either sides of the provided URL - ie, have checkboxes to disable pre-URL and post-URL validation (where URL is the text entered into the 'When URL Contains' field by the User), but again - what is gained? I don't see a lot of benefit... if you enter 'somefreehosting.com/name1', then 'somefreehosting.com/name2' would evaluate as false.

Suppose if I want somefreehosting.com/name2 to be false

I just said that evaluating it according to the pattern I described, it WOULD be evaluated as false. Maybe I'm misunderstanding?