Hot answers tagged java
71
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 ...
44
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 ...
37
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 = ...
31
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 ...
28
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
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 ...
25
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 ...
19
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 ...
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) :
...
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
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 ...
12
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
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 ...
11
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 ...
10
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>
...
10
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 ...
10
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 ...
10
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 ...
9
The more you invest in protecting your binary from crackers:
the less of your project cost is being invested in adding value for the customer
the more expensive your product becomes, driving away legitimate customers
the longer your time to market, allowing a less conservative competitor to execute faster
Virtual machines are part and parcel of the way ...
8
Don't use the same key in both directions.
In network communications, a common mistake is to use the same key for communication in the A->B direction as for the B->A direction. This is a bad idea, because it often enables replay attacks that replay something A sent to B, back to A.
The safest approach is to negotiate two independent keys, one for each ...
8
Don't use insecure key lengths.
Ensure you use algorithms with a sufficiently long key.
For symmetric-key cryptography, I'd recommend at least a 80-bit key, and if possible, a 128-bit key is a good idea. Don't use 40-bit crypto; it is insecure and easily broken by amateurs, simply by exhaustively trying every possible key. Don't use 56-bit DES; it is not ...
8
First point, never use SHA256 for hashing your passwords. Use bcrypt or pbkdf2. Here is a link to a Java library for bcrypt.
The library will take care of most of the details, including the generation of salts. Use it, don't roll your own.
What is the purpose of the password? Is it for authentication? If so, just store the hash somewhere you can retrieve ...
7
One common, standard encryption format is Cryptographic Message Syntax (CMS, evolved from PKCS#7), and e.g. BouncyCastle supports it. It allows for signatures also, and is the basis, e.g., for S/MIME mail message security. It may be overkill, but is widely supported.
Example code is provided by Bouncy Castle. For CMS, see org.bouncycastle.cms.test, ...
7
Try LAPSE+, Yasca, CodePro AnalytiX, Klocwork Solo, and the Teachable Static Analysis Workbench.
Be sure to check out The Denim Group's blog post on Using static analysis to review file access in android apps, which includes some tools written in Perl.
When Angry Birds Attack Android Edition is the latest blog post from TEAM JOCK, who presented on this ...
7
This may sound mysterious, but once you understand the threat model that they're talking about, it all makes sense. The web page you link to is talking about preventing people from hacking your app to bypass the in-app billing.
Example: Let's suppose you've built a fun game that people can play, by installing your app on their Android phones. You use ...
7
It sounds like you are using cryptography improperly. There is no reason to store encrypted data within an html page. Further more ECC and another asymmetric algorithms are very resource intensive. A symmetric cipher should be used with a mode that has authentication.
But most importantly. Why aren't you using HTTPS?
7
Yes. Java applets can access the original client IP address using java.net.InetAddress.getLocalHost().getHostAddress() and then send it anywhere.
See also Are there any addons that disable only some functionality of scripts? and the Tor documentation (e.g., this page) for more discussion of how various web technologies could reveal your original client IP ...
7
My German is pretty rusty, but I'm pretty sure the article from Heise Security doesn't really say what the H-online article claims.
Unter Opera erreicht man die Plugin-Verwaltung durch die Eingabe von opera:plugins in die Adressleiste. Beim Internet Explorer genügt das Deaktiveren der Plug-ins unter "Add-Ons verwalten" nicht. Wer den IE einsetzt, sollte ...
Only top voted, non community-wiki answers of a minimum length are eligible
