Dear RIPE: Please don't encourage phishing
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? ------- From: RIPE_DBannounce@ripe.net Subject: Advisory notice on passwords in the RIPE Database Date: February 9, 2012 1:16:15 PM EST To: XXXXXXXX [Apologies for duplicate e-mails] Dear Colleagues, We are contacting you with some advice on the passwords used in the RIPE Database. There is no immediate concern and this notice is only advisory. At the request of the RIPE community, the RIPE NCC recently deployed an MD5 password hash change. Before this change was implemented, there was a lot of discussion on the Database Working Group mailing list about the vulnerabilities of MD5 passwords with public hashes. The hashes can now only be seen by the user of the MNTNER object. As a precaution, now that the hashes are hidden, we strongly recommend that you change all MD5 passwords used by your MNTNER objects in the RIPE Database at your earliest convenience. When choosing new passwords, make them as strong as possible. To make it easier for you to change your password(s) we have improved Webupdates. On the modify page there is an extra button after the "auth:" attribute field. Click this button for a pop up window that will encrypt a password and enter it directly into the "auth:" field. Webupdates: https://apps.db.ripe.net/webupdates/search.html There is a RIPE Labs article explaining details of the security changes and the new process to modify a MNTNER object in the RIPE Database: https://labs.ripe.net/Members/denis/securing-md5-hashes-in-the-ripe-database We are sending you this email because this address is referenced in the MNTNER objects in the RIPE Database listed below. If you have any concerns about your passwords or need further advice please contact our Customer Services team at ripe-dbm@ripe.net. (You cannot reply to this email.) Regards, Denis Walker Business Analyst RIPE NCC Database Group Referencing MNTNER objects in the RIPE Database: maint-rgnet
So because of phishing, nobody should send messages with URLs in them? On Fri, Feb 10, 2012 at 8:56 AM, Steven Bellovin <smb@cs.columbia.edu> wrote:
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?
-------
From: RIPE_DBannounce@ripe.net Subject: Advisory notice on passwords in the RIPE Database Date: February 9, 2012 1:16:15 PM EST To: XXXXXXXX
[Apologies for duplicate e-mails]
Dear Colleagues,
We are contacting you with some advice on the passwords used in the RIPE Database. There is no immediate concern and this notice is only advisory. At the request of the RIPE community, the RIPE NCC recently deployed an MD5 password hash change.
Before this change was implemented, there was a lot of discussion on the Database Working Group mailing list about the vulnerabilities of MD5 passwords with public hashes. The hashes can now only be seen by the user of the MNTNER object. As a precaution, now that the hashes are hidden, we strongly recommend that you change all MD5 passwords used by your MNTNER objects in the RIPE Database at your earliest convenience. When choosing new passwords, make them as strong as possible.
To make it easier for you to change your password(s) we have improved Webupdates. On the modify page there is an extra button after the "auth:" attribute field. Click this button for a pop up window that will encrypt a password and enter it directly into the "auth:" field.
Webupdates: https://apps.db.ripe.net/webupdates/search.html
There is a RIPE Labs article explaining details of the security changes and the new process to modify a MNTNER object in the RIPE Database: https://labs.ripe.net/Members/denis/securing-md5-hashes-in-the-ripe-database
We are sending you this email because this address is referenced in the MNTNER objects in the RIPE Database listed below.
If you have any concerns about your passwords or need further advice please contact our Customer Services team at ripe-dbm@ripe.net. (You cannot reply to this email.)
Regards,
Denis Walker Business Analyst RIPE NCC Database Group
Referencing MNTNER objects in the RIPE Database: maint-rgnet
If they're intended as a path to log in with a typed password, that's correct. Sad, but correct. On Feb 10, 2012, at 12:18 PM, Richard Barnes wrote:
So because of phishing, nobody should send messages with URLs in them?
On Fri, Feb 10, 2012 at 8:56 AM, Steven Bellovin <smb@cs.columbia.edu> wrote:
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?
-------
From: RIPE_DBannounce@ripe.net Subject: Advisory notice on passwords in the RIPE Database Date: February 9, 2012 1:16:15 PM EST To: XXXXXXXX
[Apologies for duplicate e-mails]
Dear Colleagues,
We are contacting you with some advice on the passwords used in the RIPE Database. There is no immediate concern and this notice is only advisory. At the request of the RIPE community, the RIPE NCC recently deployed an MD5 password hash change.
Before this change was implemented, there was a lot of discussion on the Database Working Group mailing list about the vulnerabilities of MD5 passwords with public hashes. The hashes can now only be seen by the user of the MNTNER object. As a precaution, now that the hashes are hidden, we strongly recommend that you change all MD5 passwords used by your MNTNER objects in the RIPE Database at your earliest convenience. When choosing new passwords, make them as strong as possible.
To make it easier for you to change your password(s) we have improved Webupdates. On the modify page there is an extra button after the "auth:" attribute field. Click this button for a pop up window that will encrypt a password and enter it directly into the "auth:" field.
Webupdates: https://apps.db.ripe.net/webupdates/search.html
There is a RIPE Labs article explaining details of the security changes and the new process to modify a MNTNER object in the RIPE Database: https://labs.ripe.net/Members/denis/securing-md5-hashes-in-the-ripe-database
We are sending you this email because this address is referenced in the MNTNER objects in the RIPE Database listed below.
If you have any concerns about your passwords or need further advice please contact our Customer Services team at ripe-dbm@ripe.net. (You cannot reply to this email.)
Regards,
Denis Walker Business Analyst RIPE NCC Database Group
Referencing MNTNER objects in the RIPE Database: maint-rgnet
--Steve Bellovin, https://www.cs.columbia.edu/~smb
On Fri, Feb 10, 2012 at 12:28:22PM -0500, Steven Bellovin wrote:
If they're intended as a path to log in with a typed password, that's correct. Sad, but correct.
I agree. Training your customers/clients to click on URLs in email messages is precisely equivalent to training them to be phish victims. I teach people to (carefully!) bookmark the sites that they use which require passwords, and to always use those bookmarks -- that is, *never* to use the links in any mail message or on any web page. (Of course, an attacker in control of their browser could manipulate the bookmarks, but there is little reason for an attacker who's already gotten that far to do so.) ---rsk
On Feb 10, 2012, at 9:29 AM, Randy Bush wrote:
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.
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
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 -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
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. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
On 2012-02-10 18:37 , Leo Bicknell wrote: [..]
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
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 Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
On Feb 10, 12:01 pm, Leo Bicknell <bickn...@ufp.org> wrote:
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.
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.
In a message written on Fri, Feb 10, 2012 at 11:11:18AM -0800, Ryan Malayter wrote:
Windows has had its own centralized certificate store and APIs since NT 4.0's release in 1996.
You are correct that I maligned Windows in a way I shouldn't have done. Indeed, I've been very impressed with the software they make to manage certificates in the enterprise before, making it quite easy to roll out per user certificates for VPN's or E-Mail and dump it in the certificate store. I think my view was incorrectly colored by the fact that the API is not used by many programs (open source in particular) where as OSX has had some traction with the Keychain. It would be nice to get something approximating a cross platform API, even if all that means is the ability to do the same operations on all major platforms. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
On Fri, Feb 10, 2012 at 1:01 PM, Leo Bicknell <bicknell@ufp.org> wrote:
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.
The problem space is that most folks won't catch the difference between an email and link from ripe.net, ripe.org and ripe.ca. The game is lost long before a purely technical version of validating the message source becomes an issue. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
In a message written on Fri, Feb 10, 2012 at 04:15:19PM -0500, William Herrin wrote:
The problem space is that most folks won't catch the difference between an email and link from ripe.net, ripe.org and ripe.ca. The game is lost long before a purely technical version of validating the message source becomes an issue.
You're reply is along the lines of what several other folks have told me privately, and I think they all miss the mark of where I am going with my suggestion. Hypothetically, I get an e-mail from ripe.ca, which uses some trick (perhaps as simple as HTML text and link that go to different places) to visually show me ripe.net and actually sends me to ripe.org. Let's also assume I have a ripe.net account and have been to that web site before. The software can do a pile of things that make life better for the user: 1) When I reach ripe.org (from the phish above), my browser can say: "This is an SSL web site asking for a login and password, and yet, you've never been here before. Maybe you would prefer to register, or leave if you came here incorrectly." That's all client side UI, and would make even novice users stop and think about what happened. 2) Let's say the e-mail was signed, by ripe.ca, the original sender. When my e-mail client passes the URL to my browser, it can also pass the details of the ripe.ca key. My browser can then say "You got an e-mail from Key ABC, but went to a web site run by XYZ, are you sure this is what you want to do?" Of course if everything matches, it can be silent. Specifically I am NOT suggesting to ever trust a root-CA, or the details in a certificate. Indeed, browsers could ship with no certificates what so ever in my scheme. The key is comparing multiple sources of information. Most folks might not know the difference between ripe.ca and ripe.net. The existing CA scheme may allow both of them to get the common name "Réseaux IP Européens", confusing even the technical who look close. But it's trivial for the software to say Cert in E-mail != Cert in Web, or even that they don't have a common branch in the tree (in a large org they may have the same parent, for instance). As I've also said, a good UI feature would be the ability to add a description to a cert locally. Once I'm sure my banks web site is legit I should be able to add "Leo's Bank" in the cert store locally. Now when my web browser or e-mail client use that cert to validate a message they can display "Leo's Bank" next to it. I can easily look for that and know I went back to the same place. I click on a link in my e-mail and see no description, I know something went wrong. Does my scheme stop all phishing. Heck no. If we wait for a perfect solution we'll never have any solution. Look at NANOG. Bandy Rush is here somewhere. It's why many years ago I set my mailer to PGP all e-mail to NANOG. See an e-mail from me not signed, don't trust it. Does that stop all impersonation on NANOG. Heck no, but if we all did it, and subscribed to the web of trust, it would all but stop it. Users hate encryption and ignore the warnings not because they don't want to be secure, or are idiots. They do it because the darn software is broken, confusing, and has the worst UI's ever invented. If the industry fixes it, encryption will be much more widespread. Small steps, like banks allowing users to upload an cert to their account profile, and then communicate via two-way authenticated e-mail would go a long way to traning the user community how this should work. End user ISP's (cable, DSL) issuing e-mail certs automatically and installing them as part of their install package would be a quantum leap forward. It's not hard, people just don't do it. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
In article <20120210213755.GA88812@ussenterprise.ufp.org>, Leo Bicknell <bicknell@ufp.org> writes
Hypothetically, I get an e-mail from ripe.ca
Or from ripen.cc which is one of their actual domains (used briefly as a url shortener). -- Roland Perry
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
On Fri, 10 Feb 2012 09:37:01 PST, Leo Bicknell said:
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?
Obi-Wan Kenobi: "(shocked) How could this have happened?? We're supposed to be smarter than this." Anakin Skywalker: "Apparently not."
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 On 2/10/2012 11:51 AM, Valdis.Kletnieks@vt.edu wrote:
On Fri, 10 Feb 2012 09:37:01 PST, Leo Bicknell said:
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? Obi-Wan Kenobi: "(shocked) How could this have happened?? We're supposed to be smarter than this." Anakin Skywalker: "Apparently not."
On Feb 10, 2012, at 12:37 01PM, Leo Bicknell wrote:
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.
The really hard parts are (a) getting the users to pay attention to the validation state (or, more precisely, the lack thereof on a phishing email, and (b) get them to do it *correctly*. Some of the browser password managers have protection against phishing as a very useful side-effect: if they don't recognize the URL, they won't pony up the correct login and password. That's much better than hoping that someone notices the absence of a little icon that means "this was signed". The "correctly" part has to do with the PKI mess. --Steve Bellovin, https://www.cs.columbia.edu/~smb
On Fri, Feb 10, 2012 at 09:37:01AM -0800, Leo Bicknell wrote:
Remind me again why we live in this sad word Randy (correcly) described?
Because banks and many other institutions have prioritized all-singing, all-dancing, bloated, horribly-badly-marked-up HTML email with "stationary" and logos and pictures and web bugs far, FAR ahead of security, privacy, accessability, portability and other -ilities that I'm too lazy to enumerate just now. Besides: it's not like it's *their* accounts that will get hosed or *their* money that will get lost. Things like that only happen to the little people. See also this related note: http://www.mail-archive.com/infowarrior%40attrition.org/msg08436.html ---rsk
There used to be the old programming benchmark of how large a "program" (in lines, as well as compiled bytes) it took to say "Hello, world." The 21st century benchmark might now well be the size of a "Hello, world" e-mail. Or a web page with a similar statement. Jeff On 2/10/2012 6:46 PM, Rich Kulawiec wrote:
On Fri, Feb 10, 2012 at 09:37:01AM -0800, Leo Bicknell wrote:
Remind me again why we live in this sad word Randy (correcly) described? Because banks and many other institutions have prioritized all-singing, all-dancing, bloated, horribly-badly-marked-up HTML email with "stationary" and logos and pictures and web bugs far, FAR ahead of security, privacy, accessability, portability and other -ilities that I'm too lazy to enumerate just now. Besides: it's not like it's *their* accounts that will get hosed or *their* money that will get lost. Things like that only happen to the little people.
See also this related note:
http://www.mail-archive.com/infowarrior%40attrition.org/msg08436.html
---rsk
On Feb 10, 2012, at 12:29 30PM, Randy Bush wrote:
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.
Yup -- I wrote about that a while back (https://www.cs.columbia.edu/~smb/blog/2011-10/2011-10-02.html)
waaaay to much phishing, and it is getting subtle and good.
What's the line -- "I know I'm paranoid, but am I paranoid enough?" --Steve Bellovin, https://www.cs.columbia.edu/~smb
----- Original Message -----
From: "Steven Bellovin" <smb@cs.columbia.edu>
What's the line -- "I know I'm paranoid, but am I paranoid enough?"
"Just because people say you're paranoid, that doesn't mean that there *aren't* people out to get you." Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
On Fri, Feb 10, 2012 at 09:29:30AM -0800, Randy Bush wrote:
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.
Web site? With the RIPE db one communicates using PGP email for data in and port 43 queries for data out. The web site is for signing up to RIPE meetings. Yes, RIPE NCC, I think that you put a lot of resources into new fancy guish junk, and tend to forget how things should be done, and some things -- the horror! -- are only possible to accomplish using the web site and some forgotten password. To me, that is much more annoying than the side projects that people are griping over. </rant>
waaaay to much phishing, and it is getting subtle and good.
Indeed. -- Måns
On Fri, Feb 10, 2012 at 12:18 PM, Richard Barnes <richard.barnes@gmail.com> wrote:
On Fri, Feb 10, 2012 at 8:56 AM, Steven Bellovin <smb@cs.columbia.edu> wrote:
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? [...] attribute field. Click this button for a pop up window that will encrypt a password and enter it directly into the "auth:" field.
So because of phishing, nobody should send messages with URLs in them?
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 -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
----- Original Message -----
From: "William Herrin" <bill@herrin.us>
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.
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 -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
On Fri, Feb 10, 2012 at 1:00 PM, Jay Ashworth <jra@baylink.com> wrote:
From: "William Herrin" <bill@herrin.us> 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.
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...
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 -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
---- Original Message -----
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 -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
On 10/02/12 10:00 AM, Jay Ashworth wrote:
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.
Freakonomics recently aired a story about the problem of getting Doctors to follow hand hygiene rules and wash their hands as frequently as they are supposed to (upon entering and leaving each patient's room) to avoid spreading disease. One of the biggest problems with changing behavior with doctors (and with technical people) is that the smarter people are, the more they chafe at being told they aren't doing things the correct way. The most effective step they took to counter-act the hand-washing problems was using a screen-saver on all the public terminals, showing the consequences of not-washing - an image of a petri dish showing the bacteria results from a hand-print of a doctor's hand. http://www.freakonomics.com/2012/01/24/how-to-get-doctors-to-wash-their-hand... If you wanted to have a similar effect at $workplace, try a similar visual (e.g. a mockup of 2 screenshots, first clicking on a link in email then typing in a password on a webpage with a phishing URL (with a typo)) as the screen saver on all company computers; as the first slide in all in-house ppt presentations; on the wall at all card-lock entry doors, etc. jc
----- Original Message -----
From: "JC Dill" <jcdill.lists@gmail.com>
If you wanted to have a similar effect at $workplace, try a similar visual (e.g. a mockup of 2 screenshots, first clicking on a link in email then typing in a password on a webpage with a phishing URL (with a typo)) as the screen saver on all company computers; as the first slide in all in-house ppt presentations; on the wall at all card-lock entry doors, etc.
The problem is you need the 3rd visual... a picture of an abandoned factory, with the doors flapping in the wind, bceause the company went out of business because someone got spearphished. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
On Fri, 10 Feb 2012 14:44:29 EST, Jay Ashworth said:
a picture of an abandoned factory, with the doors flapping in the wind, bceause the company went out of business because someone got spearphished.
Has this ever been spotted in the wild? Serious question - most of the well-publicized spearphishing attacks lately the victim company is still around.
----- Original Message -----
From: "Valdis Kletnieks" <Valdis.Kletnieks@vt.edu>
On Fri, 10 Feb 2012 14:44:29 EST, Jay Ashworth said:
a picture of an abandoned factory, with the doors flapping in the wind, bceause the company went out of business because someone got spearphished.
Has this ever been spotted in the wild? Serious question - most of the well-publicized spearphishing attacks lately the victim company is still around.
I don't know that we would have any way to know that a demised company went down due to a spearphish... but yes, I was exaggerating. Cheers, -- jr 'hyperbole and a half!' a -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
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. On 02/10/12 09:18 -0800, Richard Barnes wrote:
So because of phishing, nobody should send messages with URLs in them?
On Fri, Feb 10, 2012 at 8:56 AM, Steven Bellovin <smb@cs.columbia.edu> wrote:
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?
-------
From: RIPE_DBannounce@ripe.net Subject: Advisory notice on passwords in the RIPE Database Date: February 9, 2012 1:16:15 PM EST To: XXXXXXXX
[Apologies for duplicate e-mails]
Dear Colleagues,
We are contacting you with some advice on the passwords used in the RIPE Database. There is no immediate concern and this notice is only advisory. At the request of the RIPE community, the RIPE NCC recently deployed an MD5 password hash change.
Before this change was implemented, there was a lot of discussion on the Database Working Group mailing list about the vulnerabilities of MD5 passwords with public hashes. The hashes can now only be seen by the user of the MNTNER object. As a precaution, now that the hashes are hidden, we strongly recommend that you change all MD5 passwords used by your MNTNER objects in the RIPE Database at your earliest convenience. When choosing new passwords, make them as strong as possible.
To make it easier for you to change your password(s) we have improved Webupdates. On the modify page there is an extra button after the "auth:" attribute field. Click this button for a pop up window that will encrypt a password and enter it directly into the "auth:" field.
Webupdates: https://apps.db.ripe.net/webupdates/search.html
There is a RIPE Labs article explaining details of the security changes and the new process to modify a MNTNER object in the RIPE Database: https://labs.ripe.net/Members/denis/securing-md5-hashes-in-the-ripe-database
We are sending you this email because this address is referenced in the MNTNER objects in the RIPE Database listed below.
If you have any concerns about your passwords or need further advice please contact our Customer Services team at ripe-dbm@ripe.net. (You cannot reply to this email.)
Regards,
Denis Walker Business Analyst RIPE NCC Database Group
Referencing MNTNER objects in the RIPE Database: maint-rgnet
-- Dan White BTC Broadband Ph 918.366.0248 (direct) main: (918)366-8000 Fax 918.366.6610 email: dwhite@olp.net http://www.btcbroadband.com
On Fri, Feb 10, 2012 at 10:56 AM, Steven Bellovin <smb@cs.columbia.edu> wrote: You know, clickable objects in automated business communications are a standard practice, the larger the organization sending the message, the more complicated and annoying their standard e-mail template full of HTML eyecandy, the more clickable links to improve accessibility, and banks among the worst offenders. Those encourage phishing, because HTML just provides way too many methods of faking a URL, or making a 'button' or 'link' go to somewhere else besides what is suggested by the e-mail text. All an e-mail user needs to do is click on one unknown link, to be quietly diverted to a fake website, that will then ask the user to "change" a password; it makes no difference whether the e-mail itself is about passwords or a security issue or not. Convincing the user to "log in" can be done while they are visiting the fake website. There are plenty of phishers that rely on convincing users to hit the 'reply' button and divulge sensitive info, with no clickable items in the message at all. But this particular item from RIPE here appears to be a plain text message... text/plain The message from RIPE is darn benign, and does not really encourage phishing moreso. When was the last time you saw a phishing attempt in a text/plain e-mail showing the name of a HTTPS location on the real organization's web site ? If sending out a web address "encourages phishers", then what are they supposed to provide to make sure maintainer users can easily and quickly change their password? RIPEs not encouraging phishing by sending such a message. MUA developers who included text/html MIME type support and support creating clickable objects in a HTML message have encouraged convincing phishing very much so. What RIPE did there is a perfectly example of what should be done. Send plain text e-mail with the URL location to review, no HTML doodads. They have no control of your e-mail client that for some reason perhaps turns a plaintext URL into something you can click.
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?
-- -JH
participants (18)
-
-Hammer- -
Corey Quinn -
Dan White -
Jay Ashworth -
JC Dill -
Jeff Kell -
Jeroen Massar -
Jimmy Hess -
Leo Bicknell -
Måns Nilsson -
Randy Bush -
Rich Kulawiec -
Richard Barnes -
Roland Perry -
Ryan Malayter -
Steven Bellovin -
Valdis.Kletnieks＠vt.edu -
William Herrin