Slicehost Forum - Account Security

Account Security

Shpigford — Wed, 21 May 2008 06:08:28 +0000

I'm curious, is there anything that could be put in place to make the SliceManager more secure?

I've read article after article about making my Ubuntu installation secure, but the SliceManager seems extremely vulnerable.

All someone has to do is get one password (the password to your SliceManager) and they then have access to basically just delete your entire slice...correct?

I bring this up because I had this very thing happen to me at a former dedicate server host of mine. A hacker was able to get my password to the admin area that managed all my servers and then he proceeded to reformat the servers.

If there were some way to make certain actions more secure or require an extra level of verification, that would be really nice.

Account Security

artagesw — Wed, 21 May 2008 06:52:11 +0000

I’ve often wondered about this as well. I go to great lengths to secure my servers, but I have no insight into the security of SliceManager which, in addition to offering the ability to wipe and reinstall slices, also offers console access to the slices. I’ve always found this to be a bit on the scary side. And even if I have a really strong password, there’s the possibility that a vulnerability in the SliceManager code could allow a cracker who breaks into another customer’s account (due to a weak password) to gain access from there to my account.

Has the SliceManager code has been through any sort of external security audit? That would be one step you could take to help ease the customer’s mind.

Account Security

TJ — Wed, 21 May 2008 07:50:01 +0000

I would really like it that no one be able to close an account or even reformat a slice without confirming they have access to the account email.
Or for a setting allowing only logins from specific IPs (which are confirmed via email) to execute such. I know it adds some stress to SliceHost and could probably result in more support requests than you'd like to deal with but I'm sure it would make everybody feel a lot safer.

Account Security

rbuecker — Wed, 21 May 2008 13:34:16 +0000

Yep, I agree. I remember at one point asking to make OpenID login a requirement instead of just user/pass also being allowed. With Verisign's PIP you can add your paypal security key ($5) in order to be authenticated with openid that way. If there was a way to require the security key to delete a slice, that would be great- although my search on the topic of providing the token code + serial number to get a true/false back has come up with nothing.

I'd really like an option at least of being able to set a slice in the slicemanager as "call confirmation for delete". So that way my critical slices require a phone call to me in order to actually delete. But I don't set that flag for my toy slices that I'm just mucking around with for ideas and such.

Account Security

jason — Wed, 21 May 2008 16:23:26 +0000

Your requests are noted. We are definitely open for suggestions on this topic. We are formulating some ideas to potentially cover the concern areas, I’ll add to this thread when its fleshed out enough for discussion.

Account Security

mlee — Wed, 21 May 2008 16:32:56 +0000

I think having an optional "lock account without phone or SMS confirmation" is a great idea. Once everything is up and running, most of us rarely ever visit the slicemanager, and would only need to blowup and reimage the slice under extremely rare conditions. This is an account add-on that I'd be willing to pay an extra dollar or two a month to have in place, similar to how the backup option works.

Locking the account to a single IP is less preferable to me, since I'm a road warrior and am frequently logging on from new IP locations.

Account Security

Shpigford — Wed, 21 May 2008 16:59:04 +0000

I personally like the Verisign PIP suggestion that requires a security key, but I understand that's not something easily implemented or scaled easily.

Really even just having security/verification questions for certain tasks would be a step in the right direction.

Examples:
* Verify your full credit card number on file to complete this task
* What are the last 4 digits of your drivers license (a question set on account creation...any question could be asked this way)

You could also maybe require email confirmation from two email addresses. When I had my problem before with the other host, the hacker had gained control of my email account (it was a gmail address) and so he was able to retrieve my password. But if you required 2 email addresses on file (one of which is NOT a free email account) you could send verification links to both addresses which would greatly reduce anyone's ability to perform damaging tasks.

Account Security

timh — Wed, 21 May 2008 17:01:44 +0000

I agree that this is a serious issue.

I like the idea of locking to specific IPs.

You could always allow logins from other IPs, but simply require additional verification, such as the last 4 digits of the billing credit card, an answer to a "secret question", an email verification, etc.

Account Security

lex — Thu, 22 May 2008 04:52:17 +0000

First things first, pick a good password. Make it a passphrase, or a pass-sentence, or even a passnovel. Make it really super-long, and write it down. I know that's something you're not supposed to do, but if you do it, then you can have a super-long unique password. What're the chances some burglar's gonna know what some random sentence on a scrap of paper means?

For authentication, it'd be cool if I could get some other use out of this paypal security key I have, so I'll have to check out openid. I'll also throw a suggestion into the heap: SSL client authentication. Slicehost could set up a self-signed CA, and issue signed client certificates to users upon request. We'd take these keys (usually in .p12 format) and import them into firefox (or opera or ie or whatever). Slicehost's http server would be set up to have client authentication be optional, accepting client certificates signed by their CA. Then their backend scripts can just look at the SSL_ environment variables that the http server sets to see what the CN of the client certificate is. I can explain this better if need be.

This would mean that only someone who had access to the client certicate for an account AND provided the normal username/password could log in, if they turned on an option to require the certificate. I use this kind of authentication for my personal projects on my webserver, and it works great and is simple to use on the client side.

Account Security

ilikepi — Thu, 22 May 2008 11:16:57 +0000

FWIW, the password field in SliceManager is currently limited to 20 characters. I like the SSL client keys idea.

Account Security

jason — Thu, 22 May 2008 16:22:19 +0000

Good suggestions so far guys. Still rolling around some ideas here, the main two driving principles for us

1. As much as possible, all things should be completely automated (including the mechanisms for retrieving forgotten passwords)
2. New features should not add complexity for users that do not want them

There are a couple of easier to implement items that we’ve thought of, most of which could be simple check box options in an account security section of the SliceManager-

a. receive notifications via email of failed and/or successful login attempts to a SliceManager account (including source IP)
b. disable emailing of initial build/rebuild slice password (passwords are still displayed on the web page once after the request is made)
c. disable password based login to the slicemanager (allowing only openid login)

A potentially more sticky thing to implement would be some type of ‘enable mode’ for accounts. This could work similar to how switches/routers have a privileged mode that you need to enter in order to perform potentially destructive tasks. It would take the form of a secondary password/passphrase that needs to be entered after already logged in. We could set it up such that this password is not resettable as simply as the main account login password, perhaps via email to both primary and secondary addresses or verification of some facts about the account.

I do like the ideas brought up about IP login restriction and SSL based authentication, however, I do think the complexity level is a little high for the extra benefit. We definitely want to avoid support tickets over confusion regarding what IP you are trying to log in from and things of that nature. Its troublesome because you can’t exactly display an informational error to the person supplying correct credentials from the wrong IP, that would basically defeat the purpose of the restriction. Also SSL based methods will basically lock you out of your account if you are ever forced to use a different machine. Possibly not a problem for many, but I could see it creating issues for some. In addition the extra steps involved in making that work with your browser may be enough to filter out less savvy customers from being able to (or understanding how to) take advantage of the feature.

I wanted to get some rudimentary thoughts out while the thread was still somewhat alive, this isn’t near as fully thought out as I’d hoped, but please comment on the above ideas. In particular if you do like the ‘enable mode’ feature, I’m open for suggestions on a solid and secure way to reset a forgotten passphrase in an automated way. Keep in mind that billing details like address, last 4 digits of the card, etc are emailed to the account holder on invoices so that isn’t really a good shared secret.

Account Security

lex — Thu, 22 May 2008 16:36:51 +0000

20 characters? Well, that's fairly long, but why limit us? If it's easy to implement, I suggest extending the password field to allow pass-sentences and the like. They can be easier to remember.

Your constraints make sense, and I see how my idea might be neat but might also be confusing. I've thought about it, and I don't know how openid works, but I don't think I want to have to trust that VeriSign or whoever won't abuse their position to break into my account. They might not, but what if someone breaks into their system?

I'd love idea "a". I'd enable that and set it to send the messages to my mobile phone.

Account Security

rbuecker — Thu, 22 May 2008 16:37:20 +0000

to delete a slice, small charges are made to the credit card that have to be entered into slice manager (after checking out the amounts on internet banking). the amounts are credited to the balance of the account :) murder on your merchant costs, i'm sure :P

Account Security

Shpigford — Thu, 22 May 2008 16:45:10 +0000

I still think verifying your full credit card number to perform certain destructive tasks would be a solid way of doing things.

Not sure who your merchant provider is, but I believe Authorize.net provides a service where you can store credit card numbers and reference them if needed...like in the case of needing to verify a credit card for an account.

Account Security

yakumo9275 — Thu, 22 May 2008 18:48:24 +0000

no way shpigford, the last we need is using CC#‘s as verification id. worst idea i have heard in a long time.

What is needed is something like, if you delete a slice, make an automatic 24 or 48hr wait period and require email token challenge/response verification.

ideally an rsa style keytag would be cool but there is a huge expense on the side of slicehost.

it would be easy to use/verify with gpg signatures. slicehost has theirs, and they have our pub key. they encrypt token/phrase/hash in email and we decrypt it.

that can be automaed on their side, and well protected on ours.

Account Security

Shpigford — Thu, 22 May 2008 18:50:41 +0000

no way shpigford, the last we need is using CC#‘s as verification id. worst idea i have heard in a long time.

Why is that? If you’re going to say something is the “worst idea”...at least say why

Account Security

rbuecker — Thu, 22 May 2008 18:51:37 +0000

i still like the idea of tagging slices for callback verification to delete, except then the attacker just has to change the phone number before deleting anything :/

Account Security

jason — Thu, 22 May 2008 19:20:35 +0000

Anything with a lot of back and forth communication seems prone to issues. Full cc number verification is a bad idea in my mind due to the number of people who have trouble simply keeping a good billable card number on file to begin with, coupled with the number of people who have a different billing contact than the technical contact, because in those cases the person taking the action likely doesn’t have access to the card.

Account Security

artagesw — Thu, 22 May 2008 21:46:35 +0000

I think SSL client certificates are a good all-around solution. Are these portable? If so, I could carry my certificate with me on an encrypted USB thumb drive if I ever need to gain access from a different machine. Of course, if it is not my machine, the onus would be on me to uninstall it when I am finished. (This should be optional, so only those who really feel the need for the extra layer of security need deal with certificates.)

Other ideas I like in addition:

1) Don’t email passwords – especially root passwords – ever. I have asked for this before.

2) Receive notifications of login attempts.

And while this is a bit off-topic, I would love to see ssh-based console access with passwordless key-based authentication. The Ajax terminal is great, but nothing beats being able to log in via Terminal. A previous Xen-based VPS host I used (RimuHosting) had this feature and it was great.

Account Security

lex — Thu, 22 May 2008 21:53:18 +0000

You can carry around the .p12 file, although you're going to have to be able to trust any system you use it on. It might be marginally more secure to have a complete firefox install on the keychain, and even more secure to have a complete bootable Linux install (eg puppy linux). The .p12 files are exported with a password like you can do with ssh keys.