![](/style/images/good.png)
![](/style/images/bad.png)
Exploiting humans during phone authentication
source link: http://rachelbythebay.com/w/2012/07/15/auth/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Exploiting humans during phone authentication
I'm a fan of interfaces which are designed to be useful to users while also collecting good signals for later analysis at the same time. Sometimes this can be helpful from a security perspective. Here's what I mean.
There was this customer who was being "attacked" in the social engineering sense. Someone was trying to get into their account by calling the support line and going through a whole bunch of trickery. They seemed to be playing "phone monkey roulette", where you keep trying back at different times to see if you can find the weak link.
If they had succeeded, they could have gotten some dumb tech to cough up the root password, or even worse, change it to a new value to lock out the real customer. After that, it's game over. Anything on that entire config is considered compromised.
When I heard about this, my initial idea was to change the way we went about verifying customers. At that point, someone would call in, and we'd get their account number, then we'd pull up their account. They'd say who they were, and we'd click on that contact, and it would give the secret question and answer. We'd ask the question, and if they gave the answer, then they were considered authenticated and had access to things.
The problem is that the act of pulling up an account for phone authentication purposes was indistinguishable from pulling up an account for some other reason, like looking for an older ticket or any other need. This meant you couldn't tell when an account had a higher-than-usual quantity of phone authentication events.
Also, there was no way to track authentication failures. If someone called in and failed to provide the necessary info, there was no good way to convey this to others. If the attackers spread out their attacks sufficiently on a night when things were pretty busy, the people working support might not even realize they were collectively being gamed.
My idea was to create a new path through the customer information system which was to only be used for validating phone calls. It would be limited in what it did so you would not load it up for any other reason. It was relatively simple.
First, there would be a form where you plug in the account number. As soon as you submitted that form, it would be noted as an authentication attempt against that account as a whole. The next page would have a list of contacts, and you would have to pick one, and that would be noted as an auth attempt against that specific contact. Finally, the third page would have the secret question and answer page, and you would be required to answer whether they got it right or not. Only then would it allow you to proceed to the rest of their information to do actual support work.
Once this was in place, certain things would become possible. First of all, you could see accounts which were receiving a bunch of attempts which didn't work just by noticing how many times it showed up at step #1 but didn't get an approval by step #3. The data collected for individual contacts in step #2 could also be useful if there was one in particular which was being brute forced.
I presented this to people who supposedly had some sway in these matters. Nothing happened. At the time, I found it surprising. I don't think it would surprise me any more.
August 8, 2012: This post has an update.
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK