Password Policy - Phishing Prevention

MitM

One way I've seen as an attempt to combat phishing is to have a password management policy that requires employees to enter a bad password when they are prompted to login from a link that they clicked in email.

The thinking is a legitimate site will not accept a bad password but a phishing site would

Any thoughts on this? Is a good/realistic idea

UnixGuy

How would the phishing victim know that they are on a malicious link? The reason they give away their passwords is because they think they're browsing a legitimate link.

2-Factor authentication, and a continuous education & awareness program are the only two effective remedies that I know of. 

MitM

That's exactly the point, they wouldn't.  That's why the policy would require them to always enter a false password, any time that they are prompted to login after clicking a link from an email

Jon_Cisco

My biggest concern with this is it might encourage them to click a link in the first place. I would not want to encourage users to click any links or provide any input but I do think it's an interesting idea.

scaredoftests

Agreed. And some people, even though they are told repeatedly NOT to click any link, will then do so after doing the above..

MitM

I agree. It is an interesting idea though. I think it is more useful as a tip, instead of a policy

I also agree with @UnixGuy comments regarding 2FA and continuous  education + awareness

paul78

@MitM - usually what I recommend is that if an end-user gets an email with a link in it claiming to be from a site that the end-user accesses or has an account; instead of clicking on the link, it's better to just open a browser and enter the website that's known to the end-user.

MitM

@paul78 agreed. This is what I do too

tedjames

We train our users not to click on links right away. First, hover over them to show the actual link. Then, key it in manually. And if they are not sure, they can always forward the email as an attachment to us to check out first. We have a really security-savvy group of users.

paul78

tedjames said:

We train our users not to click on links right away. First, hover over them to show the actual link. Then, key it in manually. And if they are not sure, they can always forward the email as an attachment to us to check out first. We have a really security-savvy group of users.

The "key it in manually" step is really key. (pun intended) Many people don't understand how multibyte unicode IDN's can be abused.

Johnhe0414

Education and training - we use a web blast for continuous tips and warnings throughout the week.

MitM

tedjames said:

We train our users not to click on links right away. First, hover over them to show the actual link. Then, key it in manually. And if they are not sure, they can always forward the email as an attachment to us to check out first. We have a really security-savvy group of users.

100% agree.  This is the one thing I hate about O365 ATP Safe Links. It rewrites the URL

paul78

100% agree.  This is the one thing I hate about O365 ATP Safe Links. It rewrites the URL

Just my 2 cents - but I find it preferable to use O365 ATP vs url inspection. I'm not a fan of having end-users inspect the URL and then clicking on the link because most end-users are not able to detect a malicious URL - and even a sophisticated user can be fooled with an IDN. I rather that the end-user simply access the site that they believe is attempting to send them an email.

BTW - the latest version of Outlook decodes the ATP URL and displays the actual original URL. Perhaps you haven't patched <just kidding>

MitM

paul78 said:

100% agree.  This is the one thing I hate about O365 ATP Safe Links. It rewrites the URL

BTW - the latest version of Outlook decodes the ATP URL and displays the actual original URL. Perhaps you haven't patched <just kidding>

hmmmm What version? I'm running 1803 (Build 9126.2295). When you hover the link, it shows

na01.safelinks.protection.outlook.com/?URL=<somewhat of the actual link>

UnixGuy

MitM said:

That's exactly the point, they wouldn't.  That's why the policy would require them to always enter a false password, any time that they are prompted to login after clicking a link from an email

so what happenes when they click on a malicious link, it asks them for a password, they enter a false password..malicious link responds with 'failed login', then they enter correct password..malicious link responds with 'failed login' again...I don't see how it'll prevent the passwords from being stolen

MitM

UnixGuy said:

MitM said:

That's exactly the point, they wouldn't.  That's why the policy would require them to always enter a false password, any time that they are prompted to login after clicking a link from an email

so what happenes when they click on a malicious link, it asks them for a password, they enter a false password..malicious link responds with 'failed login', then they enter correct password..malicious link responds with 'failed login' again...I don't see how it'll prevent the passwords from being stolen

Valid point. I don't know. I didn't come up with the idea, was just something I came across

paul78

hmmmm What version? I'm running 1803 (Build 9126.2295). When you hover the link, it shows

na01.safelinks.protection.outlook.com/?URL=<somewhat of the actual link>

I'm running 1811 (Build 110029.20079). We enable Targeted releases.

I just poked around and I see the same behavior but rarely. I notice that the original URL is NOT displayed only if the HTML uses nested tables. 

yoba222

Malicious websites can infect end-users by simply visiting the site--no interaction needed. Encouraging end users to visit a potentially malicious website is a bad idea.

MitM

yoba222 said:

Malicious websites can infect end-users by simply visiting the site--no interaction needed. Encouraging end users to visit a potentially malicious website is a bad idea.

I agree but this was not about encouraging end users to visit a potentially malicious site.  This is strictly a policy that states IF an end user clicks a hyperlink from email and is prompted to login, they MUST first enter a bad password.

While an interesting thought, I don't see it as practical

LionelTeo

How is it entering a bad password going to help against a phishing site that would always prompt incorrect username or password? Also, is this policy enforce in its technological control? What about employee simply choose to enter their correct password on first login.

MitM

LionelTeo said:

How is it entering a bad password going to help against a phishing site that would always prompt incorrect username or password? Also, is this policy enforce in its technological control? What about employee simply choose to enter their correct password on first login.

It wouldn't.  I'm not sure how successful this is (or could be). It was mentioned at some event I was at