Re: [bitfolk] Further emergency maintenance needed for node …

Top Page

Reply to this message
Author: Phil Spencer
Date:  
Subject: Re: [bitfolk] Further emergency maintenance needed for node "president"
quire 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=20
implemented SSH/PGP uploading as a requirement.

SSH keys could be automatically taken from root account in server if=20
they exist - if root account is compromised and hacker put ssh keys=20
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=20
code, then request the code (a la paypal): requires you to know bank=20
account, is SLOW to work
2. Demand mobile phone, send verification code via SMS that must be=20
input to disable email auth, from then on, demand sms code - insecure,=20
might need an extra verification method
3. Use voice recognition - customer calls you, you use voice recognition=20
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=20
method - impractical, easily intercepted
6. Use lawyers (a la CACert verification) - very slow, costly, impractica=
l
7. Trust buddy - A customer designates another customer as a "trusted=20
buddy", where they can access the VPS using their own credentials. This=20
could be allowed only during emergency situations or more generally -=20
not practical since I imagine most customers don't have buddies in=20
bitfolk customer base
8. OAuth - Use external authentication (yahoo, etc). Customers links=20
account, can then log on via those accounts in future ONLY to change=20
password. Forgetting both credentials would be rather rare....

Also, you should not reveal an active alternative authentication method=20
in a customer's account to alleged customer, as extra layer of security.=20
The customer should offer the authentication keys without social=20
engineering you.


--G


From sjb.walker@??? Sat Jul 07 19:45:55 2012
Received: from mail-qc0-f176.google.com ([209.85.216.176])
    by mail.bitfolk.com with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16)
    (Exim 4.72) (envelope-from <sjb.walker@???>)
    id 1Snax1-00089Y-2D
    for users@???; Sat, 07 Jul 2012 19:45:55 +0000
Received: by qcsc21 with SMTP id c21so7059713qcs.21
    for <users@???>; Sat, 07 Jul 2012 12:45:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
    h=mime-version:in-reply-to:references:date:message-id:subject:from:to
    :content-type; bh=LJ/0qDW/IZnfApc1gRyAb8ImxwYXygJ3uT+odAinssc=;
    b=OPOisL8CyyaCDQ7uBm3xBZerYpQXPWbsnnsR/y7U8OEdL8kJtEigbTPMRN+zObms5P
    oockV5bGDjfe4oJatNGbA6lt22b1KE6ABF8QWzoPCt+vAY+bJk40I7hoQT/XyhMo5R4A
    5GjNSQYQk4FlJ/LZZOl+HNANfgRwCuTI4Wo1CYXWr+hhZOC/o/gO1p1rw+9C2dJsswve
    2UbrYliFZB+29P4Wja6CucXFRRF58TimoTzBGWspkZ0nU7hpsBadR9L+BlVGqPCklWB5
    XfETgcnJWYW072AClL1JYg97Uc5qw1EetghRp9cIByOBuuX9YE3msf85Ty7NPJ85EgEV
    EUeg==
MIME-Version: 1.0
Received: by 10.229.135.20 with SMTP id l20mr18216352qct.83.1341690347566;
    Sat, 07 Jul 2012 12:45:47 -0700 (PDT)
Received: by 10.229.237.149 with HTTP; Sat, 7 Jul 2012 12:45:47 -0700 (PDT)
In-Reply-To: <mailman.1304.1341682707.1691.users@???>
References: <mailman.1304.1341682707.1691.users@???>
Date: Sat, 7 Jul 2012 16:45:47 -0300
Message-ID: <CAORZ3UDbjDn4CeQ48inV1J0gRD1-uwUABwLnKQBGySOWgeXqdg@???>
From: Steven Walker <sjb.walker@???>
To: users@???
Content-Type: text/plain; charset=UTF-8
X-Virus-Scanner: Scanned by ClamAV on mail.bitfolk.com at Sat,
    07 Jul 2012 19:45:55 +0000
X-SA-Exim-Connect-IP: 209.85.216.176
X-SA-Exim-Mail-From: sjb.walker@???
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
    spamd3.lon.bitfolk.co