5 ms·

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

by de90 16y ago

Not really the answer to the question, but this was the result of social engineering -> http://pastie.org/1535735 http://pastie.org/1535735 So, even if it was secure, in this case it would have happened..

allenp 16y ago
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/Shibboleth http://en.wikipedia.org/wiki/List_of_shibboleths http://en.wikipedia.org/wiki/List_of_shibboleths
- JonnieCache 16y ago
  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.
  - artmageddon 16y ago
    That's mostly security by obscurity, in which you're bound to get burned.
    - JonnieCache 16y ago
      Could you elaborate?
      - jrockway 16y ago
        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.
        JonnieCache 16y ago
        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 :)
    - deno 16y ago
      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.
- bhousel 16y ago
  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.
  - JonnieCache 16y ago
    >'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 http://news.ycombinator.com/item?id=2067063
    - bhousel 16y ago
      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.
      - JonnieCache 16y ago
        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?

by de90 16y ago

allenp 16y ago

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/Shibboleth http://en.wikipedia.org/wiki/List_of_shibboleths http://en.wikipedia.org/wiki/List_of_shibboleths

JonnieCache 16y ago
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.
- artmageddon 16y ago
  That's mostly security by obscurity, in which you're bound to get burned.
  - JonnieCache 16y ago
    Could you elaborate?
    - jrockway 16y ago
      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.
      - JonnieCache 16y ago
        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 :)
  - deno 16y ago
    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.
bhousel 16y ago
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.
- JonnieCache 16y ago
  >'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 http://news.ycombinator.com/item?id=2067063
  - bhousel 16y ago
    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.
    - JonnieCache 16y ago
      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?