I was looking for password encrypting method that uses 140 symbols encrypts.
Like the one i have right here
"1f06b3b57542c78b08d9b2c8cd14a44ff6de52eefa60284af778c2d02c7f35e8cb28b972a8a597ed949da8538f2f494cc5813bb500b595dab3e8575d01284e983d525a70eb61"
so can anyone point me into the right direction?
Or at least give some info about that kind of method (140symbols) .
It's not encryption, it's hashing. Most likely, the algorithm works roughly as follows:
1) Generate a 6-byte salt.
2) Generate the SHA-512 hash of the password and salt.
3) Output the 6-byte salt followed by the 64-byte hash as a 140 character hex string.
Related
I have two files:
one is a raw plain text file which is first compressed using ZStandard and then encoded with Base64
one is basically the same file but it is encrypted after the compression but before the encoding. I know the password used und have a 32 byte long salt.
Assumptions made:
I assume that the algorithm used is aes-128. Why? Because I actually have four files (two pairs) and the biggest common divisor of the two ciphers is 16, so I at least can assume a 128bit blocksize. And AES because it is the most common
The cipher is not generated using ECB since the same plain text results in different ciphers each time I let it generate.
I can provide one pair with its password and salt. I can also provide multiple pairs all with the same plain text if needed.
What is this for:
I am currently implementing a golang library to communicate with TeamSpeak 3 ServerQuery. It provides the possibility to create snapshots of servers and you can encrypt them using a password. I'd like to decrypt them with the password and the salt to parse and manipulate them.
I was not yet able to figure out, which mode is used with what IV.
I've tried many different possibilities including but not limited to:
Hashing the password using MD5 and using it as a key
Hashing the password with the salt using MD5
Hashing the password and then hashing the password hash and salt using MD5
Using the first half of the salt in the Key hash and the second half as a iv and vise versa
I am pretty much all out of ideas at this point. If anyone can just so much as point me in a direction would be appreciated.
MfG
I have a tcl/tk based tool, which uses network password for authentication. Issue is that, it is saving password in the logs/history. So objective is to encrypt the password.
I tried to use aes package. But at the very beginning aes::init asks for keydata and initialization vector (16 byte). So how to generate IV and keydata. Is is some Random number? I am a novice in encryption algorithms.
If you have the password in the logs/history, why not fix the bug of logging/storing it in the first place?
Otherwise there are distinct things you might want:
A password hashing scheme like PBKDF2, bcrypt, argon2 etc. to store a password in a safe way and compare some user input to it. This is typically the case when you need to implement some kind of authentication with passwords on the server side.
A password encryption and protection scheme like AES. You need a password to authenticate to some service automatically, and it requires some form of cleartext password.
You have some secret data and need to securly store it to in non cleartext form.
If you have case 1, don't use the aespackage, it is the wrong tool for the job. If you have case 2, the aes package might help you, but you just exchanged the problem of keeping the password secret with the other problem of keeping the key secret (not a huge win). So the only viable case where aes is an option might be 3.
Lets assume you need to store some secret data in a reversible way, e.g. case 3 from above.
AES has a few possible modes of operation, common ones you might see are ECB, CBC, OFB, GCM, CTR. The Tcllib package just supports ECB and CBC, and only CBC (which is the default) is really an option to use.
Visit Wikipedia for an example why you should never use ECB mode.
Now back to your actual question:
Initialization Vector (IV)
This is a random value you pick for each encryption, it is not secret, you can just publish it together with the encrypted data. Picking a random IV helps to make two encrypted blocks differ, even if you use the same key and cleartext.
Secret Key
This is also a random value, but you must keep it secret, as it can be used for encryption and decryption. You often have the same key for multiple encryptions.
Where to get good randomness?
If you are on Linux, BSD or other unixoid systems just read bytes from /dev/urandom or use a wrapper for getrandom(). Do NOT use Tcls expr {rand()} or similar pseudorandom number generators (PRNG). On Windows TWAPI and the CryptGenRandom function would be the best idea, but sadly there is no Tcl high level wrapper included.
Is that enough?
Depends. If you just want to hide a bit of plaintext from cursory looks, maybe. If you have attackers manipulating your data or actively trying to hack your system, less so. Plain AES-CBC has a lot of things you can do wrong, and even experts did wrong (read about SSL/TLS 1.0 problems with AES-CBC).
Final words: If you are a novice in encryption algorithms, be sure you understand what you want and need to protect, there are a lot of pitfalls.
If I read the Tcler's Wiki page on aes, I see that I encrypt by doing this:
package require aes
set plaintext "Some super-secret bytes!"
set key "abcd1234dcba4321"; # 16 bytes
set encrypted [aes::aes -dir encrypt -key $key $plaintext]
and I decrypt by doing:
# Assuming the code above was run...
set decrypted [aes::aes -dir decrypt -key $key $encrypted]
Note that the decrypted text has NUL (zero) bytes added on the end (8 of them in this example) because the encryption algorithm always works on blocks of 16 bytes, and if you're working with non-ASCII text then encoding convertto and encoding convertfrom might be necessary.
You don't need to use aes::init directly unless you are doing large-scale streaming encryption. Your use case doesn't sound like it needs that sort of thing. (The key data is your “secret”, and the initialisation vector is something standardised that usually you don't need to set.)
I have this password : cJU6fIvqSrHJq8ErBo0mU9fFjzPdSl/94iZyzX/VZ9RJ+GLm3PopuABNopq4UcqcMJTPOBu8KHadfcXl7DEE4Q==
and I want to know the used encryption type. I got this password with the salt from a database used by a script coded with symfony2.
the developer said that he used the sha512 encryption but I think that there is another encode method used.
Thank you,
you are right that there is further encoding, as this a base64 encoding of what is probably a hash output. the decode of the base64 string into a hex string is:
70953a7c8bea4ab1c9abc12b068d2653d7c58f33dd4a5ffde22672cd7fd567d449f862e6dcfa29b8004da29ab851ca9c3094cf381bbc28769d7dc5e5ec3104e1
which is odd because its 128 bytes/1024 bits long, compared to sha512 which is 64 bytes/512 bits. It may be that the salt has been appended to the hash or something like that. Compare your sha512 hashing with the above hex string and see if it matches some part of it.
Right now, this is what I am doing:
1. SHA-1 a password like "pass123", use the first 32 characters of the hexadecimal decoding for the key
2. Encrypt with AES-256 with just whatever the default parameters are
^Is that secure enough?
I need my application to encrypt data with a password, and securely. There are too many different things that come up when I google this and some things that I don't understand about it too. I am asking this as a general question, not any specific coding language (though I'm planning on using this with Java and with iOS).
So now that I am trying to do this more properly, please follow what I have in mind:
Input is a password such as "pass123" and the data is
what I want to encrypt such as "The bank account is 038414838 and the pin is 5931"
Use PBKDF2 to derive a key from the password. Parameters:
1000 iterations
length of 256bits
Salt - this one confuses me because I am not sure where to get the salt from, do I just make one up? As in, all my encryptions would always use the salt "F" for example (since apparently salts are 8bits which is just one character)
Now I take this key, and do I hash it?? Should I use something like SHA-256? Is that secure? And what is HMAC? Should I use that?
Note: Do I need to perform both steps 2 and 3 or is just one or the other okay?
Okay now I have the 256-bit key to do the encryption with. So I perform the encryption using AES, but here's yet another confusing part (the parameters).
I'm not really sure what are the different "modes" to use, apparently there's like CBC and EBC and a bunch of others
I also am not sure about the "Initialization Vector," do I just make one up and always use that one?
And then what about other options, what is PKCS7Padding?
For your initial points:
Using hexadecimals clearly splits the key size in half. Basically, you are using AES-128 security wise. Not that that is bad, but you might also go for AES-128 and use 16 bytes.
SHA-1 is relatively safe for key derivation, but it shouldn't be used directly because of the existence/creation of rainbow tables. For this you need a function like PBKDF2 which uses an iteration count and salt.
As for the solution:
You should not encrypt PIN's if that can be avoided. Please make sure your passwords are safe enough, allow pass phrases.
Create a random number per password and save the salt (16 bytes) with the output of PBKDF2. The salt does not have to be secret, although you might want to include a system secret to add some extra security. The salt and password are hashed, so they may have any length to be compatible with PBKDF2.
No, you just save the secret generated by the PBKDF2, let the PBKDF2 generate more data when required.
Never use ECB (not EBC). Use CBC as minimum. Note that CBC encryption does not provide integrity checking (somebody might change the cipher text and you might never know it) or authenticity. For that, you might want to add an additional MAC, HMAC or use an encryption mode such as GCM. PKCS7Padding (identical to PKCS5Padding in most occurences) is a simple method of adding bogus data to get N * [blocksize] bytes, required by block wise encryption.
Don't forget to prepend a (random) IV to your cipher text in case you reuse your encryption keys. An IV is similar to a salt, but should be exactly [blocksize] bytes (16 for AES).
I'm having an issue discovering what hashing algorithm is being used when inserting a password into a database, I have the password in the clear, and the hashed password itself, plus a salt, but I can't figure out what's going on in between (PHP developer, not .NET).
If anyone can help me out with what type of hashing has been used that would be ace.
The unhashed password: a77U3b3ovil#chee
The salt: 394279838
The hashed password: F80ADFC2175F9DB94745E6A9B8CFA575D5B94263C523F9249620BEC958026DB4
It's being inserted into an mssql database via ASP.
Your result has 64 hex char, so 64 x 4 bits = 256 bits in total.
That means that it's either
the result of a SHA-256 (but this is a recent algorithm that is not built in to ASP)
use http://hash.online-convert.com/sha256-generator to calc
the concatenation of 2 MD5 hashes
use http://hash.online-convert.com/md5-generator to calc
The output of SHA1, the default hashing algorithm of ASP.NET has 160 bits = 40 chars, so that seems to not fit well with the data you have.
On the other hand, there might be an application salt in the code (see):
computeHash( user.salt + "98hloj5674" + password )
and if you don't know that one, there's no chance to find your answer. Can you 'guess' it? You would need a dictionary attack (try all the possibilities) and the point of using hashes is just that this would take you years (for SHA-256) or hours (for MD5).
I've tried the obvious options (like sha256(Pass & Salt) ) but none of those worked. I'm afraid there is no obvious answer without access to the code.
See this discussion:
https://security.stackexchange.com/questions/3989/how-to-determine-what-type-of-encoding-encryption-has-been-used
and here's a page with a few encryption methods that you could run your data through:
http://support.persits.com/encrypt/demo_text.asp