As part of an increase in the security measures for our company, we're moving to making sure all password logins (databases, servers, etc), are done through a password prompt and never using stored passwords. The hope here is that if a company laptop were to go missing, we wouldn't need to change all our passwords.
Is this really enough to assume we wouldn't need to change passwords? Is it not possible to recover passwords from memory or disk when they are typed in interactively?
This is a fallacy on several levels.
First, you can't expect people to remember passwords that are both strong and unique to each service. It's just not gonna happen. Implementing this is just begging to have "passwords.xlsx" pinned to half the users desktops (the other half will use "passwords.docx").
Second, trying to prevent password change is a move in the completely wrong direction. Instead, you should invest in a strategy that makes it painless to change passwords as often as needed or wanted and help users (including admins) manage these passwords in a safe and efficient way.
The reason for that last statement is that if there is one thing certain with passwords, it's that at one point, you will have to change them. An administrator moves on? Change all your system passwords. A manager used the same password for the corporate network as well as his son's football team forum? Change his password. Found a post-it the payroll admin stuck to his screen? Change his password.
Use single-sign-on whenever you can, provide a convenient password manager for your users, educate them as much as possible and make it trivially easy to change their passwords. That's the only way to make password usage in an enterprise less risky.
This is the wrong solution for this problem. First, no, it is not safe to assume that passwords can't be recovered from on disk or in memory. On disk is the real threat...If you're up against adversary who can pull data off of RAM, you're probably up against an adversary you can't defeat in any case.
Additionally, password theft is only one of the threats that you face with a stolen laptop. Sensitive data loss is another, and generally more serious threat. Your scheme does nothing to solve this problem.
So, the correct solution is full disk encryption. This protects all of the data on the drive of a stolen laptop, solving both of these problems with a single solution. It also frees you up to use whatever mechanisms are most suitable to encourage the strongest possible passwords without worrying about the additional trade-off of requiring that passwords never be stored.
When users are forced to memorizes a large number of passwords, they have a few options:
All of these options are bad for security. Most systems need a way to store user's passwords or values generated from these passwords (e.g. hashes). This happens for Windows (SAM files) and Linux (/etc/shadow) systems, for Databases and so on. If the passwords are weak, finding out the passwords behind the hashed/encrypted values is something relatively easy to accomplish.
On the other side, if a secure Password Manager is used, strong passwords can be used for each service and only one(or a few) complex passwords need(s) to be memorized.
A good approach would be to:
<ctrl> + v in a password and it will auto-type it for you, avoiding clipboard attacks (or attempting to reduce them).
Jan 22, 2015 at 16:22
OK, first we need to cover what makes a good password:
"Good" passwords are of substantial length and have the ability (often a requirement) to utilize special characters.
Why does the possible addition of special characters matter? By having more possible characters you have created a substantially larger set of combinations for each password.
Examples:
Passwords need to be 8 characters using lowercase letters.
There are 26 possible characters for each position, so 26^8 = 208827064576 possible combinations.
Passwords need to be 8 characters. Passwords may include uppercase, lowercase, numerals, and special characters.
26 lowercase + 26 uppercase + 10 numerals + 30(ish) various special characters = 92 possibilities for each character.
92^8 = 5.13E15 possible combinations!
So, we can see that by increasing the possible values for each character, we have substantially increased the power required to brute force these passwords.
Why does this matter here?
Simply put, longer passwords are harder for people to remember. As a result, people are more prone to write passwords down as well as reuse them. Therefore, in answer to your first question: No, you will still need to change passwords. People may report when they lose a company laptop, but may not tell the company if their wallet was stolen (with passwords written inside) or that their Yahoo account was hacked (which conveniently used the same password... but of course the company doesn't know this.)
In regards to your second question...
It depends, key loggers aside:
Let's assume the laptops have password encrypted drives.
If the laptop is turned off when stolen. you're fairly safe.
If the laptop is on, you're in trouble - regardless of whether the machine is logged in or not. A couple quick examples:
-Programs such as Cain & Abel could dump any passwords stored in browsers or on the local machine.
-Additionally, some machines with firewire could be susceptible to Direct Memory Access attacks which can leak contents of the memory. (Lucky for hackers, some firewire cards are Plug-and-Play!)
If the laptop is in sleep mode, the RAM retains just enough power to keep the memory contents alive. So any recently used passwords could theoretically be gleaned by "those with the knowledge of these things". (E.g. liquid nitrogen bath to the RAM and swapping it into an already running PC.)
If the laptops don't have encrypted drives...
-Whether the laptop is on or off, data can be pulled by another OS, allowing tools like Cain & Abel to potentially work some magic.
So, in closing:
***This typically doesn't have "much force" coming from the IT department. It's important that your company's executives/owners buy into this last point, understand it, and promote it company wide with their authority.
First off, Dinu S is correct that local machine passwords (e.g. the password you log into the machine with if it's not a domain login) have to have their hash actually stored on the machine. This requirement does not exist for accounts on domains or remote systems, though such systems may cache the password hash locally (Windows commonly does this with domain logins, for instance, so that you're not locked out of the computer if you're away from a domain controller.)
Beyond that, though, there's this nasty little thing that few people outside of security, file system designers, and computer forensic investigators know about: File Slack. Basically, this issue arises from the OS always writing an entire file sector to disk at a time - even at the end of a file that is not evenly divisible by a sector length. Presumably, this behavior is due to the design of the DMA engine or some similar consideration (or maybe the author of the file system driver was just lazy.) The result is that whatever happens to be in the RAM immediately following the end of the buffer that is supposed to be written to a file also gets written to disk after the end of the actual file data, filling whatever was left over of the last sector in the file. Reading the file via normal file read APIs will not let you access this data, but reading the raw disk sector data will. Forensics investigators commonly use this to recover information that just happened to be in the computer's RAM at some point. What data will be at the end of a given file is more or less random. It could be passwords that were stored in RAM (i.e. after reading from the keyboard, but before they got hashed and/or encrypted,) pieces of e-mails or documents, incriminating evidence, or anything else that ever gets stored in the computer's RAM. This was one of the especially important things we were taught to look for when I took a computer forensics course.
I should note that it's been a while since I took said forensics course, so it may be that modern operating systems actually overwrite the whole buffer that they're about to send to disk before sending it in order to avoid this issue. I'm fairly certain that there are at least some file system drivers out there that do this for security purposes, but I'm not sure how widespread their use is or which operating systems use such countermeasures by default.
I assume you are talking passcodes (generic passwords, unassociated with a user) rather than username/passwords because if it is the latter you would not have to change "all your passwords", only those of the user whose laptop was lost.
If a user's laptop is lost, all of their individual passwords should be changed.
If you are using passcodes, then they must be changed if a laptop is lost which used those codes.
The reason for this is that the memory of the computer is cached on the hard drive of the computer. This is called "virtual memory". By bad luck, the variable containing a passcode in clear text could be stored as part of this virtual memory on the drive and thus could be recovered.
