Password security

[ferrix]

After going through the server setup process a couple times, I have some concerns about how password security is being handled.


The "welcome" email divulges the Teknic/Billing password in plain text. This is fine for new users, but for existing users it is kind of problematic.

This password is used for a lot of things on unixshell, and I don't care for the idea of having to change it every time I add another server, simply to maintain some level of security.

Also, why is it the case that the "SSH Console" password is limited to 8 characters from the Teknic console? This seems to be an artificial limitation, because my new server was defaulted to use my Teknic password for the SSH console, and that is far longer than 8 characters, and it works just fine. Yet if I go into the Teknic console to change the password (since it was sent over plain text email) then I will be limited to 8 characters again.


Just some suggestions from a security professional. Your service offers a tremendous benefit to security-conscious administrators, since we don't have to worry about security breaches of other users' servers affecting our own (virtual) servers. Stuff like password policies, though, could use some attention!

Thanks for your consideration.

[cmturner2]

I agree, the limitation of alphanumeric characters and a length limitation of eight through the web interface is kind of disappointing (to say the least). I personally use special characters in all of my non-throwaway passwords and was concerned with the limitations on the teknic control panel.

I even seem to remember being able to use more complex passwords when specifying the root password when pushing a new OS image, but that seems to have gone away as well.

[jburnes]

Support Guys (and Gals perhaps),

I've been doing Internet Security for about 10 years now. I know I mentioned this somewhere before, but I've think I need to second the running opinion on this thread.

You've got a great service, but unlike Yahoo groups and other lower security accounts you can't just send people's passwords in the clear over the Internet. The passwords that are being sent are quite possibly the root password to their server and control panel. Bad mojo.

You should put together a simple way to communicate the root passwords to the owners.

Here is a cheap and low overhead idea:

Communicate the password on a separate callback channel.

Don't use the Internet. You really don't know who might be listening either on your net, on the open Internet or on the local network. Here is an idea:

When people sign up they can give you their cell phone number so that an internal script at unixshell can send a text message with their password to their cell phone. Text messaging isn't the most secure thing in the world, but on the other hand its a hell of an improvement over sending it along with the IP address on the open net. Some people might not like their cell numbers known, but they definitely won't like thier root or control panel passwords being known. Nothing like having Joe Random cracker come by and reload your OS for fun or worse. It's just a matter of time until someone *does* try this and then...well...it would be bad.

As to how you send a text message, that depends a little on the carrier, but there are text message companies that send your messages at bulk rates per month. Check them out.

If you need more help I'd be happy to give you some ideas.

BTW: Once you have this root password communicated securely over their cell phone they are free to change it anytime.

Another useful solution would be to have them enter their PGP public key when they sign up. Then you simply encrypt their root password and send it to them. It requires them to setup PGP, but most of us are admins and could do that easily enough. You can also setup GPG for free. I'd be glad to put together a quick refresher on PGP/GPG.

Any other thoughts?

Thanks,

JBurnes
BufferZone Security

[brett]

BTW: Once you have this root password communicated securely over their cell phone they are free to change it anytime.

Why does it matter how it's been communicated? The important part is that they *CAN* change the password. Instead of going through the hassle of implementing new sign-up procedures and requiring personal information from customers, simply encourage users to sign up with a "throw away" password and change it after the initial log in. It probably wouldn't be hard to actually FORCE users to change passwords after the first log in. The other solution seems a bit excessive...

[jburnes]

Letting the user choose an initial password should work fine if they choose to do that. Make sure it's done over an https connection and there should be no worries.

You may wish to tighten security on that a little by forcing a password change on the next login and/or possibly doing some light checks for password quality on even the throw away password.

Anything would be better than emailing them admin passwords.

JB

[matta]

Each sign-up is automatically given a 'throw away' password. We use part of the PHP session id to create a unique password. Only if the user immediately logs into the billing system and changes to their own password will they receive anything but the auto-generated password via e-mail.

[Renata]

At my look everything is fine
Yet, i have other suggestions

* Its good to have TekNic only and Billing only passwords
so 2 passwords instead of 1

* Its will be fine if emails sent by UnixShell# will be separated to
technical and billing related cathegories.
This will need setting 2 emails for contact, one for payment issues
other for technical updates and everything related to technical side.

For example - Me and my friend having a server, he doesnt care about any
technical thing, he just pays and he want everything working.
I dont care about billing, i just make thing work :)

[ferrix]

[QUOTE=matta]Each sign-up is automatically given a 'throw away' password. We use part of the PHP session id to create a unique password. Only if the user immediately logs into the billing system and changes to their own password will they receive anything but the auto-generated password via e-mail.[/QUOTE]

Matta, consider signing up for additonal servers over time. Each time you get a "welcome" email, it clear-texts the "newest" password to you. So each time I add a service I must reset the password because the old one has been "thrown away" again by the email. That's all I meant.

The other items in my initial post are all still valid as far as I can see as well.

[matta]

The change I have decided on it requiring a password (and verfication) on the order form and have the welcome letter state the password is what was requested. It will increase mails sent to sales/support (ie. "I forget what I had entered."), but it seems there is enough demand and we can easily resend login details.