Tag Info

New answers tagged

0

Without the JCE Unlimited Strength Policy files in place, Java is able to use "strong but limited cryptography". That isn't limited to 128-bit or less necessarily. Just that "the jurisdiction policy files distributed with the Java SE 7 software have built-in restrictions on available cryptographic strength." From the README.txt: Due to import control ...


3

In "pure Java", there is no buffer overflow or use-after-free or double-free or anything like that. This is what the "VM" part of "JVM" is about. ROP is something that you use to leverage an initial breakage whereby you succeeded in overwriting the "return address" for some function, and induced the CPU to jump where you want. By definition, these conditions ...


0

If you want passwords, the best way is to use TLS, and then send the passwords in clear. This is simpler than a challenge-response mechanism. If you however can't have TLS for websockets, but you have TLS for the code (delivered over HTTP), best thing to do is to do the login via HTTPS, generate session cookies (or some other form of keys) and use them to ...


1

If you want security, transmitting authentication data through TLS is a big start. But let's assume the websocket is already set up over TLS. A solution I would recommend would be based on a challenge-response mecanism : The server would set up a random set of bytes (the challenge), set a timeout at the end of which the challenge wouldn't be authorized. ...


3

The vulnerability (still undisclosed) is also described as "Microsoft Schannel Remote Code Execution Vulnerability", which indicates that it is an implementation weakness (namely, a probably boring buffer overflow), not a protocol weakness. Thus, there is no reason to believe that the vulnerability would be shared with any other independent implementation of ...


6

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


5

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 is as "safe" as any cipher suite can be: there is no known protocol weakness related to TLS 1.2 with that cipher suite. Any particular implementation can, of course, botch things and introduce weaknesses on its own accord. You can also trample your own security to the ground by, for instance, failing to properly protect ...


1

Java's SecureRandom does use /dev/random, but only briefly. Specifically it only uses it when generating seed information, either by explicitly calling SecureRandom.generateSeed() or by the first call to nextInt() So therefore, to repeat your bash example you can do the following, and it should block. import java.security.SecureRandom; public class A { ...


1

A secure channel cannot be established unless either (i) the two parties are either using public key cryptography or (ii) the two parties are using a pre-shared secret. RSA private keys (or any other private keys for that matter) are never meant to be sent. From your question it seems you are not aware of how public key cryptography properly works and I'd ...


0

The servlet engine you are using securely handles session cookies when you call request.getSession(), and is not vulnerable to fixation. (as discussed in the comments) This behavior is both intentional and correct. Whether getSession(), getSession(true) or getSession(false) is called, the server relies on its own memory to determine if there is a valid ...


1

Yes, there is a better option, and it's called OAuth. It's specifically designed to support secure cross-domain authorization, and if you want more than bare authentication, there's a supporting standard called OpenID Connect that is built on top of the OAuth 2.0 framework that provides some richer standard data around users.


1

A failed deletion is a security risk only if all of the following hold: the target file does exist; that file contains sensitive data; the deletion fails for "some reason"; in the assumed attack model, the attacker can at some point access the contents of the file that was deleted, but, for some reason, would not have been able to access these contents if ...


0

The SunJSSE provider does not support SSLv2. It does support sending the first ClientHello message of the SSL/TLS handshake in SSLv2 format, though. A client sending the ClientHello message in SSLv2 format is useful if the client is ready to actually use SSLv2. However, since SunJSSE does not support SSLv2, it sends the ClientHello in SSLv2 format for a ...


0

Technically yes, there is a very minor data leakage vulnerability here. In your example: "aaaaaafooNfooaaaaaaa".replaceAll("foo([A-Z])foo", "user_input") if user_input contained $1 and the value of the above was output and the input string aaaaaafooNfooaaaaaaa was not user controlled, the user would be able to find out what the original "secret" string ...


0

You do not specify what version of Jboss you are referring to, or if you're talking about EAP from Redhat, or the Community Edition. The configuration is quite different from for instance Jboss CE 6 to 7. These are some starting resources for both EAP and CE: https://docs.jboss.org/author/display/AS72/Hardening+Guidelines ...


1

POODLE is a vulnerability in the SSLv3 protocol, specifically in how it handles padding for block ciphers (RC4, being a stream cipher, isn't vulnerable, but it has its own weaknesses). Do the client and server talk to each other using SSLv3? Can a man-in-the-middle attacker coerce them into talking using SSLv3? If the answer to either of the above ...



Top 50 recent answers are included