Application security question

Discussion in 'Java' started by Martin Gregorie, Jan 26, 2008.

  1. I need to implement login security for a database system and would
    appreciate some suggestions.

    The database will be hosted on a Linux system, but the graphical query
    and maintenance applications may be run anywhere - Linux, OS-X or
    Windows. The applications access the database directly: there is no
    middle tier server.

    The database doesn't need to be particularly secure. Its intended to
    operate over an office LAN: access over the Internet is extremely
    unlikely. The intention is simply to keep visitors and unauthorized
    staff members from querying or altering it.

    I thought of simply using the database user name and password but this
    seems pretty insecure: these tend to become common knowledge. Ideally
    I'd use something like the standard *NIX login:
    - user is prompted for name and password.
    - password is encrypted.
    - the name and encrypted password are used as keys to query a database
    table.
    - the query returns a row count (0 = login fails, 1 = login OK)

    Name/password maintenance would be handled by a simple application used
    by the admin to create/cancel users and the reset lost passwords to a
    default. The user would set and change their own password and would be
    forced to change the default on first login

    I'd appreciate comments about the security of this scheme, but what I
    really need to know is what standard or 3rd party classes are available
    to implement it. I've looked through the standard classes and Roedy's
    site but all I've found is the JPassportField, which is exactly what I
    need for the GUI.

    I'm currently still on Java 1.4. Some searching hints that the Crypt
    class may be part of Java SE 5. Did I read this right? If so, it looks
    like I'd best upgrade to Java 6 ASAP.

    BTW, I want to avoid solutions involving pam because that could limit
    portability.


    --
    martin@ | Martin Gregorie
    gregorie. | Essex, UK
    org |
     
    Martin Gregorie, Jan 26, 2008
    #1
    1. Advertising

  2. Martin Gregorie <> writes:

    > I need to implement login security for a database system and would
    > appreciate some suggestions.


    So, you want to implement security.
    The first thing to do is to establish the threat model.
    What are you protecting? From what? How bad is it if security is
    compromised?

    > The database will be hosted on a Linux system, but the graphical query
    > and maintenance applications may be run anywhere - Linux, OS-X or
    > Windows. The applications access the database directly: there is no
    > middle tier server.


    > The database doesn't need to be particularly secure. Its intended to
    > operate over an office LAN: access over the Internet is extremely
    > unlikely. The intention is simply to keep visitors and unauthorized
    > staff members from querying or altering it.


    So you are protecting the database from direct querying and altering
    by local, semi-trusted, users.

    The username and password of the database should be kept "secret".
    Users should not need to know them to use the system.

    Obviously, a determined competent user will be able to acquire the
    login credentials for the database from the application.
    You will need a policy forbidding this.

    Alternatively, each user should be created as a user on the
    database, with seperate credentials and capabilities.

    > I thought of simply using the database user name and password but this
    > seems pretty insecure: these tend to become common knowledge.


    Use for what? For login into the application?

    > Ideally I'd use something like the standard *NIX login:
    > - user is prompted for name and password.
    > - password is encrypted.
    > - the name and encrypted password are used as keys to query a database
    > table.
    > - the query returns a row count (0 = login fails, 1 = login OK)


    Why encrypt the password?

    It sounds like you expect all users to login using the application,
    but they can just as easily do queries and alterations directly
    against the database using a standard database tool.

    The reason passwords are encrypted in traditional Unix password files
    is to avoid having them available in plaintext to other users.
    That's a good reason, maybe also in your case, but if the client
    encodes the password, not the server that checks it, then the
    real password just becomes the encrypted string. I.e., you have
    no advantage from encryption, except from people restricted to
    using your application.

    > Name/password maintenance would be handled by a simple application
    > used by the admin to create/cancel users and the reset lost passwords
    > to a default. The user would set and change their own password and
    > would be forced to change the default on first login


    > I'd appreciate comments about the security of this scheme,


    The security is pretty low, if you can talk about security at all. You
    are trusting the client to do authentication, and the client is
    entirely under the control of the user.
    You have no trusted server-side to do the authentication, so you will
    not have security against anybody determined and mildly competent.

    On the other hand, it's an internal application, which means that
    the users can be threatened with, e.g., being fired, if they do
    something they are not allowed to. This is much better security
    than any technical measure you have available here.

    Add logging and log auditing, and users should be able to police
    themselves.

    > but what I
    > really need to know is what standard or 3rd party classes are
    > available to implement it. I've looked through the standard classes
    > and Roedy's site but all I've found is the JPassportField, which is
    > exactly what I need for the GUI.


    > I'm currently still on Java 1.4. Some searching hints that the Crypt
    > class may be part of Java SE 5. Did I read this right? If so, it looks
    > like I'd best upgrade to Java 6 ASAP.


    Cryptography is available, but it doesn't need to be strong (since all
    it does is to make the key entered into the application not be the key
    that is actually checked - anybody circumventing the application and
    accessing the database directly will only need the encrypted
    value).
    Any one way method would do, as long as it's the same method used when
    changing password and when checking.

    Pick any cipher from javax.crypto
    <URL:http://java.sun.com/j2se/1.4.2/docs/api/>
    DES is one choice.
    But XOR'ing the bytes of the password by a constant would probably
    also suffice.

    I'd rethink the need for this.

    /L
    --
    Lasse Reichstein Nielsen -
    DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
    'Faith without judgement merely degrades the spirit divine.'
     
    Lasse Reichstein Nielsen, Jan 26, 2008
    #2
    1. Advertising

  3. Martin Gregorie

    Roedy Green Guest

    On Sat, 26 Jan 2008 21:20:01 +0000, Martin Gregorie
    <> wrote, quoted or indirectly quoted
    someone who said :

    >I need to implement login security for a database system and would
    >appreciate some suggestions.


    usually login is managed by your servlet womb. I gather you don't
    have any servlets.

    see http://mindprod.com/jgloss/servletwomb.html
    --
    Roedy Green, Canadian Mind Products
    The Java Glossary, http://mindprod.com
     
    Roedy Green, Jan 27, 2008
    #3
  4. Lasse Reichstein Nielsen wrote:
    >
    > So, you want to implement security.
    > The first thing to do is to establish the threat model.
    > What are you protecting?
    >

    Its effectively a document repository containing historic
    correspondence, where "historic" means "yesterday and earlier". Stuff in
    it may be company confidential but no more sensitive than that, i.e.
    there's no harm in permanent staff seeing it.

    > From what?
    >

    Temps and clients/competitors should be kept out. Interactive functions
    are limited to deleting cruft, so probably need to be restricted to
    specified staff members.

    > How bad is it if security is compromised?
    >

    Not really bad. See above.

    > So you are protecting the database from direct querying and altering
    > by local, semi-trusted, users.
    >

    Correct.

    > The username and password of the database should be kept "secret".
    > Users should not need to know them to use the system.
    >

    They also need to be configured into applications. At present I'm using
    standard *NIX type configuration files. Users don't need to see them
    but, of course, could do so.

    Are there any gotchas I'd need to be aware of if I moved the four values
    (JDBCdriver, DBname, DBuser, DBpassword) into the application JAR as a
    property file and used an extract/edit/replace cycle to customize them?
    I haven't yet tried modifying jar files, only building them. Hence this
    rather dumb question.

    > Alternatively, each user should be created as a user on the
    > database, with seperate credentials and capabilities.
    >

    Sure, with users tied to login names. That would be fine in a *nix
    system and was my initial plot, but the query application may also be
    run from Windows boxes which may not have a logged in user, user names
    may not be unique or the sysadmin may not be told if they change. It was
    this thought that prompted my query.

    Not clever, I know: I should have thought this through earlier.

    > Why encrypt the password?
    >

    To stop it being sniffed on the LAN.

    > It sounds like you expect all users to login using the application,
    > but they can just as easily do queries and alterations directly
    > against the database using a standard database tool.
    >

    Windows users are unlikely to have access to a database tool.
    Users with a *nix login can be kept away from it by using a captive
    login - logging in shows a menu of programs that they can't escape from.

    > The reason passwords are encrypted in traditional Unix password files
    > is to avoid having them available in plaintext to other users.
    > That's a good reason, maybe also in your case, but if the client
    > encodes the password, not the server that checks it, then the
    > real password just becomes the encrypted string. I.e., you have
    > no advantage from encryption, except from people restricted to
    > using your application.
    >

    I agree, but sending it in plaintext is equally undesirable. What's
    left? I don't like the idea of leaving database clients on Windows boxes
    without any form of user authentication either.

    How much more secure would things really be if I was to introduce a
    security server:
    - accessed over an encrypted link from a security module
    in the application program
    - passed the username & password
    - handles password encryption and lookup in the database
    as I originally described, but done local to the database.
    - after a valid login the application uses the database as normal
    - (not mentioned before but part of the plot) after x mins
    inactivity the application program would force the user to
    login again.
    >
    > Add logging and log auditing, and users should be able to police
    > themselves.
    >

    Good point, and something that the security server could handle.

    >
    > Cryptography is available, but it doesn't need to be strong (since all
    > it does is to make the key entered into the application not be the key
    > that is actually checked - anybody circumventing the application and
    > accessing the database directly will only need the encrypted
    > value).
    >

    Understood.

    I quite like the *nix plain username + encrypted password because its
    reasonably secure and simple to use. IIRC its a one-way DES-based
    algorithm that uses the user name as 'salt' for the encryption. Its
    implemented as the C crypt() function, which is why I was asking about a
    Crypt class. I'm not a cryptographer, so when I read through the package
    and class descriptions for javax.crypt and java.security I (a) didn't
    understand how to use them and (b) they seem to be focused on encrypting
    a document or session rather than a password: overkill IOW.


    --
    martin@ | Martin Gregorie
    gregorie. | Essex, UK
    org |
     
    Martin Gregorie, Jan 27, 2008
    #4
  5. Roedy Green wrote:
    >
    > usually login is managed by your servlet womb. I gather you don't
    > have any servlets.
    >

    Thats right. Its a simple system organization. Stuff is loaded into the
    database by a CLI program run by the cron daemon. A couple of GUI JDBC
    client programs are used to query and maintain the database. There is no
    web interface and no servlets. All code is plain-jane Java with Swing
    used for the graphical interfaces.


    --
    martin@ | Martin Gregorie
    gregorie. | Essex, UK
    org |
     
    Martin Gregorie, Jan 27, 2008
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Earl Teigrob
    Replies:
    3
    Views:
    593
    John Saunders
    Jun 10, 2004
  2. Aaron
    Replies:
    1
    Views:
    368
    John C. Bollinger
    Aug 4, 2003
  3. Marco
    Replies:
    1
    Views:
    2,436
    Roedy Green
    Jan 28, 2006
  4. Akram Baig
    Replies:
    0
    Views:
    340
    Akram Baig
    Apr 7, 2011
  5. Michael Randrup
    Replies:
    3
    Views:
    315
    Henning Krause [MVP]
    Mar 27, 2006
Loading...

Share This Page