So I have a wesbite running php which encrypts all passwords using a line such as
password_hash($_POST['password'], PASSWORD_BCRYPT, $options)
and verify passwords as follows
$passwordCheck = password_verify($password, $row['password']);
the options variable being:
$options = ['cost' => 00];
I have excluded the number with 00 but it is of course something else not sure if it is relevant for me to not give out that number.
Here is the issue,
I am running a SmartFox server which runs in java. I am using the login assistant (perhaps I may need not to, please continue reading) and it tries to compare the password I send to it as a plain text password, of course the MySql passwords are using BCrypt. Now in the documentation it references I can set the sign up to use Md5 so I presume I must be able to support this type of password check.
using md5
http://docs2x.smartfoxserver.com/api-docs/asdoc/com/smartfoxserver/v2/util/PasswordUtil.html
login assistant documentation
http://docs2x.smartfoxserver.com/DevelopmentBasics/login-assistant
I believe I can try the following but please don't hesitate to tell me to approach this from another angle or that one of these won't work (as I don't understand hashing/encryption/salt/rainbowtables ect):
Could I convert the password in the c# application I am sending the password from and have the server check that against the database
Could I use a preprocessor to convert the password and check it and set the password to the password from the database if the preprocessor tells me it matches
get java to execute a php script if BCrypt isn't available on java
I think you are hashing, not encrypting password, if I am not wrong. As BCrypt in PHP can be used to do both, names are important.
Avoid using MD5, it is considered broken nowadays - You have online searches http://www.hashkiller.co.uk/ and distributed bruteforcing tools that could require even hours or less to break a new MD5 hash.
Still the question is not totally clear, but let me try: you control the way $row['password'] is stored, but you are using the BCrypt "standard" in php and that does not seem to have an equivalent in Java. So you can't read/write $row['password'] from a java program, in a way it works at least. Is that correct?
If that is the case, the previous question about this here How do you use bcrypt for hashing passwords in PHP? explains you what is BCrypt and you could find a library implementing the same algorithm in Java. But I would not suggest that approach, while I would use one of the Portable PHP Hashing Functions listed in that very same page in the best answer (that should be your first approach in the list?)
The second approach with the preprocessor is not clear, but a general tip: simple is better, way better with security. If it sounds just a little bit "odd" or "cumbersome", avoid it, replace it with something easy to explain, that "looks good" and that can be easily mapped to a well-known / documented solution.
There is an implementation of BCrypt in Java here. I make use of it in several of my applications. I've even implemented a GUI to generate hashes and test matching plaintext. BCryptGenerator
Related
Hello Everyone!
I am still fairly new to Java programming, so please forgive me if this question is not thorough enough.
I am trying to find a way to salt and hash my passwords in Java for a web app that requires a password login.
I tried to use the Bouncy Castle bcrypt and scrypt classes in order to get a method of salting, hashing, and password verification only to find out that there is no password verification method in either one of these classes. If I am incorrect in this assessment, please let me know what the method is for password verification or if I am missing something.
As an alternative, I have decided to try out bcrypt instead before I just break down and go to PDBKF2 since there is more documentation out there for that instead of bcrypt or scrypt.
The problem that I am running into is that I found Mindrot's bcrypt at this website: http://www.mindrot.org/projects/jBCrypt/#download
, but my concern is that it hasn't been updated in about two years. I had a developer at my work tell me to only use encryption methods that are being constantly updated within the past six months, so it makes me really nervous to even consider it.
Has anyone out there used jBcrypt recently? Is it still something that I can use for my project?
If not, where is somewhere reliable that I can get either bcrypt or scrypt with password verification?
Thanks in advance!
You should not worry too much about jBcrypt, as far as I know, is a widely used library, and if you check author's webpage you will see that the library has been updated to resolve security issues and bugs.
The code is not so big and you can take a look, specifically, check the tests.
I'm trying to make a game that will tie into website content, and users' accounts will be shared across the site multiple versions of the client.
The problem is that the password needs to be salt-hashed in PHP, and I need to be able to verify through Java, and I can't find any information on secure cryptos (like PBKDF2) and ensuring that the generation is identical between PHP and Java.
I've seen some info on using PBKDF2 on PHP, OR Hmac with SHA-1, but not combining them as is suggested in the name of Java's "PBKDF2WithHmacSHA1". I have a handle now on the individual hashing for PHP or Java.
How do I set up the methods to be able to generate a salt and hash on PHP, store it in MySQL and be able to verify passwords through Java's hashing functions?
Would prefer to stick with PBKDF2, if at all possible (unless someone can suggest an equivalent that would work better for cross-compatibility).
P.S. Not particularly sure whether this deserved to be here or on Crypto SE. I figured, since I was asking about specific languages, I'd try here first.
So, it turns out it wasn't as complicated as I was thinking it was. I found this question that said that PHP's equivalent to Java's PBKDF2WithHmacSha1 was the hash_pbkdf2 function with the sha1 algorithm. From there it was just a matter of transferring the salt and hash from the PHP to the Java. Here's how it ended up:
1) PHP: For this one, I just copied the guy's pbkdf2 function and generated the salt and hash like he did.
2) Java: All that needed to happen was a bit of a change in the bytecode conversion, and it worked just fine.
After that, all I needed to do was modify the Java code to fit into my server/client setup (including secondary session hashing), and work out a few more bugs surrounding more salt and hash encoding and decoding through network transmission, and it works perfectly now.
A slightly more detailed answer is available on that other question.
Try to consider using a pre-built user and password management like JBoss KeyCloak. It is based on standards like OAuth2 and OpenID Connect, and things like password reset, user registration and social login come for free. It includes connectors for Java and JavaScript. Apparently connectors for PHP are available as well.
I'm looking for a secure symmetric-key encryption algorithm compatible with both JavaScript and Java.
I've tried implementing one but I had some encoding issues.
You don't want to encrypt with JavaScript, especially on the client-side where it is open to tampering, and has no cryptographically secure random number generator.
I've tried implementing one but I had some encoding issues.
You tried to write your own encryption algo? You've gone against everything that the security world hold dear. No. Actual tutorials that explain how encryption works are so scared that people are going to screw things up because they don't understand the math behind it, I've actually seen this in one of them:
If you don't understand encryption, things like, what "cryptographically secure pseudo random number generator" actually is, and common attacks on it, you shouldn't do that.
If you don't understand things like side-channel attacks, you shouldn't do it.
If you don't understand what's going on in crypto and have read at-least two books on it you have no business implementing it.
Crypto is not a magic black box, it's something that is very VERY easy to screw up, even without touching any bit of code in a packaged solution.
What should you do? Forget about JS encryption. I know, I've tried it myself. It's a waste of time. Learn from my mistakes.
Go get an SSL certificate, SSL is the best way for us to encrypt messages on the transport level from a server to a client. It's about as secure as you can get. If you face an advesary that can defeat SSL, trust me, your JS-based crypto is also compromised.
Once it's at the server where it's secure from being tampered with, encrypt it. Anything else is a really long way to waste your time.
Also, go read these books:
![This one is free][4]
[![This one is cash money][5]][5]
(source: [schneier.com](https://www.schneier.com/images/book-ce-150w.jpg))
Then when you understand them come back and scream at me about why I'm wrong and don't understand how much you need JS on the client to do crypto.
There is an excellent DES (and by extension 3DES) implementation in JS, which I use quite often. I'll put up the link Monday, when I'm at the office and have it ready. Results from this (after base64 encoding for the transport) work perfectly with .Net/Mono (builtin), Java (bulitin) and PHP (mcrypt).
Found the links, but both are dead: http://www.shopable.co.uk/des.html and http://www.netdealing.com. I have put it up on http://pastebin.com/KbRsWKJY
This page has CTR mode, which is available in Java. I would recommend keys of 128 bits or you might run into trouble regarding the Java export policies on larger key sizes.
Here is a page which uses some very usefull methods of encryption, including password encryption techniques and ciphres with integrity checks and authentication, although you may need the bouncy castle libraries on Java to match those all.
There are oodles of libraries for JavaScript, but character encoding issues will be present on any of them. So make sure you use the same encoding both on the JavaScript side as well as on the Java side. A quick look up assures me that JavaScript uses UTF-16 internally, but don't hang me up on that.
Finally, don't try this at home, the libraries are there, use them (especially if they mention tests and/or official test vectors).
Like the other answers said, if you don't have to encrypt with JavaScript, avoid it. However, there are some valid use cases to encrypting in JavaScript.
When you need to, I recommend this library: https://keybase.io/triplesec/.
It's more secure than DES, which another answer links to.
On our server, we have several periodical jobs that login to external accounts through API's. Currently, these passwords are hard-coded (in the clear). We are going to be storing them in a database and would like to encrypt the passwords, but we must be able to decrypt them to login to the external sites. Is there a way to store these passwords securely without having another password stored in the clear for encryption/decryption? (This seems like a common problem, but I am not familiar enough with security terminology to classify it). Thanks!
What you are trying to achieve is very similar to this question. Ideally you do not want to keep these secrets in the database, you want to keep them as far away from your application as possible. Why? Because this way you can at least rule out the application itself as an attack surface and it will be much harder to get access to those passwords.
In your case you want to protect the encryption keys with a password. This means that you have to store the password somewhere. Should you encrypt that password again? This leads to a vicious cycle - it's what I meant by this section of the answer:
... What brings us to that resource. It's really a hen-and-egg problem with key stores and passwords. The only really clean solution to this is entering the passwords manually each time the app/database is started. But this tends to be a real problem (think of: crash in the middle of the night), so people tend to store the passwords in a text file on the file system. It's acceptable as long as you follow some guidelines:...
If you encrypt something, then there is a secret resource, the key involved. The ideal way to keep it secret is, as outlined in the quote, memorizing it and entering it manually so that no trace of it is left behind. As this is often not manageable, you have to live with something less secure than memorizing but better than storing the secret in plain text.
The same recommendations as in that post apply to your case with regard to storing the secret password in a file. As an alternative you could try to leverage OS Secure Storage facilities such as Windows Data Protection.
I have a legacy system with passwords that look like this 115c28e0578f262bde08e3de39ee9066. Im not quite sure if they were created with md5 or crypt or... It was a java application that created them.
My new system is in Python (Django) and I tried to run a comparison check on a known password using md5(), sha1() and crypt(). None of them came back with an identical result of what this legacy system has given me.
Assuming the passwords were created within java, is is possible for Pythons equivalent modules to read/convert them so I may import that into a Django project? I'd love to not have to bug my users to reset their passwords.
In general, you will need to know the exact algorithm used by the Java program. Then you would be able to recreate the same results in Python. (You cannot get the plain-text password from the hash, without using brute-force, but you should be able to recreate the same hashing algorithm, so you can verify a user's password against the hash).
It is very possible that the passwords where hashed with something called a salt when they where stored in the Java application. This is a bit of random information added to the password, and the purpose is to defeat dictionary attacks. If this is the case, you will need to know what data was used for salt.