7 Jul
2012
7 Jul
'12
7:25 p.m.
On 7/7/2012 4:05 μμ, Andy Smith wrote:
Hello,
Today a customer popped up on IRC saying that they had broken their
VPS and couldn't remember their account details in order to use the
console / rescue VM.
Unfortunately they had also at some point in the past disabled
email password reset, so they were unable to regain access.
I believe that
disabling password reset should only be available if
another method of authentication is configured. A means of identifying
oneself should always be active.
I would consider the method you used insecure and prone to social
engineering attacks. Anyone can forge any document sent over email or
fax, including a utility bill. Proof of address is not enough to verify
identity, in my book.
If you have disabled email password reset, are you
comfortable with
this being circumvented by someone who is able to present a
convincing image of a utility bill to support(a)bitfolk.com?
I am not comfortable
with that. Many people know my address, so this is
insecure.
Perhaps you can offer some guidelines for how this
should be dealt
with in future so that there can be a consistent response.
Suggestions revolving around the customer identifying themselves
using public key crypto (PGP keys, SSH keys) are fine but do bear in
mind that most customers have not presented either a PGP nor SSH key
to me, and that would have to be done before it was actually needed.
I could require that an SSH and/or PGP key be uploaded to the panel
before the panel allows you to disable email password resets, though
there would still need to be a plan in place for the inevitable case
where the customer claims to no longer have access to any of the
keys they have uploaded.
I would not only accept but in fact appreciate you more if
you
implemented SSH/PGP uploading as a requirement.
SSH keys could be automatically taken from root account in server if
they exist - if root account is compromised and hacker put ssh keys
there, there's nothing to lose.. it's already rooted.
Brainstorm:
1. Make a 1 GBP charge to the customer's bank account (if known) with a
code, then request the code (a la paypal): requires you to know bank
account, is SLOW to work
2. Demand mobile phone, send verification code via SMS that must be
input to disable email auth, from then on, demand sms code - insecure,
might need an extra verification method
3. Use voice recognition - customer calls you, you use voice recognition
software - might need an extra verification method
4. Use the "memorable phrase" method (a la msn live)
5. Mail the customer a password - might need an extra verification
method - impractical, easily intercepted
6. Use lawyers (a la CACert verification) - very slow, costly, impractical
7. Trust buddy - A customer designates another customer as a "trusted
buddy", where they can access the VPS using their own credentials. This
could be allowed only during emergency situations or more generally -
not practical since I imagine most customers don't have buddies in
bitfolk customer base
8. OAuth - Use external authentication (yahoo, etc). Customers links
account, can then log on via those accounts in future ONLY to change
password. Forgetting both credentials would be rather rare....
Also, you should not reveal an active alternative authentication method
in a customer's account to alleged customer, as extra layer of security.
The customer should offer the authentication keys without social
engineering you.
--G