Ahh another question, sorry. With this cipher a "salt" would make almost no
sense since I already need a key?
or it make sense to put a "salt" together with the string to ecnrypt?

Thanks

On Mon, Jul 15, 2013 at 5:39 PM, Mariano Martinez Peck <
marianopeck@gmail.com> wrote:

--
Mariano
http://marianopeck.wordpress.com

Am 15.07.2013 um 22:42 schrieb Mariano Martinez Peck marianopeck@gmail.com:

That is up to you. That is what I was trying to explain to you. You always need a key/secret to encrypt. A salt is just a little more of information that diverses that outcoming value of a hash. A hash is a one way calculation from an input string to an output string in a uniform way. Meaning the same input with same algorithm is always the same output. One way to test a cryptographic string is using rainbow tables. These are big tables consisting of the outcome of hash calculations (fast compare vs. slow calculate). By adding a salt you make it harder to have these tables because you still need to calculate or need to expand the tables of results. But as a salt is an input to the hashing function it only works if the salt is included in the input and the output. Meaning you need to add the salt to the output. In the unix passwd file for instance the first two character of the password hash is the salt. You take it from encrypted string and encrypt the password with the salt to get the output you can compare with the encrypted string (the string with salt stripped off). So in any algorithm you can add a salt and prefix the output with the same salt. The difference between algorithms is how expensive they are to calculate. The best algorithm takes an awful time to compute. In this case if you send the right password it takes an acceptable amount of time to verify (one calculation) but if someone tries to brute force your password it will take way too long to make it feasible to try.
To encrypt something between two parties some information needs to be shared. If the algorithm use is shared you need to tranfer the password in cleartext to the second instance and the second instance can encrypt it the same way and compare. Sharing a secret between the parties you can transfer the encrypted string because the other part can decrypt the string and can compare the password (but you have to transfer the secret somehow).
In an asymmetric environment where there is a key pair where everything one key encrypts the other key can decrypt you just can share the other key to the second instance and you are able to transfer an encrypted string.
So whatever you do you need to decide what approach to use and what information is best to share. If you look on SSL you have everything in combination. First there is an asymmetric key exchange (expensive) that is used to exchange a shared secret. After the negotiation the network will be encrypted using the shared secret which is much less expensive saving CPU cycles.

Norbert

On Jul 15, 2013, at 10:42 , Mariano Martinez Peck wrote:

No. Salts (and one-way hashed passwords) only make sense when you're the one authenticating login credentials, not when you're the one tasked with providing said credentials.

There is no good way of securely "remembering" passwords for a client, other than (as Norbert said) restricting access to the place the password is stored using permissions.
As such, you could just as well store the password in-image, and keep it in a restricted location/run as separate user with access to that location.

Keeping a blowfish key in a separate file, used to decrypt some in-image value to get the actual password, only buys you safety against

1. Someone gaining access to the image, but not the file
2. Reading cleartext passwords from the process memory directly.

For 1), it should be obvious that it is mostly a moot point, if you place the image in a similarly restricted location anyways.
For 2), I think, no modern OS lets you read another users process' memory (on purpose *) unless they have root access/logged in as same user, in which case, well, you're already screwed.
Sure, there might be exploitable bugs that lets an attacker read memory of other processes, but such usually have a high fix-priority.
It also means, in order to never end up keeping the plaintext password in memory for prolonged durations (and vulnerable to being read), you have to re-read the file every time you provide the password, so the image must be run as a user with access to the files location anyways.

A usable alternative exists if you already use client-side credentials for your app, provided manually when a user signs in.
Then, in addition to salt + hashed password value for your users, you can store the db-passwords encrypted with a symmetric cipher (like blowfish) using the users password as key.
At login time, after authenticating, you then also decrypt the db-passwords, and keep them available while the application runs.
This of course, is still vulnerable to potential memory dumps, but you never store the passwords in an easily reversible form if an attacker ever gains access to the files.

If introduced to an existing application , it also means you'd have to keep the db-passwords around in plantext for awhile, to create encrypted values for users on first login (if non-existing), after that passwords should already be available in memory for calculation of new encrypted values when changing passwords/ adding new users. (due to those being allowed to do so, being logged in already)

If it's a non-deployed app, the encrypted value for some super-user can be calculated before deployment, and the data required to decrypt the db-passwords never kept on disk in production.

Cheers,
Henry

If you use OpenSSL (or any other crypto library) they provide secure
memory allocation that can be used to store sensitive data such as
keys, initialization vectors, etc.
You can even encrypt the data stored there. Once freed, that
allocation wipes the memory used.

Of course there would still be the case of the String/ByteArray in the
image or in method contexts when passed as arguments, for that there
isn't much to do except if you pass that "allocation object" as
parameter and convert it right to a String at the moment of using it,
or better, map it and pass it to another FFI call.

Also there is the risk of stack traces leaking sensitive information.
It would be convenient to have a "SecureString" that is never dumped
(and also has its secure allocation outside of the heap).

Depending on where you run your software, having a password in the
heap that is read from a file with the right permissions is all you
need.
I never needed to do any of the above, but I know some people that do,
especially for desktop apps. YMMV.

Best regards!

Esteban A. Maringolo

On Tue, Sep 20, 2022 at 11:59 AM sean@clipperadams.com wrote:

Ron Teitelbaum made a clever solution to resisting memory-scanning attacks
when using private keys in an image.  Upon asking KeyHolder holdKey:
yourPrivateKey, it forks off a while loop which generates a random sequence
of bytes (ByteArray) to encrypt yourPrivateKey with it.  It then delays
100ms, decrypts the key and immediately re-encrypts it with a new set of
random bytes (two new memory locations), and wiping the old random and old
key ByteArray's.  Repeat.

The result: a memory-scanner attack needs to find both pieces of
information (the random number and the encrypted key) in the image memory
within 100ms.  Obviously this consumes some processing power and garbage
collection, but it's not noticeable.  On shutdown, all instances are
automatically wiped, saved images are clean of private keys.

It's part of the CryptographyCore package on SqueakSource.

http://www.squeaksource.com/Cryptography/CryptographyCore-cmm.9.mcz

On Tue, Sep 20, 2022 at 9:59 AM sean@clipperadams.com wrote:

Chris Muller wrote:

Wow, that sounds really interesting! Probably overkill for my current use case, but happy to know that’s available in case I ever need it. Thanks for the tip :)