Re: Application security question

Martin Gregorie <martin@xxxxxxxxxxxxxxxxxxx> 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 - lrn@xxxxxxxxxx
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
.

Relevant Pages

  • RE: How to allow users to change their password?
    ... be set up to provide the Security dialog window for password changes. ... I'll have to login using their login ... > name/password first. ... See http://www.QBuilt.com for all your database needs. ...
    (microsoft.public.access.security)
  • Re: Enter user name, enter password, then press enter...
    ... What do you do when the customer asks that the database login in be the same ... username and password to use all of the stuff that she is permitted to use. ... I have implemented this type of security for Access, VB, and Web Based ASP ...
    (microsoft.public.access.forms)
  • Re: Login forms
    ... >>> I'm trying to develop a login form for an access database. ... >>> to use the Access User Level Security at the moment. ...
    (microsoft.public.access.forms)
  • Re: Linked Table-Embed Password
    ... > for the one login was the security. ... Don't confuse data security issues with data integrity issues. ... It may be common, but it's not secure. ... See http://www.QBuilt.com for all your database needs. ...
    (microsoft.public.access.security)
  • Re: SSN encryption
    ... >> We want to encrypt social security numbers in a database. ... address and SSN are always excluded. ... exposed if there were a breakdown in the other security precautions. ...
    (sci.crypt)