• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Basic question about encryption

 
Ranch Hand
Posts: 114
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi guys,

I'm new at using encryption technique.

I read that what you usually do is encrypt the password entered by the user, and compare it to the already encrypted one in the database. Using the same algorithm, they should match.
But what I'm wondering is why couldn't a hacker grab the passsed encrypted hash, and use that for future transactions?

Thank you for the help
- Rudy -
 
Ranch Hand
Posts: 220
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
First off, don't confuse encryption with hashing. Encryption is reversible; with the correct key, you can decrypt and get back to the original data. A cryptographic hash is designed to be irreversible; you can only go "forward" through the hash. If I give you the hash of a string, you can't figure out what the original string was.

The basic idea of a system that stores hashed passwords for authentication is something like this:

the server has a list of username and hashed password pairs, (user_i, h(password_i)) for all the users with accounts on the system. To authenticate, you must provide the login process with your username and password -- lets say bob and bobspasswd. The system then attempts to retrieve the entry for the user named bob. If you don't have an account on the system, you'll get an error to that effect. If you do have an account, the system next computes h(bobspasswd) and compares it to the stored copy of the hashed password. If they match, then you are authenticated and allowed to proceed.

Suppose you get a copy of the hashed password h(ddspasswd) for another user diane. Remember, h is a cryptographic hash function, so you'll never be able to figure out the thing you have is the hash of "ddpasswd". If you provide the login process with h(ddspasswd) it will then compute h(h(ddspasswd)) which does not match h(ddspasswd).

There are certainly many security problems with the above simple system. For example, how can you login over a network securely? You can't.
 
Smith Li
Ranch Hand
Posts: 114
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the reply.

I'm using this example below from jguru.com as an example:



Original: And now for something completely different... the larch.
Message Digest: ♦═7→ ╚B╩b╩l

Then let'say message digest will be sent across network to check user information in DB. The DB has ♦═7→ ╚B╩b╩l in password column for this user.

Then a hacker can just simply send the message digest to login to the system and found a match with the information in DB, right?

Thanks
 
author
Posts: 23951
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Then a hacker can just simply send the message digest to login to the system and found a match with the information in DB, right?



Well, the hash is useless to the hacker, the system is challenging for the password -- not the hash. If the hacker provides the hash, instead of the password, the system will just rehash the hash (as if it was the password), and generate something that doesn't match.

Henry
 
Smith Li
Ranch Hand
Posts: 114
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the reply.

I haven't understant the concept quite yet. Could you please help explaining it a little bit more? This is what I thought would happen:
1. Let's say user "CLIENT1" encrypt his password from "TEST" to ♦═7→ ╚B╩b╩l
2. ♦═7→ ╚B╩b╩l will be sent across network.
3. ♦═7→ ╚B╩b╩l will be matched with the password saved in DB which is ♦═7→ ╚B╩b╩l

Then let say a hacker acquitre ♦═7→ ╚B╩b╩l in step. 2.
Then, next time, it can login to the system using "CLIENT1" and ♦═7→ ╚B╩b╩l as the password.

Isn't it that what's going to happen? since in step 3.there's no more hashing done.

- Rudy -
 
Henry Wong
author
Posts: 23951
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
First of all, this is *not* used to protect the security of the network. The client browser should use a secure connection to the app-server, and the app-server should use a secure connection to the database. The hacker should not be able to take the password from the network.

But the question is... what happens if the hacker can get to the database and get the password hash? (Stupid question because if the hacker can get to the DB, he can get to other stuff).


Anyway... The client has no idea of the password hash. The client only knows about the password. When the client (say browser) logs into the server, the server will challenge for the password only. The server then takes a hash of the password and compares that hash with the hash in the database. The server does *not* save the password anywhere. It should be discarded as soon as the hash is taken.

The DB should also be secure -- in that only the app-server logs in. The client does not log in. The client must log into the app-server. Anyway, the hacker uses his browser to log into the app-server. He will be challenged for the password, which he doesn't have.

Henry
 
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

1. Let's say user "CLIENT1" encrypt his password from "TEST" to ♦═7→ ╚B╩b╩l


The client does not hash the password. The password is sent in cleartext (hopefully over an encrypted connection) to the server, which then hashes it. So knowing the hashed password doesn't help an attacker, beacuse sending it over the wire will cause it to be hashed again on the server, in which case it will not match the hashed password stored in the database.
 
Smith Li
Ranch Hand
Posts: 114
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks guys,

All these information are really helpful.
I will play around with these ideas first before I finally decide what I'm going to do.

Thanks again.
- Rudy -
 
reply
    Bookmark Topic Watch Topic
  • New Topic