Tag Info

New answers tagged

1

Windows Credentials Yes, they are stored hashed within files in the c:\Windows\System32\Config\ directory. You will need the SAM and system files. However, a backup of these files may be stored in the Windows repair folder at c:\Windows\Repair\. If Windows is running and you need access to the locked files in the Config folder (for example you know the ...


8

Modern cryptosystems are generally not susceptible to known-plaintext attacks. In terms of encryption algorithms, there are basically 3 algorithms commonly in use in TLS: AES RC4 DES (in 3DES) All 3 of these are believed to be resistant to known-plaintext attacks, and have been well studied for such attacks. The one thing I would wonder about are ...


0

Analogy: As a locksmith, I may (with the customers' permission) keep records of what I've done for them, including the details of their keys. But that puts me at risk of having my own shop broken into and the list stolen (or an Evil Employee doing so) -- in which case the crook could make keys for many houses, and I'd be liable for not having protected this ...


2

Yes, Widnows saves users' passwords in 3 files: Windows\System32\Config\SAM file (without extension). Windows\System32\Config\SAM.sav: it is a copy of the first one Windows\System32\Config\SAM.log A transaction log of changes. To access these files, run Start/CMD and type %SystemRoot%then choose the subfolder system32\config. These files can not be ...


1

To access the windows passwords, you'll need both the SAM and SYSTEM file from C:/WINDOWS/SYSTEM32/config On a Linux Distro, like Kali-linux, you can then use the command "bkhive SYSTEM bootkey" to get the bootkey from the system file. Then, use the command "samdump2 SAM bootkey > samdump.txt" to get the hash dump from the SAM file. If you open the file, ...


0

All local user account passwords are stored inside windows. They are located inside C:\windows\system32\config\SAM If the computer is used to log into a domain then that username/password are also stored so it's possible to log into the computer when not connected to the domain. As for seeing which passwords are currently stored on a computer you can use a ...


1

@Travis Pessetto most likely has the correct answer to your question. I just wanted to point out that some places will do this without knowing your old plaintext password. This can be done by generating permutations of your new password and comparing each hash to your old password hash. Old Hash (Plaintext Unknown): ...


3

I just logged into cPanel and when I click to change my password it asks me for three things: My old password A new password Confirmation of the new password Screen Shot: It also says that the old password cannot be empty. This may not be exactly how cPanel does it but, it is a possibility: Since you have sent it your old password to cPanel it can ...


3

There is nothing complicated about building a tool to crack Diceware passphrases assuming you have an oracle, such as a hash of the passphrase, that will tell you when you have the correct answer. The cracking tool would simply loop through all possible combinations of up to n words from the Diceware list. It is also straightforward to estimate how long such ...


5

Assuming your server doesn't use any credentials besides system-level accounts and the MySQL password, there's one thing you need to protect: the swap file. Programs are supposed to take steps to prevent credentials from winding up in swap, but they don't always do so. There are some sensitive things in /dev and /proc (such as /dev/mem and /proc/kcore). ...


0

For hashing functions, no ready analogy finds itself in the sphere of football or automobiles. The best we can do is to spill the actual facts. Dear Boss, In a perfect world, users would be security conscious, and never use the same (or even a similar) password for two or more different sites or services. In that perfect world, a password would have little ...


1

It is stupidly simple to get around most sets of independently-evaluatable password complexity rules; minimum length, case requirements, non-alpha character requirements. "Password1", unless your name happens to be Joe Password, will get past most rule systems because it's at least 8 characters long, with a capital and a number. It's also the first thing any ...


0

You should NOT be able to determine if any user have the same passwords given the information in your database. It's just a security risk by design. If you really want to do something like that, at the very least please never tell the user the actual reason, just say something like "Your password is not complex enough" coupled with the generic ...


2

As @aviv pointed out, revealing to a user that some other user also has the same password is a problem. If you really intend to maintain such statistics, then you have another inherent problem: the "statistics engine" can only help any attacker, since it outputs a list of passwords that are in use. Even a reduced form which merely says "this password is ...


2

I dont think you want to do that at all... you will be giving hints about other user's passwords. If I get the message that 1 other user is using my password - now I have valuable information. I might even know or guess who that user is if I have some prior knowledge on him


2

A shared password is a poor design for managing access to a private communication channel. For example, you can't kick a user out without closing the channel: you can't cause them to forget the password. You can't prevent a user from sharing the password with other users (voluntarily or involuntarily) — if a user's password is exposed, you can invalidate it, ...


0

Analogy time: Storing plaintext passwords is like leaving your house unlocked. Encrypting the password database is like storing the key under the doormat. Hashing passwords is like using a 3-digit number lock shared by all users. Salting the password hashes gives each user their own number lock. PBKDF gives those number locks more digits. No one should ...


-2

The technical importance of hashing is vastly overstated. The practical reason you need to hash is because everyone else does it; it is considered "best practice". If you have a breach, it is much easier to defend a position where you are doing the same as your peers. Doing something different, even if it's the right thing, is much harder to defend. So I ...


0

Your logic isn't sound. "The password doesn't need to be hashed because many people will need the password." The second part of your statement is true and you've decided that that dictates that the first statement should be true. They're actually unrelated. Should the people that need the password get it from your server? Feels like they should get it ...


0

Generally speaking, you are right: given the keys 0, 1 and 2, it is possible to produce the encrypted form of any other file for the same password, even if the said password is not known. If you follow this road, you will probably be interested in Info-ZIP, a clean opensource reimplementation of the PKZIP format. Alternatively, you may want to recover the ...


4

The PUT HTTP verb is supposed to be idempotent, a smart word meaning that sending twice the request should not have any further effect. The idea is that a "PUT" command is the opposite of "GET": the data contents sent with a "PUT" are supposed to be stored at the specified URL, and may conceptually be obtained back from that same URL with a "GET". In that ...


1

Let's say your database with passwords is leaked or stolen: If passwords are in plain-text, all your password are belong to us. If passwords are hashed, all passwords are still in a shared bank-vault that must be cracked. If passwords are hashed and salted, each password is in its own private bank-vault.


2

It depends on your situation it's good practise to hash your passwords encase your database get compromised or your client's network thus allowing the attacker to gain access to any password he/she managed to gain. Advantages of hashing your password: Attacker will have much more to perform to gain access to private chat groups as he/she will require to ...


25

Personally, I don't see a reason why the password should be hashed, because when setting the password, it's absolutely clear that other people will need to know it. Then why bother storing the password at all, just let anyone in! ;) If you are storing a secret, it's because this secret identifies a subset of your total users. Not all your potential ...


5

Explain it in terms of lines of defense. Obviously, you're going to be doing everything you can to make sure that your code is secure. But the fact is, your server will not only run code that you wrote, and you have no control over the code written by other people. Even if all of the other code on the machine is open-source, you would need to hire another ...


4

The most fundamental answer, which I haven't seen anyone state directly yet, is that the actions of anyone who would be in a position to discover a password cannot be reliably distinguished from the actions of its rightful owner. If one wants to be able to prove that the rightful owner either performed an action or by his own action exposed the password to ...


27

This thread is a bit short on analogies, so here goes: An unhashed password is like a transparent lock, anyone who gets a proper look at it can design the matching key.


-5

What to tell the boss: "Here's the problem. I'm an experienced software developer and I'm telling you that storing unencrypted password is risky on a level of absolute inexcusable stupidity. Even storing unsalted passwords is risky on the level of gross incompetence. And I have just told you this. You can order me to store unencrypted passwords, and I will ...


3

Imagine you're Scrooge McDuck. You've been keeping your piles of money in one giant vault for a while now, but there's a problem with that: if a thief ever gains access to the vault, all your money will be lost in one go! That's no good. So, clever duck that you are, you decide to split your money up into lots of smaller piles and put each one in its own ...


4

Explain that passwords get stolen all the time, and when it happens the companies are REALLY embarrassed and open to lawsuits if the passwords are in clear text. Explain that hashing is really easy to do today. Now for the analogy: The best analogy of a one-way hash function to non-techies is just to just use a number look-up analogy - forget the complex ...


5

When you use an "authentication token", the simple presentation of that token by the client grants access (as long as the token is deemed valid by the server). If you store the tokens "as is" in your server's database, then an attacker who could get a glimpse at your database will immediately learn all the tokens, allowing him to send requests in the name of ...


7

Imagine you're the bouncer at a club. To know whether to let people in, you have a codebook of people's names/aliases (some people prefer to be discreet, and are only known by an alias) and their own private passwords; you can't recognize that people are or aren't who they say they are by their voice or appearance (there are too many people, and due to the ...


0

I use a small USB device of my own making that allows me to carry around a strong password "boost" on my key chain. Every password I enter anywhere is at least 15 random characters. For web sites I just tack on the first three characters of the web site domain at the end before I boost the seed to 15+ characters. Now, IF all web sites hash passwords then ...


12

Using analogies can be powerful, but in this case, I think it would be much easier to just explain in simple language what is going on. Something like this should be effective, but probably should include powerpoint slides with illustrations and large corporate fonts. As you know, we require people to use passwords so that we know who they are when they are ...


0

This depends on the strength of your password. Using Anti-weakpasswords data above, a password of 15 random characters has 62^15 = 768909704948766668552634368 possible passwords. At 40 billion tries per second, this is 768909704948766668552634368 / 40000000000 = 19222742623719166 seconds = 609549169 years = 6E8 years. This is basically unbreakable using ...


159

The Short Answer The short answer is: "So you don't get hit with a $5 million class-action lawsuit." That should be reason enough for most CEOs. Hashing passwords is a lot cheaper. But more importantly: simply hashing the passwords as you suggested in your question isn't sufficient. You'll still get the lawsuit. You need to do more. Why you need to do ...


8

All explanations so far are a bit long, here is a short one: Some people who can't remember their bank pin, keep a note in their wallet. If a thief or aquaintence would get to look inside the wallet they'd have a problem, UNLESS the pin is written in a way that only the owner can read it. Hashing is basically writing text in a way that only you can read ...


14

I like analogy as a way to explain technology, however in this case it's probably not workable as the analogy would be too complex. Most managers are more motivated to avoid personal risk to their position than doing the right thing, so rather than an analogy I'd use examples where storing passwords in plain text has reflected badly on a company. I'd just ...


4

How to explain. Humans are humans, it doesn't matter how modernized they are; there passwords will be something like Birth date or Name of the Girlfriend/Boyfriend/Pet animals etc etc. So, it is a threat to save password in clear text. Anyone can read it. Hashing helps to make them unreadable to humans (including loyal system administrator). Once a ...


28

To start off, I'll provide one to start with: Imagine you manage a bank. You don't want to allow your customers direct access to the money. So you have a teller who has just a computer and a small amount of money to deal with everyday withdrawals and deposits. He cannot access everything, nor can he pass secrets to the customer, because he doesn't have ...


3

This is an open research question, actually. It's a bit hard for users to cope with security advice; just like choosing strong passwords takes time, rationalising over password reuse does so as well. You're probably aware of The Compliance Budget and More is Not the Answer since you cite Herley. So, it's unlikely that a conscious security awareness program ...


1

When an application store your password it do so on your personal computer. This means that unless an attacker has physical access to your computer or unless your computer is compromised by a virus, your password is safe residing on your local machine. Browser are also programs that can store your password. Let's take chrome for example. If you go in the ...


1

As far as I know, Empathy is using the system's password storage capabilities (GNOME Keyring, KWallet etc.) to store the passwords for your accounts, so you may have to look into specifically how these tools operate. Which of them is actually used depends on what operating system and desktop environment you're running on.


5

one I like That is the bane of precise entropy calculations: human psychology. It is hard to quantify precisely how much the attacker can model your aesthetic choice. There are two extremes: The attacker may totally fail to guess what kind of password you like or don't like. In that case, your selection cannot be exploited by the attacker, and the ...


1

When a user is logged into a web-based application in multiple tabs, and changes their password should it automatically log them out of the other tabs? If a user is logged in using a cookie based mechanism then logging out of one tab will log the user out of all tabs. If they only change their password, then as they will still be logged into the session ...


0

When a user logs out or changes their password, it should revoke their session token, which is usually a hash that identifies them, like fc2904-92385-4jf9 The server should know that the particular session token is no longer good, and so if you have the application open in other windows, and you attempt to continue browsing, the server should reject all of ...


-1

Just ask for strong passwords, not P4$$w0rDsTh4TW1lLn3V3RbEr3m3mB3r3D. Away with the special characters, and just write long plain sentences that actually can be remembered. Calculate the entropy instead of forcing inane rules on the form. I will never remember the stackexchange password I just created. I will just trust the browser to remember it, which ...


5

You cannot know what tools exist. Actually, if the attack pattern can be enunciated ("just use three random words from a list of common words") then it can be translated to code in a matter of minutes. That the already-compiled, ready-to-run tool is not accessible from a single Google search and a couple of clicks does not mean that it does not exist, only ...


3

They're using id.avast.com as an authentication provider, not just an external database. So RCE doesn't get you access to it (assuming it's a different host machine), SQLi certainly doesn't, and since it's on a different domain (origin), neither does XSS. They've now significantly isolated their password hashes from the forum software. Using an ...


1

Don't worry, the sites don't need to store your old passwords. They simply need to store the salts and hashes of your previous passwords. So, even if their system was compromised, your previous passwords would not be revealed. As for why they want to make sure you don't reuse any previous passwords, that's simply in case any of your previous passwords were ...



Top 50 recent answers are included