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)

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.

Ok, thanks, but a follow-up question...

What does PM use to base the password on when the Defaults are used?

For example... if the login page is one of those long strings like gmail:

https://www.google.com/accounts/ServiceLogi...plcache=2&hl=en

What is actually used by PM? Does it evaluate the URL down to just the top-level domain - ie, 'google.com' in this case (I hope, I hope)?

The reason I ask is, what if Google changed this URL (which probably happens all the time) - your password would no longer work and you'd have no way of knowing why.

[Eric H. Jung]

For example... if the login page is one of those long strings like gmail:

https://www.google.com/accounts/ServiceLogi...plcache=2&hl=en

What is actually used by PM? Does it evaluate the URL down to just the top-level domain - ie, 'google.com' in this case (I hope, I hope)?

What it used is determined by which checkboxes you've checked in the URL Components section -- Protocol, Subdomain(s), Domain, and Port, path, anchor, query parameters.

[tanstaafl]

For example... if the login page is one of those long strings like gmail:

https://www.google.com/accounts/ServiceLogi...plcache=2&hl=en

What is actually used by PM? Does it evaluate the URL down to just the top-level domain - ie, 'google.com' in this case (I hope, I hope)?

What it used is determined by which checkboxes you've checked in the URL Components section -- Protocol, Subdomain(s), Domain, and Port, path, anchor, query parameters.

Ok - dang, that one was obvious... :wallbash:

So the default (which uses only the domain) would - in this case - only use 'google.com'... perfect... thanks!

Slowly but surely I'm getting my head wrapped completely around this...

[tanstaafl]

The only problem with doing it this way is it is highly error prone...

Why is this error-prone?

Surely you jest!? ;)

Because it relies on the User to enter the correct string in the field - and the user may not understand exactly what should go here and why.

All I'm suggesting is to add the same phisihng protection to the Custom Accounts as PM provides automatically for logins using the Defaults... but in order to do this, PM would have to 'capture' the actual domain (or whever is selected in the URL components for the Defaults).

Or am I completely missing something really obvious?

[Eric H. Jung]

but in order to do this, PM would have to 'capture' the actual domain

This negates the purpose of When URL Contains field which was to permit people to use the same password for sites like gmail.com and mail.google.com.

What if I simply prefixed When URL Contains with a dot and suffixed it with slash, as you previously mentioned? This can be displayed in the Account Settings dialog like so: When URL Contains .___________ /

[Romeo]

What if I simply prefixed When URL Contains with a dot and suffixed it with slash, as you previously mentioned? This can be displayed in the Account Settings dialog like so: When URL Contains .___________ /

Eric, wouldn't that then disAble someone from entering http://www.google.com/, because it would make it into .http://www.google.com//, correct?

[tanstaafl]

What if I simply prefixed When URL Contains with a dot and suffixed it with slash, as you previously mentioned? This can be displayed in the Account Settings dialog like so: When URL Contains .___________ /

Eric, wouldn't that then disAble someone from entering http://www.google.com/, because it would make it into .http://www.google.com//, correct?

:wallbash: Aaargh! My head hurts!

I thought I had this pretty much figured out...

I guess I'm just gonna have to leave this request at:

Eric, can you please figure out an elegant way to add strong phishing protection to Custom Accounts?

[Romeo]

Eric, can you please figure out an elegant way to add strong phishing protection to Custom Accounts?

Very well put.  I am sure, heck, I even know, that Eric will come up with an elegant solution here.

[ajw]

Because it relies on the User to enter the correct string in the field - and the user may not understand exactly what should go here and why.

Hey guys, stupid user popping up again...   :)

I was just playing with PM; seeing what happens with different settings - how does PM recognize the web site, what affects the password generation, etc.

I just discovered that I *completely* misunderstood how the URL fields are used.

As a result, I've got several sites with the same password.

Ok, I'm different - I make specific accounts for every site.  (that's how I historically have done it; never occurred to me to change...)

I didn't realize that if there's nothing in the "Use this URL" field, then the URL isn't being used as part of the password generation.

I do have a URL in the "When URL contains" field, but changing that doesn't change the generated password.  (I realize now that's being used only to recognize the web site)


What started this was playing with different ways to log in to ebay, and what's necessary to recognize a phishing URL.   (i.e., "when URL contains "ebay.com/" is *not* enough - but if it's a phishing site, will a different password be generated...   the way I'm set up, it won't!  My goof, but there'll be others as dumb as me...)


I've got several accounts set up with the same user name, and nothing in the "use this URL" - they all get the same password.  (although it happens I had them set for different lengths; that's why I didn't notice it at first)

So the actual page URL isn't being used at all in this case...


I found that if I went to eBay, logged out, then clicked the "log in" button I'd end up at a slightly different URL than if I went to the main page and clicked "log in".

When I used the default account, and set it to use the whole URL, I did of course get two different passwords.

That brings up the question - why isn't the URL components checkboxes available on the account-specific settings?   (I guess because you can put whatever's to be used in the "use this URL" field...  that makes sense - I just was looking for them)


I think my point in all this is that I'm supposedly reasonably intelligent, and if I'm confused by this, then how will my wife ever hope to use it?
(assuming that a goal is to get PM into the hands of general users - my wife is smarter - albeit not terribly computer-savvy - than 90% of the folks out there....)


Seems to me this breaks down into two parts:

1) how does PM find the account for the page the user is currently at.  (and more importantly - how does a user understand when they've set something wrong, and PM doesn't recognize the right account!  - I.e., user's set up "www.ebay.com" 'cause that's what they type into the browser - but the URL is at "signing.ebay.com".    The user's left sitting there with the wrong password, thinking "this thing is just broken!" - not good...)
(this ties in to phishing schemes too, btw - can't have URL-recognition be so fuzzy it matches to a phishing URL)

2) how should PM use the URL to generate the password - either of the site they're at in the browser, or subset/specified URL in the account settings - when the user doesn't know a protocol from a tld?
(the answer can't be "educate them" - good answer, but we're dealing with human beings so it fails right there.  why does phishing work in the first place???  :(

Uh, for that matter - in the URL checkboxes - what's "anchor" refer to?  I understand the rest, but that throws me.

(crap, I'm rambling again - one of  these years I have to learn to write concisely...)

- Al -

[quixin]

I think my point in all this is that I'm supposedly reasonably intelligent, and if I'm confused by this, then how will my wife ever hope to use it?

She should stick to the Basic Options so it chooses the URL for her.

(crap, I'm rambling again - one of these years I have to learn to write concisely...)

A very good point.  Some people may be inclined to skip over some of these longer messages. (hint)

1) how does PM find the account for the page the user is currently at. (and more importantly - how does a user understand when they've set something wrong, and PM doesn't recognize the right account! - I.e., user's set up "www.ebay.com" 'cause that's what they type into the browser - but the URL is at "signing.ebay.com". The user's left sitting there with the wrong password, thinking "this thing is just broken!" - not good...)

I noticed that and posted this message to hopefully help some people that are coming here to look for help.

[Romeo]

Al, When URL contains does not affect the password, while Use this URL does.  The When URL contains URL just determines which URL to use, when you browse to the site that matches what is in When URL contains.

I hope this clears it up a bit for you.

edit: Quixin added something to his post before I finished mine.  So I appologize if I am repeating what he is saying.

[Eric H. Jung]

I think my point in all this is that I'm supposedly reasonably intelligent, and if I'm confused by this, then how will my wife ever hope to use it?

She should stick to the Basic Options so it chooses the URL for her.

That, or perhaps the default settings in Advanced Options; i.e., don't create custom accounts? I'm open to suggestions!

I've got several accounts set up with the same user name, and nothing in the "use this URL" - they all get the same password. (although it happens I had them set for different lengths; that's why I didn't notice it at first)

Hm, I should have made Use This URL a required field. I'll do that now, unless anyone objects...

Eric, wouldn't that then disAble someone from entering http://www.google.com/, because it would make it into .http://www.google.com//, correct?

Yes, but so what? PasswordMaker can check if the URL ends with "//" and warn the user when he clicks OK on the Account Settings dialog. What do you think? This is the solution I'd like to use unless you guys find some other flaw I'm not thinking of  (quite likely :))

[Romeo]

PasswordMaker can check if the URL ends with "//" and warn the user when he clicks OK on the Account Settings dialog.

As long as I am able to change it back after PM does it;s thing, I do not see anything wrong with it.

If we all agree that it would be a good idea to have the When URL contains start with http://, couldn't we use wild card characters like say * to set up URLs, so that if you set up http://*.google.com, it would match http://www.google.com, as well as http://login.google.com ?  To go even further, what about http://*.*.google.com to match http://signin.thisaccount.google.com ?  I think this would work, as long as PM would checks that the URL starts with the strings specified above and I think we would be in good shape.

Of course that may require having a check box for check that URL starts with.

[Eric H. Jung]

As long as I am able to change it back after PM does it;s thing, I do not see anything wrong with it.

By "does it's thing", I assume you mean give your the warning? i.e., you want to be able to remove the extraneous "/", correct?

If we all agree that it would be a good idea to have the When URL contains start with http://

I don't agree. I know of at least several people who use PasswordMaker for non-web-applications such as ftp, telnet, and instant messaging.

[Romeo]

I don't agree. I know of at least several people who use PasswordMaker for non-web-applications such as ftp, telnet, and instant messaging.

Ok, you got me.

On my way home, it hit me.  I think everyone is talking about their solution to certain Phishing attempts.  But no one has really defined the problem.  In other words, what would constitute a phishing attempt, or what kind of attempt could be used.  In yet other words, I guess we need a definition of the situation.

Once we've got that, we can start talking about possible solutions.