Password encryption

[SilentCJ]

Are passwords saved in just MD5? If yes, its good

Thanks to whoever helps or replies

[Antechinus]

No.

[Arantor]

Specifically, they're salted SHA1. MD5 is a bad idea, because it's incredibly easy to break (even if it's salted, it's still ridiculously easy to generate rainbow tables because it is an order of magnitude weaker than it is supposed to be)

[Antechinus]

I get the impression this person was hoping they'd be easy to decode.

[Arantor]

There's two reasons they would be asking, either to decode (which is impossible, the original password is never stored, and it's a one-way process, instead you look for strings that create the same hash as a result, which doesn't have to be the same password at all), or to bridge with another piece of software.

There is still plenty of software out there that uses MD5 based hashing (either directly, naively or as part of something much more sophisticated)

[Antechinus]

The OP had another topic in which he/she was asking if all encryption could be removed, so the passwords were stored in plain text in the db.

[Arantor]

That suggests the reason is for bridging to something else then (e.g. an online game) rather than to actually expose the passwords.

(I don't immediately assume the worst about everyone... )

[SilentCJ]

That suggests the reason is for bridging to something else then (e.g. an online game) rather than to actually expose the passwords.

(I don't immediately assume the worst about everyone... )

Its actually for a snapping program I'm making in java, and I want you to be able to log in with your forum account so your snaps are logged on your profile. It would convert the text in the password box to md5 then compare with the one in the database.

Damn

[Arantor]

It's hardly an insurmountable problem, just need more details.

Where's the Java program running at? In the browser as an applet or on the server?

[SilentCJ]

It's hardly an insurmountable problem, just need more details.

Where's the Java program running at? In the browser as an applet or on the server?

Its running on the users computer, it asks for your username and password when you first open it, or thats what I want it to do.

[Arantor]

In which case it's not going to have access to the database anyway, is it? (Making the DB accessible directly by the client is a bad, bad idea on so many levels)

So when it opens, you send the username and password to a script on the site which does the authentication against the database in the format that the DB is already in (you should be able to use the SMF API for this) and responds back with whether the user is valid or not.

[SilentCJ]

In which case it's not going to have access to the database anyway, is it? (Making the DB accessible directly by the client is a bad, bad idea on so many levels)

So when it opens, you send the username and password to a script on the site which does the authentication against the database in the format that the DB is already in (you should be able to use the SMF API for this) and responds back with whether the user is valid or not.

It queries username and password on my website and displays the password. It compares the one displayed to the one entered. If its correct it launches and if its not it gives an error. Its not going to have direct access

[Arantor]

Oh, that's lovely and secure.

What's stopping you using things how they're meant to be used - i.e. keeping as little data on the client as possible?

[SilentCJ]

Oh, that's lovely and secure.

What's stopping you using things how they're meant to be used - i.e. keeping as little data on the client as possible?

I don't get what you mean. The user sees nothing that goes on, its all in the script.

[Arantor]

It doesn't matter what the user sees. The whole concept of collecting a username and password, doing the hash on the client, sending it to the server and *getting the answer back* is a bad idea. It's insecure, and potentially compromising if what's returned is a different hash.

Better simply to send the username and password, do the hash totally on the server, and return a simple yes/no response.

That's putting it at its simplest, doesn't get into anything like using cookies or tokens or anything else. You move all the actual logic out of the client and put it all on the server where it can be less tampered with.