I received the enclosed note, apparently from RIPE (and the headers check out).
Why are you sending messages with clickable objects that I'm supposed to use to
change my password?
So because of phishing, nobody should send messages with URLs in them?
If they're intended as a path to log in with a typed password, that's correct.
Sad, but correct.
So because of phishing, nobody should send messages with URLs in them?
more and more these days, i have taken to not clicking the update messages,
but going to the web site manyually to get it.
waaaay to much phishing, and it is getting subtle and good.
randy
Concur.
It seems as if they're no longer written by non-native English speakers, which goes a long way towards making them more insidious. While still perfectly intelligible, most folks who use English as a second language don't speak in the same voice as, say, Wells Fargo corporate communications.
-- Corey
url != clickable object
No problem with URLs in email.
No problem with clickable objects that are unrelated to security.
Minor problem with URLs that lead to changing passwords but can be
mitigated by making the URL very plain and easy to read, even by a
non-techie. They'll at least have to see the thing, even if the mail
client automagically makes it clickable.
Big problem with clickable objects which lead to PII (personally
identifiable information) or passwords. That's how phishing works -- a
disguised url that you either see at all or whose incorrect nature
slips right past your brain. The only known working solution is to
train folks to *never* click security-related URLs in email. Copy and
paste only, and only if they're readable and read right.
Regards,
Bill Herrin
In a message written on Fri, Feb 10, 2012 at 09:29:30AM -0800, Randy Bush wrote:
more and more these days, i have taken to not clicking the update messages,
but going to the web site manyually to get it.waaaay to much phishing, and it is getting subtle and good.
We know how to sign and encrypt web sites.
We know how to sign and encrypt e-mail.
We even know how to compare keys between the web site and e-mail via a
variety of mechanisms.
We know how to sign DNS.
Remind me again why we live in this sad word Randy (correcly) described?
There's no reason my mail client shouldn't validate the signed e-mail
came from the same entity as the signed web site I'd previously logged
into, and give me a green light that the link actually points to said
same web site with the same key. It should be transparent, and secure
for the user.
It seems as if they're no longer written by non-native English
speakers, which goes a long way towards making them more insidious.
While still perfectly intelligible, most folks who use English as a
second language don't speak in the same voice as, say, Wells Fargo
corporate communications.
Most people who use English as their milk language don't speak in the same
voice as Wells Fargo Corporate Communications. 
Cheers,
-- jra
The line gets crossed when you send an unsolicited message that includes a
clickable change password link, that a phisher would find interesting
to emulate.
After the fact, if a phisher gets one of your customers to click on such a
link, you'd like to tell them them in response, or preemptively, that your
company never asks for sensitive information via email.
With good policies in place, the customer should not be receiving clickable
links via email that ask them for a password, except for a scenario where
they've actively generated that email in response to an "I forgot my
password" link on a website.
[..]
There's no reason my mail client shouldn't validate the signed e-mail
came from the same entity as the signed web site I'd previously logged
into, and give me a green light that the link actually points to said
same web site with the same key. It should be transparent, and secure
for the user.
That is a rather nice idea. Most people, especially the common ones, do
not use PGP or heck even S/MIME though and only when one is included in
the web-of-trust can one actually verify these. Of course when that is
done, one should be able to match up email address and website URL quite
easily and your trick will work, at least one can then state:
"the sender, who is verified by trust, is pointing to his/her
own website."
The problem still lies in the issue that most people, even on this very
list, do not use PGP or S/MIME. (and that there are two standards does
not help much there either 
Greets,
Jeroen
There's no reason my mail client shouldn't validate the signed e-mail
came from the same entity as the signed web site I'd previously logged
into, and give me a green light that the link actually points to said
same web site with the same key. It should be transparent, and secure
for the user.
my paranoid side is not comfortable with the certs that come for free
with my browser. see the ietf dane wg.
randy
While still perfectly intelligible, most folks who use English as a
second language don't speak in the same voice as, say, Wells Fargo
corporate communications.
yep. if it's intelligible, it can't really be from wells fargo corp
comms.
randy
Obi-Wan Kenobi: "(shocked) How could this have happened?? We're
supposed to be smarter than this."
Anakin Skywalker: "Apparently not."
And right there, Bill, is the part we so rarely understand, and it kills us:
Even lots of *technical* people just don't understand what "a security-
related URL" *is*, and there's almost always no way to teach them.
So it's necessary to throw the baby out with the bathwater, and tell them
never to click on a link... MUA's that support HTML at all, much less
they fail to tell the user when a text URL doesn't match the actual link,
are the underlying culprits here...
Cheers,
-- jra
In a message written on Fri, Feb 10, 2012 at 06:46:43PM +0100, Jeroen Massar wrote:
The problem still lies in the issue that most people, even on this very
list, do not use PGP or S/MIME. (and that there are two standards does
not help much there either
The problem space is still certificate management.
I bet (nearly) everyone on the list uses an e-mail client that can
decode S/MIME. mutt, pine, Outlook, OSX Mail, gmail, they all do
it. We all have browsers that do SSL.
OSX at least has a central certificate store (Keychain), although
it's not up to the tasks of the world I wish to have. Other OS's
provide no central store, so each application maintains their own
key store. We have a very real problem of pre-loading the key
store, for instance root certificate trust for X.509 certificates.
We need a central certificate store on every platform, easy, secure ways
to transfer/sync it (to say, moble devices), and a bit of UI goo.
Imagine a capability as simple as being able to add a description to a
cert in your key store. I should be able to download my bank's cert,
verify it (call and check finger print, check a trusted third party,
web of trust, probably multiple ways, automated, would be best) and then
tag it "Leo's Bank".
When I get e-mail from it, or go to it with my web browser it should now
say "Leo's Bank" in all of my software, telling me not only do I have
the little padlock, but it's the certificate I personally validated.
When I click on a link in e-mail it should pass the URL AND KEY to
the next program (e.g. my browser). My browser can then silently
load if they are the same, or give me a big pop up "The person who
sent this e-mail is different from the person who runs this web
site."
It's all UI. No new technology, protocols, encryption formats or other
things are needed. It's making end user software act in a responsible
way.
Of course I'd also prefer my bank allowed me to provide my certificate
to them, and they crypto authenticated me (perhaps in addition to
passwords and pins). This should all be two-way.
Leo,
This has nothing to do with the competency of the folks on the nanog list. It's a safe rule in general. Why? Because the stupid on the Internet outnumbers all of us. It's just easier to not send clickable links then it is to have the call center lit up because your users are getting hijacked.
-Hammer-
"I was a normal American nerd"
-Jack Herer
We know how to sign and encrypt e-mail.
there is a public key distribution and trust problem
We know how to sign DNS.
not very reliably yet
randy
Hi Jay,
And if we could just train people to never send or accept email
attachments, we could get rid of email-spread viruses. Not gonna
happen -- the functionality is too useful.
Security isn't just about what you can train someone to do... it's
also about what you can convince them to do when you're not standing
behind them watching -- the instructions that they're willing to
internalize. You can't convince people never to click links in an
email. It's too useful.
You might, however, be able to convince the average person that if a
link they clicked from an email asks for a password or asks for any
personal information then the message was probably from an
impersonator trying to steal the user's identity and they should
report it immediately lest they be victimized.
Regards,
Bill
From: "William Herrin" <bill@herrin.us>
And if we could just train people to never send or accept email
attachments, we could get rid of email-spread viruses. Not gonna
happen -- the functionality is too useful.Security isn't just about what you can train someone to do... it's
also about what you can convince them to do when you're not standing
behind them watching -- the instructions that they're willing to
internalize. You can't convince people never to click links in an
email. It's too useful.
I did admit that it was throwing the baby out with the bathwater.
Being able to drive across someone's golf course to get to work is
convenient for me as well, but I'm still forbidden to do it. This is a
tragedy of the commons problem -- since the biggest target for zombies
on PCs is probably spambots ...
You might, however, be able to convince the average person that if a
link they clicked from an email asks for a password or asks for any
personal information then the message was probably from an
impersonator trying to steal the user's identity and they should
report it immediately lest they be victimized.
Yup. Just like Steve just did in the posting that started this.
Y'know: the thing that only looked like a phish.
Cheers,
-- jr 'and don't even get me started on e-cards' a
Windows has had its own centralized certificate store and APIs since
NT 4.0's release in 1996.
Firefox and Java are the only mainstream software can think of on
Windows that insists on using their own certificate stores (really
just a "pile of world-readable files") instead of the built-in per-
machine+per-user certificate store on Windows.