New answers tagged

1

In your specific use case, this assertion is faulty: ... suggested that a small digest is susceptible to rainbow tables and other attacks ... A rainbow table is only a lookup table of pre-computed digest values. Think of your use of a hash like the index at the end of a book, telling you what page number to read to find the real context containing ...


2

In practice it literally doesn't matter. If your key size is 512-bit (I'm not sure what cipher you're using, as none that I'm aware of use 512-bit keys, but whatever) then you've got two scenarios: In a small digest you've got so many collisions that discovering the original key by looking for matching values will give you a silly number of results. Not ...


4

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 ...


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 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 ...


0

My new found understanding: Two types of logons for this- one stores and one doesn't: Interactive logon occurs when a user enters their logon creds at boot, RDP, or other interface on the local machine. This logon type injects user’s credentials into memory as Kerberos tickets TGT, NTLM, LM, or plain text. This logon type is the primary security concern ...


-15

No, because your hashed password is just plain text anyways. The hashing takes place when you create the account, not each time you log in. If someone is using the same password as you then they will have the same hashed password as well, which is why many sites require complex passwords. Those plain text passwords will take about as long to retrieve as ...


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 ...


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 ...


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.


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 ...


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.


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.


0

There's another aspect to this discussion beyond the technical: if it is your design to not secure passwords, then you, as the service operator, are responsible and liable for them. Passwords are security measure for individuals. They aren't the property of the service. If passwords are properly secured (hashed, etc.), then the service operator has done its ...


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 ...


0

There is a slew of reasons you shouldn't plaintext store passwords. I'll go through some of them (since realistically you should only need ONE reason not to do it - it's not hard) travel - at some point your password has to be read from the database and that requires it to actually GO somewhere, having the passwords not in plaintext grants another level of ...


0

You rarely use encoding for integrity1. Encoding is used to transform some data in another format, usually because it is more suitable to the other system. For example, base64 is used because some systems may not react very well to some binary data. Encoding might only help you against transmission errors. (E.g. if the base64 data received contains an ...


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 ...


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 ...


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 ...


0

An attack based on simply resending captured data (e.g. a password that was hashed by the client) without needing to decrypt the data is known as a "replay" attack. The standard mitigation for this attack is to include what is known as a "nonce" in the hashed data, this could be a random number provided by the server, or a reasonably high-resolution ...


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 ...


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 ...


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 ...


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 ...


-1

I have learned a lot with this thread, so I thought in a way to easily understand the possible outcome when combined different methods (of course, it won't fit all cases): [W=weak, S=strong]: Formula | Example ---------------|----------------- W(W) = W | md5(sha1(pwd)) W(S) = W | md5(bcrypt(pwd)) S(W) = W | bcrypt(md5(pwd)) S(S) = ...


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 ...


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 ...


-3

For all intents and purposes you will only want to hash on the client side. The idea behind a hash is to prevent anyone but the user from knowing the password. As any good site should be using TLS, the fact that the hash is being sent to the server is irrelevant (Note that even if this was a concern sending the plain text password would be just as bad). ...


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 ...


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 ...


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 ...


1

I see no faults there. When using bcrypt, it's often actually a good idea to use a regular hash first, because bcrypt has a little known downside of being limited to only 72 characters of input. Using a hash before makes the input size effectively unlimited, while not reducing security at all. So not only do you get the extra strength of bcrypt, but ...


1

With this scheme you are certainly making an attacker’s life harder. Here is the general attack algorithm for cracking bcrypt-protected plaintext passwords: Obtain hashes (obviously) Generate candidate passwords for password cracking tool Perform the cracking attempt And here is the attack algorithm for cracking your sha1-hashed-than-bcrypted passwords: ...


0

To restate: your system has users with assigned IDs. You receive periodic location data associated with these user IDs in real time. You also have one (or more) clients who want to analyze your user locations. Each client needs to receive randomized tokens that each map to a user ID, and the tokens can refer to a specific ID for a period of no more than ...


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 ...


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 ...


0

Theoretically, yes, but you're going to run into storage limits. As an example, back-of-the-envelope math: Passwords of length: <12 Salt length: 32 bytes salt&password combinations: 6x10100 (~6x1088 TB). The total storage capacity of all computers on the planet is roughly 10 zettabytes, or 8x1010 TB, so good luck storing this table. I've also ...


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 ...


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 ...


0

Yes it would, but this is computationally impossible as of today. The salt technically expands your password by so and so random but known characters. You could therefore build a "salted rainbow table" with all passwords combinations up to n characters with, for each password, all salts of m characters (m is known). But this is not computationally feasible ...


1

Yes, there's fundamentally no security difference to what you are doing as the result will have the same "strength" of hash. Operationally though the two methods will return completely different hashes, which might a problem if you will be using this to authenticate to a different system. Appending the salt is the conventional way to do it, if you reverse ...



Top 50 recent answers are included