Hot answers tagged

39

At least part of the hashing must occur server-side. Indeed, whatever the client sends to the server grants access, so if that very same value is just stored as-is on the server, then you have the same issues as plaintext password storage, namely that a single read-only glimpse at your server database gives all the accesses. In most cases all the hashing is ...


23

How login password hashing is supposed to work Note that in all snippets, I am intentionally excluding security features because I want to keep it compact. Do not rely on these code snippets for anything. In usual network applications ,that employ password hashing, is the user password hashed on client side before sending it to the server or is it sent ...


22

You can't make that assumption. Hashing occurs extremely fast, even a password that's salted, and uses a secure "slow" algorithm (or even chained set of algorithms) is going to return very fast (for humans). A ballpark estimate for using PBKDF2 with 10,000 iterations for each logon attempt could handle 100,000 attempts in a second (when only looking at ...


7

The simple answer is that it's not less strong. Encryption that's solely password-based is just as (in)secure as a equivalently-architected password-based authentication system.


6

The value of salt is not in its secrecy, it's in its differentiation and the added complexity. You've touched on this a bit. First, two passwords hashed with different salts have different resulting hashes. Therefore, an attacker cannot look at a password table and discover users who share the same password. Second, as you write, a rainbow table could be ...


5

To make it simple, if passwords are in plain text, the security would be compromised by anyone having a glance at it. Now, you need to remember that website log-in isn't the only access to a database. An attacker might be able to get some information from your database in various ways. First you need to know that it happens. And a hacker typically won't ...


5

In the case you constructed, even a 4-digit PIN would be fine. In fact, it's very similar to the iOS (and maybe Andriod?) PIN lock screen that wipes your phone after 10 incorrect guesses. No real hacker will try brute-forcing passwords against an application server, it's just too slow. Over the internet you can get at best what, a couple of hundred guesses ...


4

As has been said, it is theoretically possible but due to computational and storage limitations practically far beyond possible: Calculating a rainbow table for the entire hash space of an hashing algorithm is impossible as pointed out here. Not to speak of larger hashes like SHA-512 or SHA3. There exist rainbow tables for MD5 covering simple passwords ...


3

SANS first ran an article on the basics of what you are looking for -- a way to detect mimikatz on the network -- https://isc.sans.edu/diary/Detecting+Mimikatz+Use+On+Your+Network/19311/ However, remember that mimikatz is capable of Kerberos attacks -- https://dfir-blog.com/2015/12/13/protecting-windows-networks-kerberos-attacks/ -- as well as PtH attacks ...


3

To your first question: It depends on the application. In most cases, the password is sent to the server in clear text (and this is insecure if the application uses an unencrypted protocol, such as HTTP). The server, however, might store a hashed value in the database. If it does, the application calculates the hash value of the clear text password received ...


3

You seem to have summed it up pretty well. The only drawback I can think of is inactive users in your system - they will continue to have a previous work factor because they may never log in again, or may not have chance to log in before your next breach, meaning their stored password is more vulnerable to attack. As work factor is visible within the stored ...


3

As of today, bcrypt, scrypt and PBKDF2 offer reasonable properties to be used and considered safe. What is especially on their side is their history. As Neil pointed out in the comments, Argon2 - while winning the PHC - still has to prove itself, being researched extensively to be fairly sure nothing has been overlooked that can break its neck. That's the ...


3

Encryption software is often password based. Even if the adversary gets your computer they can't get the data without knowing the password, and bruteforcing is infeasible. Why is brute forcing infeasible? This mainly depends on the design of the system and of course the strength of the password. Encrypted plaintext that was encrypted with "password" is ...


3

The salt in a password just needs to be random enough so that its more or less evenly distributed. The salt is just used to make attacks with precomputed password hashes or rainbow tables infeasible by increasing the needed memory. Thus there is no need for a cryptographically secure random generator. This means that the implementation is secure enough in ...


2

Your assumption at 1. is incorrect. Consider an email system, where users log in with a password. In that case, the target may well be either the emails (which might be stored in a database, but equally may be in individual files, or mailbox files), or the ability to use the system. In this case, access to the database wouldn't provide either of those ...


2

I think you actually have two questions here: Why can passwords be used to encrypt data, but are less strong for authentication? There is not really a difference in security if you encrypt all data for a single user with the same encryption key or if you have some kind of secure storage and have some secure facility to authenticate this single user by ...


2

A key point is that you have the password hashes in your database so you do not have to re-hash the password. Lets say you have hashed them (correctly, with salt ect.) N times. To double your work factor you can rehash the hashes N more times in the database. And then apply this same rehash to logins in the future. See ...


2

I am a member of the thought police in a dystopian police state and I can eavesdrop on all internet traffic. Through my detective work I have found out that Bob is a thought-criminal. But Bob is outside of my grasp. I noticed that Bob used your program to upload several cyphertexts with the salts S1, S2 and S3 to your server. I also noticed that Alice, ...


2

It seems like the weakest link is the password since that is the only thing needed to decrypt the text, so users MUST create good passwords. I can't speak to most of the security decisions you chose, but I have some opinions on the UI: There's a potential for collisions of S. Why not have the client app query the server for S as part of step 2, and the ...


2

Why should I don't store passwords in plaintext? There are 2 main reasons: If a database dump is obtained, attackers can simply login with the plain-text password in the dump. If the passwords were hashed, the password would first need to be brute-forced. Lots of users reuse passwords, as bad an idea as it is, so your security failure could compromise ...


2

Generally yes, if you have enough time. If you know how long or in what format the salt is, it would help you. But the method is brute-force, as the any other hash-reversal: oclHashcat -m=0 b4fbb742bc2a24bc033dbfb4f4582e08 -a=3 userpassword?1?2?2?2?2?2?2 I didn't test that, but documentation is certainly good place to start.


2

A cryptographic signature can only assert trust on the data it is signing. Unless there's a way to validate the validity of the unsigned fields based on the validity of the signed fields, then no you can't trust the unsigned fields.


2

Your assumption is wrong. Cryptographic hashes are not generally designed to be slow. Quite the contrary, the most widely used hashes such as MD5 and the SHA series of cryptographic hash function were developed explicitly with speed in mind. They need to be, because they may be used to hash huge files or provide integrity check for internal file system data ...


2

You have got that wrong, at least the encryption. Asymmetric Encryption is done using public key of the receiver. Therefore it provides Secrecy (nobody without private key can not read the message). But it does not provide Integrity -- anyone can encrypt any message and send it to you with your public key. Wikipedia is a good friend: Digital signature ...


1

I suppose it depends on the circumstances. If you're running a Windows 95 machine on a dial-up connection to a webservice running on an overloaded Unix box from 1990, then yes I imagine it would take a second or two to return back a result. However, we are in 2016, where CPUs run in the GHz range, and internet speeds run into the MB/s. Hashing to a ...


1

It depends on how much entropy the salt contains. 32 bits? Sure. 128 bits, no chance in hell. Something in between, YMMV. Of course, the salt used MUST be available somewhere, otherwise you can't compare the password to anything. The salt is (generally) as much of a secret as the hash is, and normally stored in the same place.


1

First of all, they are three different concepts. And let me paste this block from the site you linked: Encoding is designed to protect the integrity of data as it crosses networks and systems, i.e. to keep its original message upon arriving, and it isn’t primarily a security function. It is easily reversible because the system for encoding is ...


1

Encoding is not a mean to ensure integrity. Encoding is here for representation. You encode a string into base64 because it is easier/safer to use the symbols in the internet environment, e.g. URLs where some characters are difficult to convey and interpret correctly afterwards. UTF-8 is used because we need a wide space to represent foreign language ...


1

As others have pointed out, the usual way for this to work is that the client sends the cleartext password, but over a secure channel (which uses reversible encryption, not hashing), and that password is then hashed server-side with the same salt as the stored hash. Client <----- Secure link -----> Server Cleartext password ...


1

No, this approach is not widely used and here's why: If the client hashes the password and sends this to the server, then doesn't that hash become "the password"? As an attacker, can't I just intercept the hash and use that in a replay attack? You said "A salt can be added also". This one actually is done in some protocols, when you add in a random value ...



Only top voted, non community-wiki answers of a minimum length are eligible