Stack Exchange Network

Stack Exchange network consists of 175 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Visit Stack Exchange

New answers tagged

0

As was mentioned, getting exact number of hashes per second is impossible, but some benchmarks should give you an idea of scaling if the coolling and other variables are equal or adequate. Now I would avoid mentioning precise numbers and keep in mind that while comparing NVIDIA RTX 2060 and 2080 sgould give you a decent idea, comparing NVIDIA and AMD or ...


2

If you hash the google ID you must then rely on the hash function having no collisions, also as you need to use a plain hash like SHA256 not a salted hash like Bcrypt2, because for lookups you need a hash that can be repeated with zero information. For passwords you want a salted hash like Bcrypt2 to prevent rainbow-table attacks. Hashing the google id (...


1

No. The secret is password, not user ID. Hashing any user IDs has no sense. Furthermore, is seems you store hashed Google passwords. It makes no sense. Normal users will not tell you (your application) their Google passwords.


1

While the above answers do raise some valid points they do not seem to be entirely correct and it should be noted that there do in fact exist weaknesses in certain hash functions that make a significant difference in the cracking speeds for "$pass.$salt" or "$salt.$pass". See for example md5. According to atom (https://hashcat.net/forum/thread-8365.html), ...


68

The password hashes for MS Office 97-2003 are vulnerable to collision attacks https://hashcat.net/forum/thread-3665.html). That is, multiple passwords exist that should be able to open the document. That also means that the password "iemuzqau" is not necessarily the original password that was set by the author. It is just one of the passwords that should be ...


0

You give very little detail on the amount of security you need, but I think you are overdoing it. I'd do a smaller token, maybe 64 bits, with good randomness and then just limit the repetition rate with which clients can present you said links. Assuming you create some thousands links per group (say, for example, 50.000) and that you limit the tests to 1 ...


25

Many recommendations for storing passwords recommend hash(salt + password) rather than hash(password + salt). Those recommendations are evidently bad, because what they should be telling you is to use a password hashing function that's been specially designed for the purpose, like (in rough order of newer and betterish to older and worse-ish): Argon2 (best)...


2

ThoriumBR answer provides a neat solution about how a system with the desired properties could work. However, it is quite crude for the students. You would ideally want an application built upon that that abstracted all the storing prior versions and applying the patches. Rather than creating a new program for this, I would encourage using a version ...


0

The premise is wrong You are asking how to generate a common salt, but not why you want to salt the email hashes. You salt passwords so that two users that chose "Password1" get different hashes on the db. However, here you are seemingly hashing unique values. In which case I see no need to save a salted hash. At least not when the client must be able to ...


34

Actually, you are tackling it the opposite way. It is true that doing hash(salt + password) would allow you to precompute the salt (but see note below) and only hash each password candidate for all those trials. The cost be the same you would bear if you were not using a salt at all. However, the goal of the salt is not to make bruteforcing a single hash ...


1

Yes, it can be done. You will need public keys and patches. Student A create original.txt, sign it, and send it to Student B. In turn, Student B checks the signature, edits this document, uses diff to create a patch, signs the student_b.patch and sends it along with original.txt. Student C checks all signatures again, and if they validate applies student_b....


16

Hash functions recommended for password use do not have this advantage - I'm not sure that any non-trivial hashing functions do, in fact, but wouldn't want to make a blanket statement there. Instead, hashing functions mix parts from the whole input in each stage. For example, given the input ABCDEFGHIJKLMNOPQRSTUVWXYZ, the first step could be something like ...


1

Sounds like you need the Responsible Disclosures method https://en.m.wikipedia.org/wiki/Responsible_disclosure in which a vulnerability is disclosed only after a period of time that allows for the vulnerability or issue to be patched So contact the maintainer of the package first , and allow them time to fix it before publishing your findings


1

Veracrypt is supporting multiple hash algorithms, which are listed in the documentation. It supports the following Hash Algorithms: RIPEMD-160 SHA-256 SHA-512 Whirlpool Streebog


0

Take this as a very long comment. I was curious how quick the stuff runs on my personal laptop (Thinkpad T460p, Intel i7-6700HQ). I know that for cracking salted passwords there are special devices, but if you have a web service you likely don't have special hardware for that. Evaluation results The default of werkzeug.security.generate_password_hash ...


1

The Argon2 spec gives very detailed information. How does one "figure out" how many threads should be used? If only one thread is used, is it unsafe? The maximum number of threads you want is the number of hardware threads on your system. A 4 physical core Intel CPU Hyper-Threading to give it 8 logical cores should be be running Argon2 with 8 threads. ...


14

It depends on how good the password is, and the size of the hash prefix. Large prefix / bad password If we assume this is a hash of an average Joe's password which contains say 30 bits of entropy ("mySuperSecretPassword123" almost certainly contains less entropy than this), and to be conservative we follow Kerckhoffs's principle and assume the attacker ...


51

Actually, it's as bad as a full hash leak. Hash-cracking is done by: Generating password candidates Hashing them Comparing the resulting hashes to the hash you want to crack None of those steps will be slower in case of a partial hash leak, so this is very similar to a full hash leak speed-wise. Please note that if the partial hash output is not long ...


4

If you only have half a 160 bit hash, then that means you have 80 unknown bits. This results in $2^80 = 1.2089258196146292e+24$ possible hashes left. That means that your password can be hashed to one of those, and that does exponentially reduce the number of possible passwords (2^80 times less), but an attacker CANNOT find your password only based on this, ...


0

Don't create your own custom algorithms. This is a trap that novices fall for again and again and again. If you do, you will fail, because you are not an expert. Good algorithms are designed by people who spent decades on this very material, and the results again are checked by hundreds of cryptoanalysts, trying to find any imaginable flaw. Your student, ...


0

Starting from PostgreSQL 10, the SCRAM-SHA-256 password authentication mechanism is included: To upgrade an existing installation from md5 to scram-sha-256, after having ensured that all client libraries in use are new enough to support SCRAM, set password_encryption = 'scram-sha-256' in postgresql.conf, make all users set new passwords, and change the ...


3

Your unhashed password ended up on their system because that's typically how authentication works, with credential information being sent to a server which then verifies it. It should never be an assumption or expectation you make as a user that your password is not available to the server. That is why it is typically considered best practice to use ...


-3

It's still true that hashes are one-way: A hash can be computed from a password, but the inverse is not true: a password cannot be derived from its' hash. So logically, that leaves us with only one possibility as to how Google came to capture their users passwords in clear-text: they were NOT being hashed BEFORE transmission. Were Google to have only ...


1

The jumbo version of john has a --list=format-details option. By default, it outputs one record per hash type for all hash types, with tab-separated values of a variety of information about that hash type (maximum password length, long name, etc.). You can also specify a hash type. So for a specific hash type: $ john --list=format-details --format=descrypt ...


1

If an attacker is able to extract hashes from a database, they might sign up with the service so their password, pass123, is put through the hashing algorithm and inserted in the database. This would allow them to try common hash functions and determine how the hash is being obscured: Database hash 32250170a0dca92dfafe46b853ec9624f336ca24 SHA1 (pass123) ...


2

What you're proposing is almost completely pointless, and probably counterproductive overall. It will protect you against some automatic scans that just look for standard formats, but not against someone who takes a few minutes to look at your system. It won't increase security I'm aware of that, but I believe it can make cracking the hash much difficult. ...


3

You have basically created a custom hashing algorithm. If no one knows how your algorithm works and no one knows that it is trivially based on MD5, then it will be extremely difficult, if not impossible, to crack this hash. So, to answer your question directly about the hash, it is likely going to be uncracked without further knowledge. The only real ...


Top 50 recent answers are included