[WEB4LIB] RE: database authentication script

[James Cayz]

Everyone,

On Mon, 26 Apr 1999, Glen Davies wrote:
>> You may realize this, but you have two glaring security holes in this 
>> temporary solution.
>> 
>> (1) You are sending usernames and passwords unencrypted across 
>> the network.
>

I, too, do this, only because I haven't bothered to write the proper
encryption routine.  Does anyone know what exactly the schema is, and is
it one-way or reversible?

[ As a side-bar, I don't encrypt the passwords to/from the PC, but the
passwords to/from the central server and the remote library systems *is*
encrypted, using Unix crypt.  Now, this is "one-way", but since the remote
system sends the encryption to the central server (who has what the user
sent), the central server can encrypt what the user just typed in, and
compare the two encryptions.  If they match, then the passwords must
match.

I did this since the central server to/from remote library system converse
a LOT more than the central server to a specific PC, and thus, its traffic
is a bigger "target" for spoofing.  Someday, I write the code to
reversible-encrypt the password from the browser to the central server. ]


>> (2) You embed the generic username and password for the database 
>>in the HTML returned after successful user authentication. 
>>Anyone who does a "view source" can clearly read the hidden 
>>form fields.
>
>Similar to above. If they get this form returned they have passed 
>the userid check, so it doesn't matter if they see the actual userid 
>and password that is being used to log in to the vendor database. I 
>can change this userid and password as often as I like, and if their 
>library membership expires they won't be able to get back to this 
>form to see the new one. (unless they are clever, and who am I to 
>stifle ingenuity!)  

Since a lot of vendors do this ALREADY, I can't see us being crucified for
this.  I have several entry points where this is the only method I can
provide for non-local ISP users of our systems.  What's worse is that if
our users don't have Java-compatible browsers, the userid & password is
part of the URL, and is displayed in the location bar !!!???!!!

I personally prefer the other method that vendors have used - reffering
URL.  If their system can match a URL (usually with some type parameter to
a cgi program) with the "HTTP-REFFERER" field, which just happens to be
the successful return page from your authentication routine, then it
becomes difficult for someone to spoof this, without some trouble.

This is a lot more than the very loose constraints that the vendors use or
impose upon us.  I sleep at night knowing that I have made a reasonable
effort to keep honest people honest.

James

+--------------------------------------------------------------------------+
| James Cayz  #  cayz at lib.de.us #  DelAWARE homepage: http://www.lib.de.us |
| Network Processing Administrator #  302-739-4748 x130 # Fax 302-739-6948 |
| Delaware Division of Libraries # 43 S. DuPont Hwy / Dover, DE 19901-7430 |
+--------------------------------------------------------------------------+