RE: local admin account password

• Previous message: Peterson Ellis: "Re: local admin account password"
• In reply to: Michael Marziani: "RE: local admin account password"
• Next in thread: Eli Allen: "Re: local admin account password"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Wed, 26 Nov 2003 19:39:56 +0200 (IST)
To: eallen@bcpl.net

I have an idea.

Find a given word (keep it secret!); Concat it into the machine's name;

Take the concated string and run it through md5(). (http://www.php.net/md5)

Put the result as the admin password.

Next time you need the password, you need to know: Your secret word + The
machine name. (Do note - they WILL BE case sensitive, so make them all
small or all big, or, whatever you want...)

All you need is a webserver and PHP enabled to generate your passwords in
future use... (secret word isn't stored anywhere!)

I have set up a living example at http://shimi.staff.fresh.co.il/md5.php

Here is the source code for that PHP file:

--- CUT HERE ---

<form action="<?=$_SERVER["PHP_SELF"];?>" method="post">
Machine's Name: <input type="text" size="30" name="machine"><br>
Secret passphrase: <input type="password" size="30" name="password"><br>
<input type="submit" value="Generate me my password!">
</form>

<?
if ($_POST) {
  $machine = $_POST["machine"];
  $password = $_POST["password"];
  echo "For administrative access to machine $machine, use the password: ".md5($machine.$password);
}
?>

--- CUT HERE ---

> -----Original Message-----
> From: Eli Allen [mailto:eallen@bcpl.net]
> Sent: Tuesday, November 25, 2003 12:47 PM
> To: focus-ms@securityfocus.com
> Subject: local admin account password
>
>
> Say you have more then 1000 systems, how do you handle the local admin
> account password on the machines? (assuming it needs to be available for
> extreme cases to get into the machine as you'd normally just use a domain
> login)
>
> A few ways I can think of (in order from what I think is worst to best):
> 1) use the same password on all boxes. Obviously insecure
>
> 2) Use a different password on all boxes and a big filling cabinet to secure
> it (as its impossible to memorize). Don't think this would work in the real
> world so not worth using.
>
> 3) Use a password scheme where the password is basically the same on all box
> except its based on something specific about the server. This means if
> someone figures out the scheme (cracking a single box and figuring it out or
> just gets told) they basically made this as good as the first idea I list.
>
> 4) Only use domain accounts so delete the local ones. But this means no
> more recovery console and don't think cached logins will work. With so many
> boxes and hence lots of admins you may not have logged onto the box and so
> not have cached login in the cache even if you increased the logins that can
> be cached.
>
> 5)My main idea/plan is to store all the passwords on a central SQL server.
> This way you can easily have a different random passwords for the admin
> accounts on all the boxes.
>
> The DB file would be encrypted with EFS so only the limited user SQL runs
> under has access to the file and another user just used for doing backups of
> this file. This means an attacker can't use an OS break-in to get to the
> data and needs to compromise SQL or one of those two user accounts. SQL
> would be set to integrated auth and only allow the domain groups who are
> allowed access to the admin password in. (i.e. using the access rights
> already existing)
>
> For data recovery (this DB is very important not to lose) there are two main
> considerations, one the file is small as the DB has very little info in it
> and two it doesn't get updated very often. The backup user can make a zip
> backup of the DB whenever it gets changed and then encrypt the file (PGP or
> something like it with the private key stored on a/multiple CD-R(s)
> somewhere safe) Then this file could be copied to lots of employee's
> desktops. Its encrypted so they can't read it and with lots of people
> having the file the likelihood of everyone's copy being damaged from HDD
> failure is low. (Yes will use tape backup of the file too including off site
> storage but tape is slow and should only be used if necessary) If there is
> an emergency the managers could easily allow the file to be decrypted and
> then attached to any SQL server available relatively quickly.
>
> Access to this file can be made by any utility that can make use of stored
> procedures. There would be basically two stored procs, one to get a
> password from the DB and one to set the password in the DB both would have 3
> values (machine name, username, and password) passed in and out (obviously
> depending on which you use). This way if a person decides to try and dump
> the DB and get all the passwords the stored proc can do something about it
> (alert management, stop it from happening, or something like that) This way
> its easy to write whatever interface you want to be able to do access the DB
> and the app itself doesn't really need to be secure as the authentication is
> based on the user that app is run by.
>
> Yes I realize it has a central point of attack at the DB but I think that
> can be secured well enough and the design is secure that its still better
> then the other methods.
>
> Any comments? Thanks
>
> Eli Allen
> eallen@bcpl.net
>
>
> ---------------------------------------------------------------------------
> ---------------------------------------------------------------------------
>
>
>
> ---------------------------------------------------------------------------
> ---------------------------------------------------------------------------
>

-- 
  Best regards,
     Shimi
----
   "Outlook is a massive flaming horrid blatant security violation, which
    also happens to be a mail reader."
   -=The best way to accelerate a Windows machine is at 9.81 m/s^2=-
   "Windows is a 32-bit port of a 16-bit GUI for an 8-bit OS on a 4-bit
      CPU made by a 2-bit company that can't stand 1 bit of competition."
---------------------------------------------------------------------------
---------------------------------------------------------------------------

• Previous message: Peterson Ellis: "Re: local admin account password"
• In reply to: Michael Marziani: "RE: local admin account password"
• Next in thread: Eli Allen: "Re: local admin account password"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]