Hacker News Reader

Hacker News

Comment by de90 | Hacker News Reader

Parent Full thread

de90

Not really the answer to the question, but this was the result of social engineering -> http://pastie.org/1535735

So, even if it was secure, in this case it would have happened..

View on HN

I think if they required the use of a shibboleth or key phrase in the email they could have avoided this.

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

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

Or, have an agreement that all password resets will be silently ROT13'd against what is requested.

So if you say "Can you reset my password to foobar" then your admin knows to actually set it to "sbbone."

They can then just send a normal reply saying "ok your password has been set to 'foobar'" and then as long as both parties remember the secret protocol, you are OK.

You could then also watch for login attempts using "foobar" to warn you of foul play.

That's mostly security by obscurity, in which you're bound to get burned.

Could you elaborate?

The security of that system comes from hoping nbobody will guess your key exchange protocol. The security in real key exchange protocols comes from mathematics problems that would take more computer power than the universe has available to solve. So 'your way' is clearly inferior; the attacker guesses (or is told) that ROT13 is what's going on, and you're 0wned and you will never know. Problem.

Yeah this is really obvious now. When I wrote that, I didn't make the mental comparison to PGP or similar; obviously that provides actual cryptography with essentially the same information-exchange workflow.

Nothing educates like brainstorming in public and being shot down by experts, thanks :)

Though it could be effective, assuming attacker WILL try non-translated version first. Basically run honeypot on default password: if successful login attempt then go into panic mode.

But seriously, the only password in SSH auth procedure should be the one you decode your private key with.

But once you have access to a person's email, you could just go back through the history and look for past communications like this and mimic them. That's my guess about how they were able to ask specific questions about the root password.

Some method of verifying the requester's identity out of band (e.g. 'call me for the password') is really the only way to go.

>'call me for the password' is really the only way to go.

Nope.

"From what I hear - yes... My friends who worked for whitehat security companies would first try to hack staff before hacking servers. Best was to call up the ceo on his personal homephone every night at 3am, until they knew what he sounded like raving mad. Then they called up the admins doing a very good impression of the irate ceo demanding his passwords were reset there and then. Worked a stupid amount of times apparently..."

http://news.ycombinator.com/item?id=2067063

You kind of ignored my point about verifying the person's identity while you have them on the phone.

LAST EDIT: Fine. shibboleths, passwords, pins, safeword cards, emails, texts, callerid, voice, and face to face conversations are all great tools to use when trying to secure some asset. All I'm saying is Go out of band when you want to verify a person's identity. If you are emailing, call. If you are on the phone, and you don't trust them, call them back at their home. Or text them a code and ask them for the code. Or meet in a trusted place and take a DNA sample. Whatever is appropriate for the thing you are securing.

Sure, any of these methods can be compromised through social engineering, blackmail, theft, or violence. That's not the point.

If you care about a password, don't send it through the same channel that you use to verify the person that you are sending the password to. Shibboleths and ROT13ing won't solve the problem of knowing who you are talking to.

How would you identify the person on the phone? Their voice clearly isn't enough. Caller ID can be spoofed. With another password? What happens when they forget that as well? I guess you could require a face to face meeting to reset that password. But by having two alternative passwords, you have increased the attack surface. The user is much more likely to write the second "emergency" password down I expect.

Also, what happens when your helpdesk's VoIP system gets hacked in the same way that the email system got hacked in this case?

Only document the full procedure on paper, and forbid people from mentioning the full procedure except in person. If an admin gets an email asking for a password, they should reply with a fake password, and then await a call to give a real password. Or vice versa. If the person contacting them tries repeatedly, they should feign incompetence and / or laziness, escalating if it gets out of hand (even if escalating means passing to another equal-rank admin.)

This is the right idea. A feedback loop is critical to hacking. If you take away the feedback loop it becomes nearly impossible.

Or just PGP encrypt any emails with root passwords or other details about your system.

Just make sure you decide before the emergency who needs to be trusted with that information, and be smart about how you exchange keys with everyone involved.

>If you are on the phone, and you don't trust them, call them back at their home.

Didn't think of that. Great idea.

We used to do this when managing unreachable firewalls. Dial out to the modem attached to the firewall console and type in that modem's password. The remote modem drops our call, then dials us back with a console login prompt. So even if you had the password, you had to at least be dialing in from our phone line.

old school BBS callback verification!

Reminds me of these tricks: http://www.skepticfiles.org/cowtext/bbs/cbv.htm

A company with truly good security practices would put into place a protocol for transferring passwords over voice comms. I'm making a note right now.

Reply on news.ycombinator.com