Hot answers tagged

129

Use Java keytool to convert from JKS to P12... Export from keytool's proprietary format (called "JKS") to standardized format PKCS #12: keytool -importkeystore \ -srckeystore keystore.jks \ -destkeystore keystore.p12 \ -deststoretype PKCS12 \ -srcalias <jkskeyalias> \ -deststorepass <password> \ -destkeypass <password&...


118

If you use Java like most other programming languages, e.g. to write standalone applications, it is no less secure than other languages and more secure than C or C++ because of no buffer overflows etc. But Java is regularly used as a plugin inside the web browser, e.g. similar to Flash. Because in this case the user runs untrusted code without having ...


81

The security vulnerabilites reported are not about Java (the programming language), which, by virtue of the JVM enforcing memory safety, is actually more robust than languages such as C or C++, where buffer overflows and buffer over-reads remain a threat, and can result in messes like Heartbleed. Instead, the vulnerabilites reported are in the Java Sandbox, ...


53

You're breaking one of the hashCode() taboos; you're using its output as a key identifier. That's wrong. You see, the output of hashCode() (in its default implementation) is a 32-bit unsigned integer, that's roughly 4 billion unique hashCodes. Sounds quite a lot? Well, not so much. Applying the birthday problem in this case shows as that with about 77000 ...


49

Yes - Java desktop and server applications are basically secure. When you run a desktop application - Skype, Picassa, whatever - you give that software full access to your computer. You have to trust the software. In contrast, when you run a Java applet in your web browser, the applet runs in a restricted environment called a sandbox. The sandbox exists so ...


42

Actually you cannot really "safely erase" an array of characters in Java. Java does memory allocation through a garbage collector, a tricky piece of software which, in practice, will move memory objects in physical RAM on a regular basis. So what you think as "a char[] instance" will be copied in several places, and the erasure will physically happen only in ...


40

Hashing on the client side doesn't solve the main problem password hashing is intended to solve - what happens if an attacker gains access to the hashed passwords database. Since the (hashed) passwords sent by the clients are stored as-is in the database, such an attacker can impersonate all users by sending the server the hashed passwords from the database ...


38

Both OpenJDK and Sun read from /dev/urandom, not /dev/random, at least on the machine where I tested (OpenJDK JRE 6b27 and Sun JRE 6.26 on Debian squeeze amd64). For some reason, they both open /dev/random as well but never read from it. So the blog articles you read either were mistaken or applied to a different version from mine (and, apparently, yours). ...


35

The client is the attacker. Walk around your office while chanting that sentence 144 times; be sure to punctuate your diction with a small drum. That way, you will remember it. In your server, you are sending Java code to run on the client. The honest client will run your code. Nobody forces the attacker to do so as well; and you use client authentication ...


35

Use TLS for the connection to the server. The purpose of securely hashing a password is to make it more difficult to attack if the database is ever stolen. It is not designed to prevent sniffing the plaintext password. In order to securely communicate with the server over a hostile medium, you should be using TLS. This will prevent interception on the wire, ...


34

Apple apparently takes this seriously, since they "disabled Java" in users' computers, which is a rather drastic move. This actually smells like a pretext to kill off the technology, as part of a wider strategy. For this specific hole, there are a few details there. It is all about the Java applet model. To understand: Java is a programming language and a ...


33

There are published successes with remote timing attacks. From the document -- "... we can reliably distinguish remote timing differences as low as 20µs." So yes, you should be worried about the underlying implementation of .equals() (spoiler: Not secure). Implement .equals() using a sum of XOR of characters to compare in a timing-independent way. Here's a ...


30

Java hashCode() was never intended to be used like this. Don't do ever it! It is even legal (while not recommended) for all instances of a class to return the same hashCode. The contract in Java is "two objects that are considered equal must have same hashcode". No more, no less. It would for example be valid to return hashcode 1 for all uneven numbers and 0 ...


28

Never hardcode passwords or crypto keys in your program. The general rule of thumb is: the only credentials you should store on a user's machine are credentials associated with that user, e.g., credentials that enable that user to log into his/her account. You should not store your developer credentials on the user's machine. That's not safe. You have to ...


27

I think this is a "trend effect" which is also the drive under everything about fashion (in the "clothing" sense). Please allow the local Frenchman to talk about fashion. Fashion is a deeply self-contradictory social behaviour. People who follow fashions seek both: to gain acceptance in a given local group by displaying adherence to perceived agreed upon ...


26

Programming is relevant to IT-Security; it may be subtitled as "yeah, I kinda grasp the concepts of what I am blabbing about". You cannot be a decent practitioner of IT security if you cannot imagine what occurs in a computer beyond something like "then magic occurs". This necessarily implies some basic skills at development. The exact programming language ...


24

In short, they're both crypto key generation tools, but keytool has the additional feature of manipulating Java's preferred key storage file format, the KeyStore. Java strongly prefers to work with keys and certificates that are stored in a KeyStore (also called a TrustStore when it's only got certificates in it). It is possible, but not trivial, to get ...


24

In theory, this is a possible exploit, and if you are in super-paranoia mode, you should assume the answer being "Yes". In every other case, the answer will be: "No.". Although there are published papers (one is linked in the answer by @Oasiscircle) which claim that they are able to run successful timing attacks, one has to carefully read the preconditions, ...


24

If it's an official service you are integrating with the provider should really have a valid, publicly signed certificate installed for the sake of security. Assuming that you need to continue on with your provider using a self signed certificate, the big difference between ignoring the certificate and adding it as trusted is the following scenario. This ...


23

Try "Keystore Explorer" I agree with Bruno. Keytool is ultimate tool when dealing with Java keystore, but there is one fancy and quite powerful free tool: Keystore explorer I use it a lot and never had a need for something else.


20

TLS ciphersuite names are structured in such a way that you can tell what algorithms and key sizes are used for each part of the handshake and encrypted session. Let's break this one down and see if there are any improvements we can make: TLS - This doesn't signify anything in itself, but does allow me to mention that TLS 1.2 is the latest version of TLS ...


17

Kerckhoffs's principle: A cryptosystem should be secure even if everything about the system, except the key, is public knowledge A wrong example: LANMAN hashes The LANMAN hashes would be hard to figure out if noone knew the algorithm, however once the algorithm was known it is now very trivial to crack. The algorithm is as follows (from wikipedia) : ...


17

You could audit the jBCrypt code yourself. It is small: one 750-line source code file, half of which being an array of constants. Moreover, since this is Java, you do not have to fear the dreaded "undefined behaviour" of C: if it works well on your machine, it will work well everywhere (for that kind of code, which does not involve threads, system access of ...


17

@John already descriped the passing of the password over the network very well (use HTTPS). To answer your question: Where should I hash them? Frontend or Backend? The backend. If you only hash them in the frontend, you are vulnerable to a pass the hash attack. The reason that you hash passwords in your database is to prevent an attacker who already ...


17

By importing a known good self-signed certificate where the private key is unique and not compromised, the connection is just as safe as a full global CA PKI signed certificate. Those are after all also simply stored and trusted at some point. The reason to get a PKI CA signed cert is one of practicality more than security; if you have to trust a self-...


14

You need to store a "password" (or password to decrypt the password, or password to decrypt the password to decrypt the password, etc ad infinitum), somewhere. So, either you can store it on the computer, but then it can be deobfuscated and read (if your program can do it, any program can do it) or in the user's head (harder to get at programatically, but ...


14

The entropy in a session identifier is the entropy of the underlying number source; a PRNG might yield good random words of 32 bits, each of them having 32 bits of entropy (however, as @forrest pointed out, entropy doesn't "carry" - it will grow until it reaches the size of the PRNG's internal state, and theoretically that state could be back-calculated ...


14

From a basic usage point of view, difference is how resulting TrustManagers are initialised, as per Java Cryptography Architecture Oracle Providers Documentation for JDK 8 SunX509: A factory for X509ExtendedTrustManager instances that validate certificate chains according to the rules defined by the IETF PKIX working group in RFC 3280 or its successor. ...


14

Store a good cryptographic hash of the secret on the server (i.e. treat it like a password). Your comparison then would be to take the hash of the string the client sends you, and compare the hashes. If the secret has high enough entropy, this should eliminate timing attacks and prevent leaking of the real secret string, since it should be practically ...


13

In a cryptographic protocol: Make every authenticated message recognisable: no two messages should look the same A generalisation/variant of: Be careful when concatenating multiple strings, before hashing. Don't reuse keys. Don't reuse nonces. During a run of cryptographic protocol many messages that cannot be counterfeited without a secret (key or nonce)...


Only top voted, non community-wiki answers of a minimum length are eligible