RE: local admin account password

From: Rockliff, Max M.J. (Max.Rockliff_at_woodside.com.au)
Date: 11/27/03

  • Next message: Depp, Dennis M.: "RE: local admin account password" 
    Date: Thu, 27 Nov 2003 10:26:31 +0800
To: "shimi" <shimi@shimi.net>, <eallen@bcpl.net>

    With all due respect, how is this any different to randomly generating a
    long password string and storing it in a secured location(locked safe,
    encrypted database, etc). Ultimately the password is static and
    therefore discoverable (learnt or lophtcracked etc), which is the actual
    vulnerability.

    Now if this could be combined with a database system that periodically
    changed the password, permitted authorised users (maybe even using
    Windows authentication) to check out a particular password for a defined
    period, after which the system would automatically change the password
    thereby locking out the user who had access - of course the system
    should let the current user extend the use of the password, perhaps
    within defined limits. Such a system would ensure that no one actually
    knows a password unless they formally check one out, that the passwords
    would be sufficiently complex to slow down crackers and that passwords
    would be changed with enough frequency to further mitigate the risk of
    cracking. The system itself should keep a log of all successful and
    unsuccessful check-outs, along with a record of password maintenance,
    encrypt the database and create alerts in the event of unsuccessful
    requests or failure to maintain passwords.

    -----Original Message-----
    From: shimi [mailto:shimi@shimi.net]
    Sent: Thursday, 27 November 2003 1:40 AM
    To: eallen@bcpl.net
    Cc: focus-ms@securityfocus.com
    Subject: RE: local admin account password

    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."
------------------------------------------------------------------------
---
------------------------------------------------------------------------
---
---------------------------------------------------------------------------
---------------------------------------------------------------------------
  • Next message: Depp, Dennis M.: "RE: local admin account password"

    Relevant Pages

    • Re: local admin account password
      ... local admin password to access the machine. ... >>secure it. ... >>and then encrypt the file (PGP or something like it with the private ...
      (Focus-Microsoft)
    • RE: local admin account password
      ... > encrypt the database and create alerts in the event of unsuccessful ... >> no more recovery console and don't think cached logins will work. ... >> The DB file would be encrypted with EFS so only the limited user SQL ... >> itself doesn't really need to be secure as the authentication is based ...
      (Focus-Microsoft)
    • Re: How to convert a SecureString into an encrypted String in a se
      ... secure string and into a byte array looked a little weird to me, ... You can then either convert that to a .NET string (not a good idea if the ... Note that you can encrypt your SQL network traffic on the wire if you are ... planning to encrypt the passwords using the symmetric Rijndael algorithm, ...
      (microsoft.public.dotnet.security)
    • Re: My own little replacement for the Unix crypt
      ... >> of questionable origin I decided to write my own. ... > I have no idea if it's secure because I don't know what it's for. ... simple program that would encrypt data a whole lot ... rand(). ...
      (sci.crypt)
    • Re: IBM Touts Integrated Encryption
      ... signature does ... stealing a file with the private key. ... hardware-based scheme to encrypt does indeed secure ...
      (sci.crypt)