[SLL] sharing superuser account is always bad policy, right?

[Rob Smith]

Erm, they mention that they are stored encrypted in their database, so
it's not stored in plain text. Calling it a "ultra-secure Microsoft
SQL Server database" is you just spreading FUD for no legitimate
reason.

Second, storing a hash to allow others to gain access is a bit... worthless.

Third, not all server maintenance can be done online, say if the
network gives up the ghost, being able to log in and troubleshoot is
fairly important...

Fourth, your little experiment doesn't seem to have any bearing on
this conversation.

On Fri, Feb 6, 2009 at 11:55 AM, Derek Simkowiak <dereks at realloc.net> wrote:
>   Phil,
>   Their mea culpa notwithstanding, they still store customer passwords in
> plaintext, which is (in my opinion) enough reason to drop them.  They should
> store an MD5 or SHA hash, and that's it.
>
>   If somebody cracks their ultra-secure Microsoft SQL Server database that
> holds all their customer passwords, your root password will be compromised
> (along with everyone else's).
>
>   The fact that they use passwords to do root maintenance -- instead of SSH
> keys -- is a major red flag.  What if their employee Joe The Administrator
> gets fired?  Will he take retribution on your server (since he happened to
> know your root password from working on it before)?  Will they ask you to
> reset your root password anytime an employee gets fired?  If they were using
> SSH keys, they could just delete Joe's public key from
> /root/.ssh/authorized_keys and not have to worry about it.
>
>    Here's a little experiment: set up a box with SSH listening on port 22,
> and make it accessible from the Internet.  Within a few hours (usually a few
> minutes) you'll start seeing dictionary password attacks in your log file.
>  Those dictionary attacks will trickle in ad infinitum.  (A group of
> developers in Germany told me they see the same thing over there, too.)
>
>
> --Derek