Tag Info

Hot answers tagged

97

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 ...


77

Don't roll your own crypto. Don't invent your own encryption algorithm or protocol; that is extremely error-prone. As Bruce Schneier likes to say, "Anyone can invent an encryption algorithm they themselves can't break; it's much harder to invent one that no one else can break". Crypto algorithms are very intricate and need intensive vetting to be ...


68

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, ...


47

Don't use encryption without message authentication It is a very common error to encrypt data without also authenticating it. Example: The developer wants to keep a message secret, so encrypts the message with AES-CBC mode. The error: This is not sufficient for security in the presence of active attacks, replay attacks, reaction attacks, etc. There are ...


47

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 ...


36

Be careful when concatenating multiple strings, before hashing. An error I sometimes see: People want a hash of the strings S and T. They concatenate them to get a single string S||T, then hash it to get H(S||T). This is flawed. The problem: Concatenation leaves the boundary between the two strings ambiguous. Example: builtin||securely = ...


33

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 ...


29

Don't reuse nonces or IVs Many modes of operation require an IV (Initialization Vector). You must never re-use the same value for an IV twice; doing so can cancel all the security guarantees and cause a catastrophic breach of security. For stream cipher modes of operation, like CTR mode or OFB mode, re-using a IV is a security disaster. It can cause the ...


29

Make sure you seed random number generators with enough entropy. Make sure you use crypto-strength pseudorandom number generators for things like generating keys, choosing IVs/nonces, etc. Don't use rand(), random(), drand48(), etc. Make sure you seed the pseudorandom number generator with enough entropy. Don't seed it with the time of day; that's ...


28

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 ...


27

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 ...


26

Since Java 6, you can import/export private keys into PKCS#12 (.p12) files using keytool, using -importkeystore (not available in previous versions). For example: keytool -importkeystore -srckeystore existing-store.jks -destkeystore new-store.p12 -deststoretype PKCS12 The PKCS12 keystore type is also supported as a standard keystore type in the default ...


26

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 ...


20

Don't use a block cipher with ECB for symmetric encryption (Applies to AES, 3DES, ... ) Here is a post and a very similar Microsoft KB article regarding how ECB mode results in code that isn't encrypted. Also see this similar post from Rook Plain text message: The same message encrypted with ECB mode (doesn't matter what cipher you use): The EXACT ...


20

Don't use the same key for both encryption and authentication. Don't use the same key for both encryption and signing. A key should not be reused for multiple purposes; that may open up various subtle attacks. For instance, if you have an RSA private/public key pair, you should not both use it for encryption (encrypt with the public key, decrypt with the ...


20

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 ...


19

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). ...


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) : ...


15

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 ...


14

Theoretically, any kind of null-pointer dereferencing in Java triggers a NullPointerException, which can be handled within Java just as any other exception. This does not mean that this is good: in practice, it is quite hard to recover from such an exception except by removing the faulty part (i.e. letting the calling thread die, or getting back to a ...


13

Try to avoid using passwords as encryption keys. A common weakness in many systems is to use a password or passphrase, or a hash of a password or passphrase, as the encryption/decryption key. The problem is that this tends to be highly susceptible to offline keysearch attacks. Most users choose passwords that do not have sufficient entropy to resist such ...


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 ...


12

It is not cryptographically secure, because that's not part of its requirements. How the hashCode is implemented is an implementation detail up to the JVM and can be different for different object types (objects can override the hashCode method and provide an own implementation). The purpose of the Java hashCode is to identify objects when placing them in ...


11

If you try to use pointer that is null, Java will throw a NullPointerException. Since this is a RuntimeException, you don't have to catch it, but you can. So for example String iAmNull = null; iAmNull.trim(); will throw a NullPointException and exit the program. If however you catch it try { String iAmNull = null;<br> ...


11

PHP runs on the server; it is code which ultimately produces a Web page to be returned to the client. From the client point of view, only the received bytes matter, not how they were computed on the server; it makes no difference whatsoever to the client if the Web page was dynamically generated with PHP or Java or whatever, or if it was the contents of a ...


11

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 ...


11

Yes, Java class files are easy to reverse engineer. The format is very regular, and very constrained: the VM must be able to verify that the code complies to the strong typing rules of Java code. This is like the output of a C compiler with all optimizations deactivated: the program structure is plainly visible. (In the Java model, optimization happens in ...


10

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.



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