PasswordMaker Forums
Firefox/SeaMonkey/Mozilla/Netscape/Flock Browser Extension => Help and Support => Topic started by: tanstaafl on October 07, 2005, 01:13:46 PM
-
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.
-
Hmm, good point. Never thought of that.
-
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?
-
This related item is on the request list:
Public key of secure sites chached and verified upon re-visits (http://forums.passwordmaker.org/index.php?showtopic=136)
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.
-
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. (http://www.google.com/search?hl=en&hs=PLD&lr=&client=firefox-a&rls=org.mozilla:en-US:official&oi=defmore&defl=en&q=define:domain+name)
-
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)?
-
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?
-
top-level domain?
-
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 (http://www.google.com/anything) = true
https://google.com (https://google.com) = true
http://fraudgoogle.com/ (http://fraudgoogle.com/) = false
http://www.fraud.google.com (http://www.fraud.google.com) = false
http://www.google.com.xyz.net/ (http://www.google.com.xyz.net/) = false
Hopefully you see the pattern...
-
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.
-
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.
-
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
-
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.
-
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.
-
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?
-
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.
? If you put 'mail.google.com' in the 'When URL Contains' field now, plain 'mail' will *not* be a match... so again, I must be missing something... :unsure:
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.
So you set up an account for each using the URL you want evaluated...
Ok, I'm tired... it's been a long day (my wife has migraines on occasion and we were up most of the night last night), so I'm gonna go over this thread in the morning and see if I can see what I'm apparently missing... sorry for the confusion...
-
If a non-programmer, non-geek-i-zoid, non-computer expert, just a simple user that is curious and would like to put in $0.002 worth of ideas.
Why not make it so the 'Use this URL' be made to indicate the site you are wanting to login to and not modifiable, if it gets modified you are NOT loggedin. Even if the 'Auto-Populate UserName & PassWord' is checked, if they do not fit then you cannot convict er enter. If there is more added to the end, after the / (slash) then it will not work. 'When the URL contains' field can contain the same or a part of that addy so there is an unknown added there as part of your Modifier, but not that field. There is another unknown, not having a full URL or Domain in the the "When the URL contains' field.
Or am I not really understanding your point in this? I am using 'SpoofStick' v1.05 maybe this can be used in PassWordMaker so that if 'SpoofStick' does not match you will not be taken to that website/w a notice dispalyed, 'The site you attempted to access is not valid or not the one you wanted.'
-
With the prevalence of phishing schemes now, I think this is an important feature - even more so for the average user than for the experienced folk. (fwiw, I consider myself pretty experienced, but I almost got caught by a phishing email last year - it was late, I was busy, and I got a report that my credit card had anomalous information posted, and "here's the link to your account" - dammed if I didn't click the link and get ready to enter the password before I caught myself!)
Having PM recognize "this isn't the right site" will create smiles every time it saves someone from a phishing scam. A Good Thing...
I have to admit, I didn't read the docs much, and I was confused by the two URL fields at first. (for that matter, I'm not sure if I understand all the nuances even now; gotta read the docs sometime... :)
Considering that there's a push to move the more-complex parts of the password configuration away from the more user-friendly parts, how about something along these lines?
The user would see two fields - the first is the actual URL; the one they *should* be at.
They'd also have a "what's important in this URL" field that shows what must match the URL in the browser for this account to be used for this site.
Something like:
Web site URL: http://www.google.com/anything
Important parts, to recognize this web site: http://www.google.com/anything
This shows that the entire thing must match for this account to genterate a password at this URL. If there's anything different (even https instead of http) it won't match and will be rejected; no password will be generated.
The user can adjust what's important (maybe highlight a part and tap a button that says "not important" or "important" ? Dunno...)
So they could make it:
Web site URL: http://www.google.com/anything
Important parts, to recognize this web site: http://www.google.com/anything
This indicates that this account is valid with:http://www.google.com/anything
http://google.com/anything
http://mail.google.com/anything[/li][/list]but would NOT work with:http://www.google.com/anything/andsomething
http://www.google.com/something
http://www.google.com.badguy.xyz/anything[/li][/list](the big question is: is this clear to general users? I suspect it isn't... so better is needed)
There could also be a "allow anything here" indicator:
Web site URL: http://www.google.com/anything
Important parts, to recognize this web site: https://www.google.com/anything(allow any text)
The idea here is to show that http:// is ok, https:// is also ok (i.e., the 's' is permitted but not required) and anything can follow the URL and it's ok.
Hmmm... even as I type this it seems ugly and confusing to me... How can it be made flexible to power users (RegEx seems reasonable - but you'll never in a million years get my wife or father-in-law to use 'em) and simple enough for the vast general user?
Another thought - won't the average user look at PM when it's NOT generating a password and just think "it's not working - it's broken" (meaning PM) - they won't recognize they're not where they think they are?
Should there be something like a "why isn't this generating the password?" button, so when they're at http://www.mybank.com.ru (http://www.mybank.com.ru)
instead of https://www.mybank.com (https://www.mybank.com)
they can tap that button and see:The top-level domain differs: ru instead of com
The second-level domain differs: com.ru instead of mybank.com
The entire host name differs: www.mybank.com.ru instead of www.mybank.com
Protocol differs: http:// instead of https://
DANGER!
YOU ARE NOT AT THE RIGHT WEB SITE!
POSSIBLE PHISHING SCAM![/li][/list]Just imagine your non-expert friend's reaction when that happens and they realize PasswordMaker just protected them from losing their bank account. Think they'll tell all their friends how good PM is? :)
- Al -
-
Excellent post AL ! I especially like the part where you say:
Just imagine your non-expert friend's reaction when that happens and they realize PasswordMaker just protected them from losing their bank account. Think they'll tell all their friends how good PM is?
you also have some good ideas in there.
One thing no one has talked about yet, is the certificate, the SSL certificate. Most reputable firms will have one of those. If they do not, I don't deal with them - tough for them. I do not know if anyone has ever taken the time to view the certificate, they will have noticed that there is a place for the Issued to entity. I do not know if PM can read this, but if it could, PM could compare that name to a name, to be sure even the CN, the common name, that was previously set up in PM by the user. If it doesn't match, WARN the user about it.
As I was proof reading this, I did remember that something about this had been brought up before, but the request was only asking about remembering the certificate and then comparing it, which is sort of along these lines.
edit: I take that back. On of my bank doesn't use SSL on the ign in page. So may be this wouldn't be a good idea.
-
Thanks, Romeo!
Sometimes my ramblings do have something useful hidden inside... :)
I've always wondered about certificates - I usually just click "accept 'em" unless there's something really odd about them. I suspect most others do to...
For that matter, why can't a phisher set up a *valid* certificate for their bogus website? Dunno what it takes, but if it's possible, it'd be a serious false sense of security.
I think we really just need to breed a better level of human being... :)
Hey, is that avatar really you? It reminds me of Easy Rider. I've got an '84 Gold Wing.
- Al -
-
May be just a litle note could pop up when the user enters the URL for when URL contains syaing The more of the URL you specify here, the less the likelyhood that a phishing scam will work. Then have a help link on this warning on there explaining what is meant by this. i.e. http://signon.ebay.com (http://signon.ebay.com) will be more secure than ebay.com.
-
Al,
Hey, is that avatar really you? It reminds me of Easy Rider. I've got an '84 Gold Wing.
No that is not me. I do, however ride a '99 BMW R1100R.
-
May be just a litle note could pop up when the user enters the URL for when URL contains syaing The more of the URL you specify here, the less the likelyhood that a phishing scam will work. Then have a help link on this warning on there explaining what is meant by this. i.e. http://signon.ebay.com (http://signon.ebay.com) will be more secure than ebay.com.
But http://signon.ebay.com/ (http://signon.ebay.com/) (with the trailing slash)
will be even more secure.
http://signon.ebay.com (http://signon.ebay.com) would match with http://signon.ebay.com.phishing.scam/ (http://signon.ebay.com.phishing.scam/)
The more I think of this, the more important I think it is for the general user! (and me, 'cause I'm stupid sometimes... :)
I'll bet we could come up with some rules that would indicate the relative security of the URL. To start with:- ebay.com/ is better than ebay.com, but not really very good - it'd match http://phishing.com/ebay.com/ (http://phishing.com/ebay.com/)
- specifying the full protocol and domain is better (best?): http://signon.ebay.com/ (http://signon.ebay.com/)
- Al -
Only kings, presidents, editors, and people with tapeworms have the right to use the editorial "we."
- Mark Twain
-
The more I think of this, the more important I think it is for the general user! (and me, 'cause I'm stupid sometimes...
Ditto...
While I agree with the intent of all of these suggestions, I think it is becoming unnecessarily complicated. Also, I think we are al saying the same things, just in different ways.
To summarize - in my opinion, by default, PM should *automatically* and *invisibly* protect against phishing attempts through the use of isolating the top-level domain - ie, allowing only the preceeding dot and trailing text *after* the slash, per my previous examples. Of course, this behavior should be well-documented, with all of the reasons we are talking about here (for anyone who knows about and understands such things).
Also, I would be against this behavior being 'optional' - it just doesn;t make sens in my book to allow a 'less-secure' mode.
The primary issue I see is how this would impact current Settings. A major goal of Erics - and understandably so - is to not introduce anything into PM that will break current passwords unless it is *absolutely* necessary, so this would probably have to have some kind of built-in compatability mode, that would simply keep nagging the user to change any password that is using the less secure URL.
I think we have provided more than enough specific examples, and Eric will come up with a simple, clean way of implementing this - assuming he sees the value in it.
-
The more I think of this, the more important I think it is for the general user! (and me, 'cause I'm stupid sometimes... :)
Very strange happenings with this software, will post in a seperate topic after I finish with this.
"ajw,"
Excuse me on this one point, you do NOT hold the market on being STUPID. You have to share that with the remainder of us. Or we will have to give each of us our own corner, which is not, in reality, possible.
From my perspective the full URL for login should be in the window 'Use this URL' then if there is anythingy else there it will not get a password that is in your groups. I am using 'SpoofStick' that will display the actual site I am on and if it is not what I am supposed to be on, even though the correct one is shown in the location window, do not login. It comes back to you have to be observant and smarter than the phisher.
"tanstaafl"
". . . Eric will come up with a simple, clean way of implementing this . . ." now let Eric do it. Well he is the final say so on what to do.
I will not put anymore ideas here so he can work on what we have given him to sort out already.
CU L8R,
-
Excuse me on this one point, you do NOT hold the market on being STUPID. You have to share that with the remainder of us. Or we will have to give each of us our own corner, which is not, in reality, possible.
Hmm.... each our own corner... infinite people, infinite corners... polygons.... triangle -> square -> pentagon -> ...
With enough corners, it becomes round
Round... like a ring... One Ring! :)
- Al -
-
Hmm.... each our own corner... infinite people, infinite corners... polygons.... triangle -> square -> pentagon -> ...
With enough corners, it becomes round
Round... like a ring... One Ring! :)
- Al -
Visious Circle/w teeth!!
CU L8R,
-
Al,
But http://signon.ebay.com/ (http://signon.ebay.com/) (with the trailing slash)
will be even more secure.
of course, do as I mean, not as I write. I have just changed all my settings to contain a trailing slash, even thought I wrote it w/o the slash.
tanstaafl,The primary issue I see is how this would impact current Settings. A major goal of Erics - and understandably so - is to not introduce anything into PM that will break current passwords unless
When you change the entry in When URL contains, the password is not affected. Trust me, I just made the changes to all my accounts.
Earlier, I was actually going to do a post on the difference between When URL contains vs. Use this URL, but I shyed ??? away from that for some reason.
-
Ok, back to the question at hand...
I'd like to thrash this out some more before I go file a Request... I'd also like to hear some input from Eric - ie, are you interested in this at all?
The goal is to implement some form of automatic phishing protection for critical Accounts. According to Eric, this already happens when the Defaults are used, so this discussion is only relevant to Custom Accounts.
What I'm hoping for is to get PM so that it recognizes a true domain from a fake automatically. Currently, one way this could be implemented manually, would be to code PM so that all you'd have to enter in the 'When URL Contains' field is 'domain.com', and PM would evaluate it thusly:
*[.]domain.com[/]*
where the preceding '.' (dot) is the only character allowed (but not required) to immediately precede what is entered, and the trailing '/' (slash) is the only character allowed (but not required) to follow the last character entered. The asterisks are, of course, wildcards, so could be any valid URL characters.
The only problem with doing it this way is it is highly error prone...
How about having the actual Top-Level Domain automatically *captured* by PM (with visual confirmation?) when the Account is created, but kept *separate* (and uneditable) from the 'When URL Contains' field. Validate it *first* (according to the rule above) - *before* checking for matching text (if the User puts anything in the 'When URL Contains' field). If nothing is entered in the 'When URL Contains' field, then the 'Use This URL' field could be greyed out (or not).
Thoughts?
-
I'd also like to hear some input from Eric - ie, are you interested in this at all?
Sure.
The only problem with doing it this way is it is highly error prone...
Why is this error-prone?
-
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 (https://www.google.com/accounts/ServiceLogin?service=mail&passive=true&rm=false&continue=http%3A%2F%2Fmail.google.com%2Fmail%3Fui%3Dhtml%26zy%3Dl<mpl=wsad<mplcache=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.
-
For example... if the login page is one of those long strings like gmail:
https://www.google.com/accounts/ServiceLogi...plcache=2&hl=en (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.
-
For example... if the login page is one of those long strings like gmail:
https://www.google.com/accounts/ServiceLogi...plcache=2&hl=en (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...
-
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?
-
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 .___________ /
-
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/ (http://www.google.com/), because it would make it into .http://www.google.com//, correct?
-
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/ (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?
-
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.
-
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 -
-
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 (http://forums.passwordmaker.org/index.php?showtopic=461) message to hopefully help some people that are coming here to look for help.
-
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.
-
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/ (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 :))
-
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 (http://www.google.com), as well as http://login.google.com (http://login.google.com) ? To go even further, what about http://*.*.google.com to match http://signin.thisaccount.google.com (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.
-
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.
-
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.
-
Yeah, yeah, what he said!
-
Yeah, yeah, what he said!
Eric, the man of many words.
-
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.
Ok, I'll give this another shot - but with much less certainty...
I think Eric provided a hint of how we can accomplish this for everyone, when he answered one of my dumb questions:
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.
First, understand that, the way I am seeing this work, the following is simply a new 'URL Validation Test' performed by PM - it isn't used to *calculate* the password, it is only required to test 'true' before PM *generates* the password. In other words, it is *invisible* to the User. I guess it could be made optional (give a warning but still generate a password), but I'd rather it didn't...
So, that said, maybe a modified version of my previous suggestion would work? Something like:
'Protocol'+'subdomain(s)'+*[.]+domain.com+[/]*
with the following hard-coded limitations:
1. the 'Protocol' is required
2. only valid subdomains are allowed
(ie, no slashes allowed between protocol and domain, and any valid URL text between the 'protocol' and 'domain' must end in the '.' (dot)
3. only valid subdirectories allowed
(ie, a single slash is the only character allowed (but not required) to immediately follow the domain. The asterisks are, of course, wildcards, so could be any valid URL characters *except '//' (double-slashes).
Hopefully there is actual coding already available (AntiPhish (http://www.infosys.tuwien.ac.at/antiphish/)?) that will make this relatively easy for Eric to implement once he decides on how he wants to do it.