Application security question

[Martin Gregorie]

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.

 

[Lasse Reichstein Nielsen]

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

 

[Roedy Green]

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

 

[Martin Gregorie]

>
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 Gregorie]

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.