Tag Info

New answers tagged

2

I'd recommend reading the original paper on the Cold Boot attack. Section 6 explains "Identifying keys in memory." They wrote an app called "keyfind" that you might be able to search for.


3

It highly depends on what software you're using to manage the keys. For example, the proprietary crypto library we use here splits the key over several memory locations, flips them big-endian / little-endian, etc and only reassembles them when they're needed. Any good crypto / key management tool will have its own bag of similar obfuscation tricks. This will ...


0

Yes, you are right, all it does is it moves the issue to another place. There are several ways to protect the password of the Keystore using PBKDF2. Using a password that is needed at start up of the application server(as you mention). Composing the password of PBKDF2 out of 'things' you know about your deployment environment; for example: concatenating ...


1

Am I right thinking that it is NOT relevant for the tokens based on mathematically reversible cryptographic functions? You're right. But you may not want to do it that way. Tokens are generally isomorphic to card numbers (15-16 digit numeric) because they are supposed to be able to easily replace card numbers in whatever software the recipient uses. ...


1

If you're doing this to avoid entering passwords, then that implies that either you'll run an SSH agent on Production, or you'll keep an unencrypted private key there. If it's the latter, then the administrators of Production will have access to your development box. But if I'm reading between the lines correctly, you're using this approach as a workaround ...


1

Tracking down the links referenced in the answers, I think it would be safe. Out of an abundance of caution, I will exclude the private key from the list of md5sum values I allow to be stored on computers connected to the Internet. I will then use the signatures generated for the same binary to confirm the excluded private keys are identical. Even if ...


0

Although it is only the collision resistance property of MD5 that has so far been compromised, I would not use MD5 for any cryptographic purposes even though in your case an attacker would need to compromise the pre-image resistance. Use a secure algorithm such as SHA-256.


1

Looking at your comment on @zedman9991's answer; if you want to check that the servers' filesystems are identical, why not generate one hash for the whole filesystem, rather than one hash per file? This will likely fail on two different severs since operating systems generate files like candy, timestamps / MAC addresses will differ, etc, so it might be ...


2

In some cases it might actually compromise the security of it. http://www.di.ens.fr/~fouque/pub/crypto07b.pdf HMAC-MD5 has a key recovery attack in the upper end of achievable but impractical, although attacks only get better over time.


2

You can use the MD5 cryptography hash without any serious concern but why not consider using the public key to confirm the private key in question. You could have the partner sign a sample binary and use the public key to confirm the signature and thereby confirm the private key. If you want to work outside the signing infrastructure you could use a ...


2

WARNING: Creativity ahead, which is often bad for security (at least without thorough review). This sounds like a case in which an SSH agent could be useful. An SSH agent provides a socket interface over which SSH clients can ask the agent to perform key operations for them, which enables the following common uses: You can have the long-running agent ...


4

1: Use hardware tokens, like a Yubikey configured for challenge-response based authentication. Or smartcards. You load up the key on them all and hand them out. They're designed to keep the secrets secret. 2: Stop using a single key, start using one keypair per user for accountability and practical revocability.


0

Well besides the sudo answer (which is really clever btw), another solution is a restricted shell. In this case you would have to write one. In this case the only commands you need to accept are "ssh <hostname>" and "exit" so it's not so hard. I'm really only posting this for completeness, but the general technique is valuable in other contexts.


0

The reality is if other processes can access your process memory or features of your virtual machine, the game is probably over as your already compromised. If a process has access at this level, it can probably gain other information, such as the initial credentials used to authenticate prior to obtaining the token or just modifying results to make token ...


0

It's no possible to distribute a software to clients that can connect but cannot be impersonated. You can make it hard by obfuscating the key, but never impossible. With this in mind, I'd pick: Use TLS with per-client keys (signed by your own CA). If a client misbehaves, you blacklist their key and move on. No-one else is affected. If a key gets filtered, ...


1

Yes, it is insecure to use http instead of https because it can be attacked by man-in-the-middle, by DNS spoofing or in other ways, so you get the wrong key and also wrong software. Checking the fingerprint of the key would not help either unless you got the fingerprint by https. And while it would be better to use https, it would not mean that TLS ...



Top 50 recent answers are included