We want to create a logfile at customer site where
the customer is able to read the log (plain text)
we can verify at our site that the log file isn't manipulated
A few hundred bytes of unreadable data is okay. But some customers do not send us files where they can't verify that they do not contain sensible data.
The only reasonable option I see so far is to append a cryptographic checksum (e.g. SHA256(SECRET_VALUE + "logtext")). The SECRET_VALUE would be something hardcoded which is plain "security through obscurity". Is there any better way?
We use the DotNet-library and I do not want to implement any crypto algorithm by hand if that matters.
You can use standard HMAC algorithm with a secret key to perform the checksum.
Using a secret key prevents in a simple way that the checksum can be regenerated directly. A hardcoded key could be extracted from code, but for your use case I think is enough
The result is a binary hash. To insert it into the text file encode the value as hexadecimal or base64, and ensure you are able to revert the process in server side so you can calculate the hash again with the original file.
You could use also a detached hash file to avoid modifying the log file
Target
customer readable logfiles
verifyable by our side
minimum of binary data
must work offline
Options
Public-Private-key-things... (RSA, ...)
would be secure
but only binary data
Add a signature
We are not the first ones with that idea ( https://en.wikipedia.org/wiki/Hash-based_message_authentication_code )
DotNet supports that ( System.Security.Cryptography.HMACSHA256 )
Key must be stored somewhere ... in source
Even with obfuscation: not possible to do so securely
Trusted Timestamping
again: we are not first ( https://en.wikipedia.org/wiki/Trusted_timestamping )
needs connection to "trusted third party" (means: a web service)
Build Hash + TimeStamp -> send to third party -> sign the data (public-private-key stuff) -> send back
Best option so far
Add a signature with HMAC
Store the key in native code (not THAT easy to extract)
Get code obfuscation running and build some extra loops in C#
Every once in a while (5min?) put a signature into log AND into windows application log
application log is at least basically secured against modification (read only)
and it's collected by the our error report
easy to oversee by customer (evil grin)
Related
We have a masked variable for example called SECRET_JAMES_BOND with value /vault/abc. During the pipeline execution, the log shows as [MASKED]. When we changed the value to ABCDE, the value was shown. Even we don't change it, we can easily get the value from the log if we perform SECRET_JAMES_BOND = $(echo $SECRET_JAMES_BOND) | base64). By echoing the base64 value, it will display on the UI because the value has changed. When we copy the encoded base64 string and decode it, we get the actual secret. How can we prevent a masked variable from echoing if its value has been changed ? Shouldn't masked variables show [MASKED] even the value is different from its original value ?
How can we prevent a masked variable from echoing if its value has been changed
In short: you can't if someone with access is determined to do so.
Masking is not meant to prevent developers with access to control CI steps from revealing secrets through jobs. It is meant to prevent disclosure by accident. There are endless ways that a value could be exfiltrated through the job output it would be impossible to cover them all.
If you wanted to prevent the base64 representation of the secret from being shown, you can register that value as another masked variable, but it must be done in advance.
Shouldn't masked variables show [MASKED] even the value is different from its original value ?
Good arguments could be made that GitLab should mask some common variations of masked variables, such as base64, url-encoded, backwards, etc. Other CI services (Travis CI for example) do this.
However, this would still be ONLY for the purposes of accidental disclosure.
For example, another way I've seen developers accidentally reveal secrets is by using curl with the -v flag.
script:
- curl -v https://myusername:${SECRET_JAMES_BOND}#myhost.example.com/secret
In the above example, the output of curl will show (in part) an output like:
> Authorization: Basic bXl1c2VybmFtZTpzZWNyZXQ=
So, if GitLab also masked base64 variations of a password, it would have prevented this accidental disclosure.
But like I mentioned, there's endless ways to output a secret: url-encoding, Caesar cipher, rot-N (rot16, rot24, rot32, etc) or even custom ways like just echoing each character one line at a time, potentially in reverse order.
So, really, you can only realistically prevent accidents, not malicious exfiltration by a user with access to execute code in a job.
I'm testing Yubico Yubikeys 5 NFC, in general, we use KeePassXC to save sensible information. KeePassXC accepts yubikeys but just one... Anyone know if it possible to add more than one to a kdbx file?
After talking to the KeePassXC dev team, it is clear that having two different seeds in two separate Yubikeys is not possible. You need to add the same seed to the other Yubikey to keep a copy of the seed.
In the Docs section, can we read this:
What happens if I break my YubiKey? Can I create backup keys?
You should always make a copy of the HMAC secret that is stored on the YubiKey and keep it in a secure location. This can be an analog paper copy, but since the YubiKey personalization tool allows you to program a custom secret into the key, you may as well program a second key with the same secret
Can I register multiple YubiKeys with my KeePassXC database?
You can only use a single secret for encrypting the database. So you can use multiple YubiKeys, but they all have to be programmed with the same secret (see question above).
and The explanation to how to setup the same id in slot 2 in two yubikeys is here:
https://support.yubico.com/hc/en-us/articles/360013779759-Using-Your-YubiKey-with-KeePass
Just remember in the second key you must copy & paste the same seed
The complete discussion is here: https://github.com/keepassxreboot/keepassxc/discussions/6344
Recommend to use a strong master password on top of the YubiKeys & save the DB regularly to generate new challenge/response pairs. Far from perfect but better than just a password. The following method (Challenge-response with HMAC-SHA1) works on Ubuntu with KeePassXC v2.6.2 and 2x YubiKey 5 NFC with firmware v5.4.3:
Install ykman (part of yubikey-manager)
$ sudo apt-get install yubikey-manager
Check that slot#2 is empty in both key#1 and key#2. You will be overwriting slot#2 on both keys.
$ ykman otp info
Slot 1: programmed
Slot 2: empty
Generate a base32-encoded secret seed (ex: "SECRETSEED") that will be programmed into both keys. RFC2104 recommends that your seed is as long as the underlying hash function (20 bytes for SHA1)
$ base32
SECRETSEED<Enter>
CTRL+D
BASE32SECRETSEED
$
Note that the above method adds a CR to the seed. Store SECRETSEED somewhere safe (ideally not digitally) in case you lose both keys
Program the resulting "BASE32SECRETSEED" to key#1 and key#2
$ ykman otp chalresp -t 2
Enter a secret key: BASE32SECRETSEED
Program a challenge-response credential in slot 2? [y/N]: y
Verify the same challenge gives you the same response using both keys
$ ykman otp calculate 2
Enter a challenge (hex): deadbeef
Touch your YubiKey...
aabbccdd11223344556677889900aabbccdd1122
Add one of your keys to your KeePassXC database
Database > Database Security > Add additional protection > Add YubiKey Challenge-Response
Both keys should now work to unlock/save your DB
Refs:
https://developers.yubico.com/Developer_Program/Guides/Touch_triggered_OTP.html
https://github.com/Yubico/python-yubico/blob/master/examples/rolling_challenge_response
https://wiki.archlinux.org/title/YubiKey
https://www.rfc-editor.org/rfc/rfc2104
I recently had to convert challenge questions and passwords for an OpenAM implementation.
The plan was to convert these values as part of the user entry in a LDIF file and load it. The attribute to complete is iplanet-am-user-password-reset-question-answer. This is a multi valued attribute to support multiple question/answer pairs.
The challenge question key, answer and question key and question status flag had to be combined in a single line delimited by tabs.
[question-key]\t[answer]\t[1|0]
The value needs to be encrypted. This was the class used to encrypt but it did not work.
AMPasswordUtil().encrypt(question.get(challenge) + "\t" + response + "\t1")
What to do to make this work?
Finally gave up and dropped ForgeRock support a question. They were very helpful and supplied the solution and it worked immediately. Here it is...
It turns out the AMPasswordUtil class should not be used. Instead this should be used
encrypted_str = AccessController.doPrivileged(new EncodeAction( clear_text_str ))
The encryption key needs to be set as a system property
System.setProperty("am.encryption.pwd", key );
The encryption key can be retrieved from OpenAM.
How can I safely store sensitive data online?
I want to store some extremely sensitive information online in a public folder, and I'm not sure how to go about it.
Specifically, I want to store bitcoin private keys in a .json file named "walletData.json" in a public folder. The file contains the wallet address and public key in plain text, along with an encrypted version of the private key.
Assuming anyone can access the file and attempt to crack the encryption password with their "super computers", what's the best way to safely encrypt that private key?
I know a longer password would be a good start, but ideally I don't want to need a password longer than 10 characters.
I was thinking of maybe hashing the password 1000 times, then using that hash+password as an AES encryption key. But, as everyone can see the key generation method, i'm not sure that will help? I was also thinking of padding out the encrypted private key with some other random data, but again, I don't know if it'll really help??
Is there a safe way to do this?
EDIT - after Reid's answer:
I'm trying to do this 100% in Javascript/jQuery.
When I export a CoinPrism.com wallet, I get this:
{"keys":[{"addr":"1PNLiLgW2fBokCB2wmfhZTtbmioitkqtMm","priv":"172655af193edeb54467a52fc6eb94c67eeeff8cd03555767e5cf12df694bb88f9c8b25c4019147d9e4993405274c96a","encryptionMode":"PKBDF2-SHA256","iterations":2000}],"salt":"2222b67fc7255aaf0b4027bfcabffb5e62f39e9e0aa13e8ad70f2dc75a484f26"}
The "priv" value is an encrypted private key. I don't know exactly how it's encrypted, but i'm sure that there's a way to decrypt it using just my 10 character password.
Does anyone know how they're doing this?
Is it safe to store this information online?
Well, I will just say outright that you don't need to be the one who writes the code to do this — it is far too easy to mess up, and your post makes suggestions that are concerning. (For instance, you describe something of an ad-hoc key derivation scheme, but one that is insufficient in protection.)
So, you need a library of some kind to handle this business for you.
My suggestion: Use GPG with the ASCII armor option. For example:
gpg --symmetric --armor --cipher-algo AES file.txt
This will symmetrically encrypt (--symmetric) a file (file.txt here) using the AES cipher (--cipher-algo AES) and store the resulting encrypted file in an ASCII armored format (--armor). Note: the resulting encrypted file will be stored in the filename plus the extension .asc; e.g., here, it puts the result in file.txt.asc. You can change this with the --output option.
Now, the above command will prompt you for a passphrase — this passphrase needs to be very strong, far more than 10 characters I'm afraid. This is the burden of passphrase-based encryption: you need passphrases that are strong. Ideally, you want a passphrase that is long and complicated, hard-to-guess and hard-to-bruteforce.
Since we are on StackOverflow, you may be looking to automate the passphrase entry (using scripting). To do that, there are several --passphrase related options for GPG. For example,
gpg --batch --passphrase "test" --symmetric --armor --cipher-algo AES file.txt
will use the passphrase test instead of prompting the user. Command line arguments are not safe, however, on a system, so it would be better to use the --passphrase-from-file option, which takes a single file as an argument. The first line of that file is the passphrase to be used.
I don't understand at the moment how countersignings work.
I'm thinking about is it possible to manipulate a file and resign it with the orginal key including a faked countersign?
I'm using e.g.:
signtool.exe sign /f "mycert.pfx" /t "http://timestamp.verisign.com/scripts/timstamp.dll" /v "MyApp.exe"
So will I get a signed application with a contersign. But how does that work? Does the "timestamp" server simple sign the current timestamp? If I understand right that would be allow a replay attack. So that I could sign a file in the past.
How is the contersign protected?
In your particular case it's not countersigning at all. The Authenticode timestamp is included as an attribute in PKCS#7 packet of the original signature. It's a signature (its digest) that is timestamped. The server signs the digest and the time value with its certificate.
Consequently there's no room (or sense) for replay attack - if you change the data, you will get different timestamp packet and if you want to replace older timestamp of the same data with the new timesamp, you can just re-sign and re-timestamp the data instead of playing with timestamps.