Visual Basic Question: Login/Password Authentication

Hello again! Im sure alot of you noticed my VB questions... you all have been AWSOME help.


Goal: Be able to have a user enter a log in name, and a password in a form, have the form search for the credintials on a database (access) (to see if they are correct) and then allow the user to go on to the next form.

Question: I have no idea how to do this, I dont know how or what syntax to use when the user presses "enter". Basically i got 2 text boxes Name/Password. I have a database using access. how do i link the 2 together? How do i even tell the form "if this matches what the database then go to next form, else msgbox blab bhab blahb" i hope thats enough info... Im still a new comer at this, this project due in less then 48 hours. a team mate dropped this on me so its urgent! thnx again.

Disclaimer: I am neither an expert in VB, nor do I enjoy programming in Microsoft environments:

My best guess from experience is:

- Open an ADO connection to the database (instantiate an ADODB.Connection object)
- Execute a SQL query to return the user's password (making sure you escape any funny characters in the username)
- Compare the password retrieved with the entered password
- For increased security, store the passwords with one-way encryption and compare the encrypted versions

There might be a much easier way but that's how I'd do it.

-- Separate security-related note

What constitutes "Funny characters" is database-dependent. Normally in SQL you would consider a single quote a funny character, but AFAIK, MSAccess has at least one more, the "pipe" character. Bear this in mind and deal with it accordingly.

For maximum safety, check that the username is alphanumeric and reject it otherwise.

**Moved from Antionline: How do I? to Programming Security**

Note: Antionline: How do I? is for post about how to do things on Antionline like delete threads, move threads, etc.

Quote:

---

Originally posted here by TSeNg

Question: I have no idea how to do this, I dont know how or what syntax to use when the user presses "enter".

---

In VB, when one double clicks on an object, the code widow cmes up, and for text boxes, it has the handling for the changing of text method open.

Select the KeyPressed() event and use that to say something along the lines of:

If (KeyAscii = 13) then '13 is the ascii code for carriage return
do database compare
end if

I'll look into the database later today, but I beleive you need to add a data object or 2, and then there is a property of which data source (your database) to link that to. From there, I'd check something more VB specific online.

i would also advise using a one way encryption method to verify the password.

Quote:

---

A cryptographic archive of 18 popular encryption algorithms, 6 popular hash algorithms and two popular compression and encoding algorithms for Visual Basic 5.0+. Changes for v2: Base 64 encoding instead of Hexadecimal encoding, fixed key initialization functions, updated the EBCrypt library, added CryptoAPI demonstrations from other authors, the inclusion of several classical ciphers, and an HTML page of crypto links. By David Midkiff

---

http://packetstorm.linuxsecurity.com...BCrypto_v2.zip
i use this library all the time, very useful ;)
taken from the packetstorm archives...

Shameless plug but: VB encryption is a small function that I have written to do one-way encryption in VB - it's very small (only about 10 lines of code) and not too difficult to understand.

I would avoid using anyone's 'home grown' solutions. Most look good at first, but the algorithms are usually flawed and open to attack. Go with a proven, tested solution.

There are a few providers of crypto api's out there that will do what you need. Microsoft has one available to you as well. Here is a book on how to use it, it also explains how crypto works - http://www.amazon.com/exec/obidos/tg...books&n=507846

As for ado, there are some decent books and tutorials out there on how to do it. You just need to learn the basics on how to use the connection, recordset, and command objects.

Slarty's steps from above are the path you want to take. Although in step two I wouldn't return the password, transmitting that back to the client is a bad idea. It would be simpler to compare the two hashes while still in the stored procedure or sql statement and pass back a code to indicate whether a match was found or not.

Quote:

---

Originally posted here by Juridian
[B]I would avoid using anyone's 'home grown' solutions. Most look good at first, but the algorithms are usually flawed and open to attack. Go with a proven, tested solution.

---

There is nothing inherently wrong with "home grown" solutions - and they are not necessarily any more insecure than ones written by Microsoft or anyone else.

I find that the ones that come with VB or can be purchased as add-ons tend to try and cover too many eventualities. My code simply takes a plaintext and produces a 32byte Hex hash from it. It has been tested not only by me (and is used in my current computing project), but also other people who have emailed me asking if they can use it in their code as well.

If you find any flaws in my algorithm, please let me know and I'll fix it. Until then, don't dismiss "home grown" solutions as being "usually flawed and open to attack".

What is inherently wrong with 'home grown' solutions is that they are done by amateurs, and usually not tested well enough to warrant use in a production environment.

I simply give the same advice that any larger information security entity (such as SANS/GIAC) would give.

Maybe you should not let posts on a message board affect your ego....

Quote:

---

Originally posted here by Juridian
What is inherently wrong with 'home grown' solutions is that they are done by amateurs, and usually not tested well enough to warrant use in a production environment.

---

Depends how you define 'amateur' really...

Quote:

---

Maybe you should not let posts on a message board affect your ego....

---

Maybe you shouldn't be so dismissive of other people's work and assume that everyone who writes a "home grown" solution is an amateur.