New answers tagged

1

You should provide the user with a message digest (ex - sha256) so that user can validate the accuracy and completeness of software. Digests are designed in a way that even a single bit flip in your application will result in a different digest. You can calculate the sha256 digest using following command on a mac machine (Tested on mojave) openssl dgst -...


0

I don't know what a "http digest file" is. If you mean a password validation database created with htaccess, then the format of the hashed password entries is very well documented, and is very unlikely to use a md5 function directly (it may use smd5). The point of hashing a password is to make it hard to recover the plaintext.


1

32-hex hashes are impossible to indirectly verify, programatically or heuristically. The only way to verify is directly - by actually cracking at least one. For future searchers, according to this Arch Linux page, ruTorrent password hashes are straight MD5, and not some kind of nested/truncated/salted variant: $ echo -n "tom:rtorrent:secret_pass" | md5sum |...


1

From a pure security standpoint, I see 3 possible improvements to your system: Using a slow hash like bcrypt. It is serveral order of magnitude slower than SHA-1. Your application won't be impacted, but it will take weeks for a motivated attacker to bruteforce every possible IP, instead of a fraction of second. Change the salt regularly. The attacker will ...


0

As others have said you should not be re-using your password however I would also add that you should not be re-using your id. If the creation is under your control then use something random for each one:- Server 1, ID: bluecanary81 Password: isoudi£&8r902)38rficsu78 Server 2, ID: tuliptop19 Password: uiouew893£*(2dferff$()_5 etc., etc. If the ...


1

GDPR requires reasonable protection of such data but does not totally forbid storing these data. Since the hashes are only stored on the server (where the attacker should have no access anyway and since the use case you have only needs short term storage and you can (and should) delete these hashes afterwards I see no real problem here. Even when the ...


2

As long as you are not storing IP addresses alongside other personally identifiable information, they do not have to be handled under GDPR rules. They only become sensitive when enriched with a user's name, email address, or any other such data. Just make sure that the systems limiting requests are separate from those handling logging in and user data, and ...


4

"Revealing a hash beforehand" does not mean the algorithm is broken. We call this a "commitment," and its a well recognized tool. However, that doesn't mean that an algorithm which uses commitments is not also broken. You have to analyze the algorithm. As an extreme example, if you were committing to a 6 sided die roll, and didn't use a nonce, then there'...


3

I used to use a browser extension which did pretty much exactly what you suggested. (It took my actual password + the URL of the site, hashed them together, and generated a password from that). It was great ... until eBay made me change my password because they had leaked their database. At that point, I had to remember which sites used one password, and ...


2

I'll only answer the crypto aspects of your reasoning; for discussions of the security implications of having a stateless master password, see other answers. Conceptually, your idea is good. It would be correct in the Random Oracle model, where hash functions have independant outputs for partially identical input. However, in the real world, our hash ...


2

I know the rule don't invent your own crypto/protocol, that's why I want to know if there exists a know protocol for a client securing himself? The problem you are experiencing in the Security Engineering space is known as the "Greedy Password" model. Each website you visit thinks it is the only site on the entire web, and they think it is OK to ask you to ...


0

The question you have to ask yourself is what are you trying to achieve ? You said you want to have a unique password, that you will hash with : Hash(Password + Service) the resulting hash, depending of the algorithm used (hint : do not create your own algorithm), will probably be 32 character long. The first problem is see is : what if the website does ...


94

You are trying to solve a problem that you shouldn't have in the first place: Password Reuse The concept is simple. You think of a "good" password and use that for everything. Your bank account, online shopping, your e-Mail provider, etc. The problem is, if it gets leaked by any one of them, then all of the other accounts are potentially in danger. This is ...


23

The established solution for this problem is to use different passwords for different websites along with a password manager. That way you won't have to reinvent the wheel. I know the rule don't invent your own crypto/protocol, that's why I want to know if there exists a know protocol for a client securing himself? Not every problem has to be solved ...


0

You would have to disassemble the BIOS image to be sure. Assuming you have access to a decrypted ROM image, you might get a head start by scanning for a block of bytes that are statistically random. You should expect to find a series of exactly 20 (SHA-1) or 32 (SHA-256) bytes. Then, if you can find a reference to that location, you might have a quick ...


2

An example of a cryptographic hash function is SHA256. An example of a non-cryptographic hash function is CRC32. A cryptographic hash could be used, for example, for a cryptographically strong Message Authentication Code (MAC, or, in practice, as a component of HMAC for key-based integrity) or as a component in an authentication encryption (AE or AEAD) ...


3

Assuming the input key is sufficiently entropic by itself, and both the input key and the identifier have a fixed length, you can safely use SHA-256 to derive extra keys. A fixed length is required to avoid length extension attacks which affect all non-truncated Merkle–Damgård hashes, including SHA-256. A safer way to do this, however, is to use HMAC for key ...


4

CD Key is a fundamentally flawed design. The software that checks the CD key validity runs on the user's machine, so it's running under the user's control. There's little that the software can do to protect itself from the user who knows what they're doing to bypass the check. There's little to gain for software vendor to deploy advanced security technique ...


2

What you are looking for is called a Key Check Value (KCV). You create a KCV by encrypting a block of zero bytes in ECB mode (the same number of null bytes as your cipher’s block size), then saving the first three bytes of output as a six character hexadecimal string, such as A1B2C3. In the future you can test a key by executing the same KCV algorithm; ...


1

For SHA-2, SHA-3, Skein, Blake2, etc. the password is the weakest link in the chain. There are two potential attacks on such hashes which allow user impersonation. Besides things like rubber-hose attacks, surveillance, and social engineering. Determine the password by brute force, guess-and-check Search for another "password" which produces identical output ...


2

What you're talking about is a zero-knowledge proof (or more specifically a ZKPP) similar to RSA-PAKE. If we ignore the general problems of implementing RSA safely, there are a few problems with the scheme you suggested: Since an attacker viewing the key-exchange knows c, if the value of ch is ever less than n then r = ch mod n = ch. From this the attacker ...


1

The short answer is "It depends", and most of the "depends" is based on the implementation details. But it also depends on what, precisely, you're attempting to achieve. If the goal is a simple security scheme where casual users can have a high assurance that they, and only they, can edit their own content -- with the understanding that the database ...


2

Blockchain database like Bitcoin works on essentially the same constraint and principle. So yes, it can be made safe. With that said, it's easy to get this wrong and unless you're doing something like a Bitcoin, there are often simpler and easier ways to achieve the same security goals. There are also lots of ways to make something that matches your ...


-4

tsk tsk, To try to secure a system via slow encryption is a fool's errand. For example, let's say the opposite, we have a hash, and we want to obtain the password (and salt if any). Even if we are to run billions of hash per second, we need a way to match the value. For example, let's say the next value: SALT:IT_ISASALT VALUE:123456 and it is the ...


Top 50 recent answers are included