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

[Derek Simkowiak]

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


    Sorry, the bearing was: "Passwords are the primary attack vector for 
a newly-deployed Linux system.  They are weak; don't use them.  Use keys 
instead."

Rob> Third, not all server maintenance can be done online, [...]


    Agreed, but even in the case of a busted network card, using a 
shared "root" account is the wrong thing to do (because there is no 
accountability).

    Ubuntu doesn't even have a root password, regardless of whether or 
not you have a network card.

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


    That's exactly the point... use a hash, because allowing others to 
gain access to your password is just plain wrong.

    There's a reason mailing lists, forums, wikis, etc. all give you a 
"Reset my password" button instead of a "Retrieve my password" button.  
Storing retrievable passwords is always wrong.

Rob> ...you just spreading FUD for no legitimate reason.


    Jeez Rob... can't a guy express a little bit of sarcasm about MS's 
security record on a Linux list?  Bruce Schneier does it all the time  :) 


--Derek

On 02/08/2009 06:45 PM, Rob Smith wrote:
> 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
>>