New answers tagged

2

There are tools to make builds deterministic. However it is not as simple as picking the correct language and compiler. You also have to eliminate all sources of non-determinism from the build. This mostly consists of time stamps and check sums. See https://reproducible-builds.org/docs/deterministic-build-systems/ for a more complete list of non-determinism. ...


0

The Boneh-Lynn-Shacham signature scheme works only in special elliptic curves that support efficient pairing computations. This is not something that you somehow add on top of an existing signature; it is a signature algorithm in its own right, that uses its own kind of public/private key pairs. If you want something that works with X.509, then you need a ...


2

Not just to keep an old thread alive but some people might have missed a important part of the long story behind this... It's been about an well known infamous and persistent bug when using /dev/urandom from Java versions 1.4 to versions 1.7. See the links below : http://bugs.java.com/view_bug.do?bug_id=6202721 ...


0

If you are using Java, shouldn't you be using the Java KeyStore? https://docs.oracle.com/javase/7/docs/api/java/security/KeyStore.html This class represents a storage facility for cryptographic keys and certificates. A KeyStore manages different types of entries. Each type of entry implements the KeyStore.Entry interface. Three basic KeyStore.Entry ...


1

I'm assuming that your threat model is an attacker gaining access to read files on your webserver via some type of web exploit. If not, you should question what exactly you are mitigating with your proposed encryption strategy. If it is, an option similar to 2 is probably the most simple. I would use AES128-CBC as the algorithm for a Key Encrypting Key. ...


1

Mongo database connections will be able to use SSL at some point in the future, but that isn't available yet. Writing to have a more recent reference for this one. From https://docs.mongodb.org/manual/tutorial/configure-ssl/ New in version 3.0: Most MongoDB distributions now include support for SSL. ... Certain distributions of MongoDB do ...


1

It's not about the practicality of the attack, it's about the habit of doing things securely. It's too common for bugs to creep in because someone thought about weither to escape that string or not, because "it's only numbers, so I can just ignore validating it". Then someone figures out how to exploit that. Using a cryptographically secure string ...


1

It cannot be determined out of context. One string comparison like this would be difficult to attack, as described in the accepted answer. The timelines are simply too short. However, context is essential. If a clever hacker can mold the rest of the code around this block to amplify the timings, they may be able to get somewhere. For example, if there ...


3

You're asking the wrong question. Worry is an emotion, and emotions should alert our minds to threats, but once alerted, we need to to think more deeply about what the threat is. It's often useful to measure one risk in comparison to other risks. The timing attacks on the equals method are real, and potentially exploitable, but you may have far larger ...


23

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


5

@Ben's answer to compare hashes rather than keys directly seems the best-practice approach for the task, and en passant also becomes a partial solution to the problem. However, it remains vulnerable to some level of rainbow tabled hash tree: try keys that result in a hash beginning with each letter, then those beginning with the found letter and cycling the ...


13

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


2

Are there examples of successful < 1ms timing attacks over the internet? What you might want to think about is if someone was attempting to discover the secret internally. Timing could be judged on a more accurate level from an internal perspective. If you are worried about such a situation, why not change the function to evaluate all submitted ...


32

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


0

HTTPS (HTTP over TLS/SSL) provides security over data in transit/data in motion it does NOT provide encryption on data at rest (Database, Files on a Hard Drive)-> Encrypted with AES, 3DES, BlowFish, etc. You can provide encryption on the Database, but not the whole database as this will eat up your resources (Encrypted Files are larger than Unencrypted). ...


6

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


2

HTTPS provides security for the transport layer only. It has nothing to do with the security mechanisms needed for the storage. You shouldn't crypt passwords. You should hash them, so you could not decrypt them later (nor an attacker). And the hash step is always done on the backend, since doing it on client-side would allow an attacker which got access to ...


5

You are confusing two things: transport security and database security. HTTPS using TLS only protects the transportation of the data from the client to the server. This means an eavesdropper does not know what client and server are sending each other (simplified). The storing of passwords is an entirely different topic. You want to make sure, that even if ...


2

Generally, most web servers running HTTPS do not require the client to have a certificate. If the server requires the client to authenticate, this is often done through credentials (e.g. username and password). However, the converse is generally not true - i.e. most clients DO require web servers to have a valid certificate signed by a recognized CA. It ...


5

Depends what you are doing, and what you want to verify. If you are accessing data, and want to be sure that the server which knows the corresponding private key is the one sending you data (e.g. you're accessing a web page), you don't need your own certificate. If the server wants to be able to verify that the client is a pre-defined one, which knows a ...


3

Depending on the block mode you are using, you can get partially decrypted data. For example, in CBC mode, if an incorrect IV is supplied, the first block of data will not decrypt properly. However, the rest of the data will decrypt successfully (assuming you are using the correct encryption key). This is because the IV of block (x + 1) is the ciphertext of ...


2

Some encryption algorithms require padding to ensure that the content is a size that is a multiple of the block size that the encryption algorithm intends to use. If your decryption process does not handle this padding, then it is possible to see in the result of the decryption there still garbled bytes appended to your decrypted message. Typically this ...



Top 50 recent answers are included