Possible security vulnerability

[juliandroms]

Actually, I posted the question, then I thought I answered it myself, but now I'm not so sure. It may actually be a vulnerability.

It's true, passwordmaker will populate the fake site with a username and password, but will it populate it with the correct password (and hence will an imposter get your password for the site he is forging)?

My thought is, "yes", because in the passwordmaker "account specific settings", the autopopulate function actually selects the string to use for the hash from the "use the following URL to calculate the generated password" field; it doesn't take it from the actual domain name of the page you are visiting. So, even if your browser is pointed to the wrong domain name, it will enter the correct calculated password for the orignal domain name into the web page at the imposter domain name...

So, in fact, an imposter in a phishing attack could set up a fake web site to troll for passwords generated and autopopulated by passwordmaker.

I think it is in fact a security vulnerability? Is it not?

Somebody reasure me here...

Wait no, I just answered my own question. It would be populated with the incorrect password, wouldn't it? Because in our example the url that starts as the base for the hash would be "thief.com", not "google.com", right?

Thanks. I feel better.

Awesome program! I love it!

Hi, I wanted to be reassured that there is not a security vulnerability.

Say I create an account (for example on google.com) and set it to auto-populate whenever it finds a url matching the wildcard url string *google.com/* .

What happens if someone (a thief, say someone sending a link in a phishing attack) creates a web site with the following url, and finds a way to direct people to it:

http://www.thief.com/google.com/login

The person owning this web page could put up a page at that url that looks identical to a google.com login page, and the page would automatically be populated by passwordmaker with the username and password for google.com . If the page is submitted, wham! the thief has the person's google.com username and password.

I've already tried something similar with the url:

http://www.nytimes.com/auth/login?URI=http://

...where the wildcard */login* will populate this web page, regardless of whether */login* appears in the domain name or somewhere else in the url, so it is apparent that this would work if a thief thought it was worthwhile to do.

Granted, a careful user would pay attention to the url menubar in the browser, and note that it is not the real google web site before he clicks the "submit" button (and provided there is no way for the thief to set the page to submit without user interaction). But this merits a certain level of user sophistication and attentiveness. Plus, I've heard that certain browsers have security vulnerabilities where java scripts and so forth can be used to over-write the menubar url with a fake one (e.g. http://www.google.com/login).

Am I not correct? Would it not be safer to have passwordmaker match regular expressions to the domain name only, by default? An then add an option for more extended matches to the entire URL (perhaps with a warning). By my understanding, the domain name is the only "safe" part of a url which grants the user a reasonable amount of certainty that he's browsing the correct page. Am I wrong here?

I'm sure it's possible to construct regular expressions to match domain name only and not if the matching string appears in other parts of the url, but that's a pain and nobody is practically speaking going to do it.

Or am I missing something here? Is there an easy way to do this with passwordmaker that I do not know?

Has it been discussed already?

[Miquel 'Fire' Burns]

When using wildcards, I would suggest trying not to start the URL to match with a *, and not using * until after the domain (along with the first / character afterwards) is found.

A bit of a pain if you have to support multiple subdomains though.

Hopefully you can catch a site trying to hijack your PasswordMaker usage before it submits though, provided it doesn't auto-submit and that it doesn't have a way to fake the URL bar (This is something I never seen before actually. Something tells me this can only really be caused by an extension)

[Eric H. Jung]

Huh? Why do I get the feeling that I missed the original post, or it's been edited?

[Miquel 'Fire' Burns]

It's been edited. The link on the quote just goes to this thread.

[juliandroms]

When using wildcards, I would suggest trying not to start the URL to match with a *, and not using * until after the domain (along with the first / character afterwards) is found.

A bit of a pain if you have to support multiple subdomains though.

Hopefully you can catch a site trying to hijack your PasswordMaker usage before it submits though, provided it doesn't auto-submit and that it doesn't have a way to fake the URL bar (This is something I never seen before actually. Something tells me this can only really be caused by an extension)

Actually, I posted the question, then I thought I answered it myself, but now I'm not so sure. It may actually be a vulnerability.

It's true, passwordmaker will populate the fake site with a username and password, but will it populate it with the correct password (and hence will an imposter get your password for the site he is forging)?

My thought is, "yes", because in the passwordmaker "account specific settings", the autopopulate function actually selects the string to use for the hash from the "use the following URL to calculate the generated password" field; it doesn't take it from the actual domain name of the page you are visiting. So, even if your browser is pointed to the wrong domain name, it will enter the correct calculated password for the orignal domain name into the web page at the imposter domain name...

So, in fact, an imposter in a phishing attack could set up a fake web site to troll for passwords generated and autopopulated by passwordmaker.

I think it is in fact a security vulnerability? Is it not?

[juliandroms]

When using wildcards, I would suggest trying not to start the URL to match with a *, and not using * until after the domain (along with the first / character afterwards) is found.

A bit of a pain if you have to support multiple subdomains though.

Hopefully you can catch a site trying to hijack your PasswordMaker usage before it submits though, provided it doesn't auto-submit and that it doesn't have a way to fake the URL bar (This is something I never seen before actually. Something tells me this can only really be caused by an extension)

Agreed, but most people using passwordmaker don't know enough to do this, and it seems like the policy could be changed easily enough.

Granted, for phishing attacks, the problem is probably theoretical at best, but only because the installed base of passwordmaker is not so ubiquitous that any phishing scammer would take its design into account. But that could change, since it's such a great piece of software.

Honestly, I hope it does, but I think, unless someone has some other take on whether passwordmaker is vulnerable to phishing attacks, it's something that may give some people pause. It's one thing for someone to clinck on a link in an e-mail (always a bad idea) and be presented with a site that looks exactly like the site they are expecting (BAD idea). But it's something altogether another problem, if the user gets an additional false visual apparent validation from passwordmaker that they are at the correct site (when they are not) when passwordmaker even fills in what they think is their correct username and password - into the incorrect site.

I don't have the capability to set up a web site myself to verify that this scam woudl work, but based on what I know and from looking at the overall design of the software, it seems like it would be a concern.

What do you all think?

[Miquel 'Fire' Burns]

Ideal wildcard are like the following:

http://forums.passwordmaker.org/*
http://google.com/login*
http://www.google.com/login* (for the www part)
etc.

The following, may be hijacked:

http://*passwordmaker.org/* (matches http://hacker.com/passwordmaker.org/, http://fakepasswordmaker.org/ for example)
http://forums.passwordmaker.org* (matches http://forums.passwordmaker.org.hacker.com/)

Best practice I see is to only chop off from the right side of the URL, but not too much.

[juliandroms]

Better workaround?

A better workaround seems like it would be to select using a "regular expression" instead of a "wildcard expression", then use something like this:

"https://[^/]*\.yahoo\.com/.*"


where, if I recall correctly, [^/] should be the regular expression for any character other than a "/", and [^/]* would be a string of repeats of such a character (characters other than "/").

I'll try it out and let you know if it works. But still, it seems like a feature request for added security against phishing attacks would be to have the search string for the domain name be separate from the search string for the remainder of the url....

another possibility would be for the default to be to calculate the password by hashing a calculated domain from the actual domain that the user is pointed to, rather than a keyboard-entered domain that is entered into the preferences for an acccount. That way, in case someone is subjected to a phishing attack, passwordkeeper will pass of an incorrect password to the imposter site.

In fact, passwordkeeper if used (or modified with additional features) would be a great stopgap measure against most phishing attacks, since in most cases users don't even know the precise password for each website, so if passwordkeeper refuses to enter it in, the user couldn't enter it in manually if they tried.

A good reference on regular expressions:

http://en.wikipedia.org/wiki/Regular_Expression

[tanstaafl]

The 'average user' is not going to take the time to learn regex, I'm sorry to say. Personally, I'm very dangerous wih them...

That said, I agree with you that this is an issue. Most of us probably get by this by simply using wildcards sensibly, as miguelfire described...

Maybe one way of handling this is to have PWM pop-up a warning to the user if they try to save a URL wildcard pattern that is vulnerable to a phishing attack, with a link to a detailed explanation right there on the warning pop-up?

[juliandroms]

The 'average user' is not going to take the time to learn regex, I'm sorry to say. Personally, I'm very dangerous wih them...

That said, I agree with you that this is an issue. Most of us probably get by this by simply using wildcards sensibly, as miguelfire described...

Maybe one way of handling this is to have PWM pop-up a warning to the user if they try to save a URL wildcard pattern that is vulnerable to a phishing attack, with a link to a detailed explanation right there on the warning pop-up?

Yeah, but just in case anyone wants to know:

[^/]* indicates a string of characters of any length that can contain anything but a "/"

\. indicates a "." - because "." alone has special meaning in regexp, you have to write \. instead.

.* indicates a string fo characters of any length (any characters whatsoever)

s? indicates that there could be a single "s" in this place, or there could be none.


FYI http:// is unsecure, https:// is secure (encrypted web page).

So:

https://[^/]*\.yahoo\.com/.*  -- domain name w/ ".yahoo.com/", secure https only.

https?://[^/]*\.yahoo\.com/.*  --- domain name w/ ".yahoo.com/", secure https or unsecure http.

https://[^/]*\.ebay\.com/.*  -- domain name w/ ".ebay.com/", secure https only.

https?://[^/]*\.ebay\.com/.*  --- domain name w/ ".ebay.com/", secure https or unsecure http.

https://[^/]*\.wikipedia\.org/.*  -- domain name w/ ".wikipedia.org/", secure https only.

https?://[^/]*\.wikipedia\.org/.*  --- domain name w/ ".wikipedia.org/", secure https or unsecure http.

[juliandroms]

Anyhow, awesome software. I love it.

[Miquel 'Fire' Burns]

I have enough on my programming plate right now, I can't eat no more!!! Don't give me ideas!!!

[juliandroms]

I have enough on my programming plate right now, I can't eat no more!!! Don't give me ideas!!!

Oh!  You're one of the programmers!  Sorry! I'm not complaining!  Nice work!

[Eric H. Jung]

Maybe one way of handling this is to have PWM pop-up a warning to the user if they try to save a URL wildcard pattern that is vulnerable to a phishing attack, with a link to a detailed explanation right there on the warning pop-up?

When would you suggest this warning pop-up? If there is a leading asterisk before the (sub)domain for wildcard patterns?

Juliandroms--please don't edit your posts so much because you're confusing me! Instead, just post a reply to the thread.

another possibility would be for the default to be to calculate the password by hashing a calculated domain from the actual domain that the user is pointed to, rather than a keyboard-entered domain that is entered into the preferences for an acccount.

Very early versions of PasswordMaker worked this way, and many other password-generator-programs-based-on-URL work this way. The problem is you're then unable to use the same password for multiple URLs. Many websites have moer than one URL from which you can login. For example, google used to have gmail.com and mail.google.com and google.com/mail (don't think it's that way anymore). Using the approach you describe would generate different passwords for all those sites when clearly you want the same password.

-Eric

[tanstaafl]

When would you suggest this warning pop-up? If there is a leading asterisk before the (sub)domain for wildcard patterns?

Correct.

But, I was thinking that this check could - eventually, if it isn't very easy to do right away - look for more than just a leading asterisk. It would be nice if a decent algorithm could be developed that would evaluate the entire pattern for phishing vulnerablility.

That said, I realize we have had this discussion before, and it was decided that the existence of other anti-phishing tools made it unnecessary to add this to PWM. I never was completely satisfied with that answer though.

I guess the deciding question should be, will this be difficult to do? If it isn't difficult, then my vote would be to add this check directly into PWM. I'm a firm believer in multi-layered security, and this would just be one more layer.

If, however, it is difficult, then there are many other features that I'd rather see implemented first (like my long awaited 'Modifiable Username Prompt' FR)...

For now, though, maybe you should even consider disallowing the use of a leading asterisk altogether - is there ever a good reason to allow it?