The Unspoken Taboo - The Never Expiring Password 537
anon writes "Every security savvy professional lives with the daily fear of the "never expiring password" being exposed. It's the unspoken taboo, the wide open back door in every corporate network. But no-one ever acknowledges it or discusses it. All applications have got pre-defined passwords that never change. Which means developers, privileged users and hosting third party service providers will all have access to these passwords."
I hate to do it.... (Score:5, Funny)
Re:I hate to do it.... (Score:5, Funny)
Re:I hate to do it.... (Score:5, Funny)
Re:I hate to do it.... (Score:5, Funny)
Another +5 funny could have been milked from that joke, but noooo, you had to ruin it and skip a line.
This ain't Soviet Russia ya know.
Re:I hate to do it.... (Score:3, Funny)
Re:I hate to do it.... (Score:4, Funny)
Re:I hate to do it.... (Score:2, Funny)
Re:I hate to do it.... (Score:3, Funny)
Re:I hate to do it.... (Score:3, Funny)
Never mind, I don't want to know!
Re:I hate to do it.... (Score:5, Funny)
tech support: what's your password?
user: ******
tech support:
user: really, it's ******. now you don't even know if i'm really stupid or really smart.
Re:I hate to do it.... (Score:3, Informative)
Re:I hate to do it.... (Score:5, Funny)
guilty (Score:5, Informative)
Re:guilty (Score:5, Interesting)
I am not a cracker or hacker. But I know a guy who uses password trading websites for porn. According to him, once you get a password for one porn website, that same password will work for others. According to him, these porn members use the same password for all sites they subscribe to.
Once companies start losing money to crackers/hackers, then they will start issuing more complex security.
Re:guilty (Score:5, Interesting)
Re:guilty (Score:4, Funny)
Drum roll please, Anton...
10. Wank
9. Jerk
8. Milk
7. Yank
6. Spank
5. Rub
4. Beat
3. Whack
2. Jack
1. Off
Re:guilty (Score:5, Informative)
SELECT COUNT(pass) AS count, pass
FROM `users`
WHERE expired = 1
GROUP BY pass
ORDER BY count DESC
| count | PASSWORD |
| 1322 | password |
| 994 | 123456 |
| 824 | 12345 |
| 569 | harley |
| 536 | 696969 |
| 434 | mustang |
| 385 | qwerty |
| 355 | baseball |
| 307 | football |
| 305 | hunter |
| 305 | letmein |
| 296 | shadow |
| 294 | pussy |
| 279 | maggie |
| 276 | monkey |
| 265 | golfer |
| 260 | buster |
| 260 | 12345678 |
| 255 | bandit |
| 241 | nascar |
When a site password is compromised, the system automagically sets a strong password, and notifies the user. They get rather upset about that. I tell them, "You should have used a good password to start with." We will let them change it back to something else, but we won't let them use anything easy.
Re:guilty (Score:5, Insightful)
never keep the passwords as plain text fields, if someone hacks your server, gets the password and then abuses the matching password on their bank accounts/(or elsewhere), you will be the dumb lamb that will be sued for letting their secrets out.
encrypt passwords and be safe, an ordinary md5 gives you more than enough for now.
i'd get my ass fired if someone would discover that i even considered saving passwords as plain text.
ps. for the password story itself, on a windows platform which is terrorized by zillion spyware items, i suggest you never change your password, as the spybot authors know it before your disk synchronizes the changes to disk (keyloggers, blah
Storing passwords (Score:3, Interesting)
No. First of all, why use an insecure hash function when a more secure one is just as convenient? MD5 should no longer be recommended for any use. Second, you have to salt before hashing. Thirdly, it's a good idea to iterate the hash function at least a few thousand times - this makes a dictionary attack computationally more expensive. This is all "key stretching" as described in Schneier et al's paper on low-entropy keys.
Where passwords are used for n
Re:guilty (Score:3, Insightful)
Even if you do really have a need to keep the passwords around for recovery, that is still no excuse to store them unencrypted in the database. It's big time amatuer hour, and I agree with the GP who calls it grounds for being fi
Re:guilty (Score:3, Informative)
You can't reverse a hash. That's the problem. The hash is like a fingerprint of the data, not an encrypted version of the data. You can compare hashes to see if they're from the same original data, but you can't take the hash and find the original data (recent Slashdot story aside).
So, if you want one of those whiz-bang features like password recovery, it has to be encrypted or encoded, not hashed.
Re:guilty (Score:3, Insightful)
Well, by the time it hits anywhere that is relatively public, it's encrypted in some fashion. Since most places need to be able to do a password recovery, it has to be in something more open than md5. People get all pissy when they can't get their password back when they forget it.
Why not just reset their password to something random, like everyone else? You aren't doing anyone any favors by storing their passwords as plain text.
First principle of security vulnerability (Score:5, Insightful)
The first rule of evaluating security vulnerability should be this:
There are ate least three clear optimistic assumptions in the very first clause of the sentence I quoted partially. (1) That you can rely upon demarking "public" and "private" places. (2) That your organization can trust completely people inside the security perimeter (e.g. you just published a rather nice guide to cracking passwords at your employer). (3) That the users in your organization should trust the organization and employees inside the security perimeter. An example of the first would be a sql injection attack that causes the password table to be dumped.
You should secure secret information as early in the process as humanly possible. This means that passwords should never be stored in a database. If I could convince people it was worth the effort, I'd avoid sending plaintext passwords at all over the wire, and I would avoid sending unencrypted password equivalent hashes as well.
Since most places need to be able to do a password recovery, it has to be in something more open than md5.
I disagree. There's seldom a reason to do password recovery, especially in a system that can tolerate a "super user" administrator who can assign privileges to any object or reset passwords to whatever he likes. In systems that can't tolerate this, then users can reasonably be required not to lose their passwords, biometrics and security access tokens.
People get all pissy when they can't get their password back when they forget it.
Well, I don't see why: "OK, I just set your password to 19651001 -- your birthday. After you log in, you should change it to something you'll remember." What they should get pissy over when you can amass a file on how they choose their passwords.
So, no security whatsover? (Score:3, Informative)
The first rule of password security for me is that there is no way to retrieve the password from the system. If that cannot be done then you have no security at all.
Relative Password Security Importance (Score:3, Insightful)
Re:maggie (Score:3, Insightful)
Only member of the Simpsons family with a name long enough for most password schemes (at least 6 characters)?
Seems reasonable enough to me.
Re:guilty (Score:4, Informative)
Some sites allow users to select their username, some don't. Some set arbitrary passwords, some don't.
If you're real lucky, you may find a combination like "user:pass". But why should anyone think someone who has the username of "bullshit" has the password of "my_password", and everyone who's chosen the username of "bullshit" would select the same one.
We've had many users complain that their username was taken. It's always funny too, on common first names, or something simple like that. How many username "bob" can there be?
More than likely, he's finding multiple sites in the same 'family' of sites. I've seen that happen before. Buying a membership at one site will allow access to many, usually because they use the same password file on the same server.
The password sites do work though.
I've become very familar with passwordz sites over the years. We were hit pretty hard when we started doing one of the largest on the Internet. We have a bot who builds pretty interesting reports for us, and I had included the sites which we were linked on.
Most people are using something like 'AccessDiver'. Many sites now set firewall rules against IP's using those tools, start showing them a bogus valid login page, or any of a number of tricks to mess with them. I know some of the 'hackers' were using multiple proxies after a while, but really, when you have to do tens of thousands of attempts to even think you're getting one password, how many proxies could you possibly have at your disposal.
When we see x number of attempts come in from an IP, it gets blocked. If we see that a valid password was acquired in the attempes from that IP, we automatically change that password, and notify the user. We have a few other tricks too. I very rarely see our sites showing up any more, simply because by the time they get a password posted, it's no longer any good. It does the same thing to the casual 'hacker', so if you start scanning through multiple proxies and leave for a while, when you get back, you still won't have a good password.
I use hacker in quotes above, because they're not real hackers. They're barely crackers. I classify them with script kiddies. They found a tool, run it, and now they've accomplished something with no work. They don't know how it happened, they just know it did.
Re:guilty (Score:2)
That's good to know. Thanks.
Re:guilty (Score:4, Insightful)
Re:guilty (Score:4, Interesting)
Re:guilty (Score:5, Funny)
All of this takes place behind a triple-secure double-blind firewall, inside a bunker which is encased in twenty-three feet of reinforced concrete and surrounded by a moat with biometrically activated piranhas.
Re:guilty (Score:5, Funny)
Sadly, I am guilty of this as well.
He wasn't kidding, folks!
The most dangerous? (Score:5, Informative)
--
Evan
Potential Trump (Score:3, Interesting)
Trojan horses -- the definitive answer [google.com]
My favorite quote from Dennis Ritchie:
"I promise that no such thing has ever been included in any distributed version of Unix. However, this took place about the time that NSA was first acquiring the system, and there was considerable temptation."
Yes, that one had definite potential for abuse. How's your favorit
Oh no! (Score:5, Funny)
Re:Oh no! (Score:4, Interesting)
I always like this.. A good locksmith would know how to pick the lock. A smart locksmith would have noticed that you leave your downstairs window unlocked.
My father used to tell me, locks are for honest people. I agree.
Several times, in nicer office buildings, I've found myself locked out of offices where I should be allowed. They use a special 'security' key, which is one or two tumblers longer than a regular key. I've opened them in about 10 seconds with a car key and a credit card. Sometimes I've found it easier to just pop the drop ceiling out, and climb over the wall too, assuming there is no firewall between point A and point B. Usually inside offices don't have them.
But, when it comes down to it, if I wanted to get into your house badly enough, I'd just kick in the door. I have yet to find anyone who uses a New York deadbolt other than me.
I went to a "secure" facility a few weeks ago. I was inside a 'mantrap', waiting to be allowed through. I started laughing at the guard, after he took too long to let me through. The guard didn't understand why. Their "security" guard was behind 2 inch thick security glass. The frame around it was steel. The door had steel bars on it, and a pry guard. He pointed all of this out to me, and I laughed again.
Someone had swung the door open too far a few times, and knocked a grapefruit size hole in the drywall. I knocked on the wall right under the bullet proof window. It was just more drywall. I then asked "What would happen if I shot through here? What would happen if I knocked a hole in the wall, and put 12v to the door latch solinoid? I would be in, and no one would find you until shift change."
Ok, it could have been other voltages, I was just screwing with him.
Ya.. There aren't too many places that are really 'secure'. It's simply a matter of how much risk a person is willing to accept in the entry to said facility. In the above case, it was easier to ask "will you please open the door now?" He stopped giving me grief every time I came through. He already knew I was authorized.
Re:Oh no! (Score:3, Interesting)
As someone who used to cut keys for duplication, this is not really true. First, 90% of the door keys I cut were one of two blanks: sc1 (Schlage) or kw1 (Kwikset). While they were supposed to keep an eye on blank inventory (we sent back "bad cuts" for credit), that was unrealistic for the most common models; they ship you the keys by weight, not by nu
Security Guy (Score:4, Insightful)
All applications have what? (Score:2)
Huh? What applications have these?
Re:All applications have what? (Score:5, Funny)
Solitare, Minesweeper, Frogger.
Re:All applications have what? (Score:2)
Re:All applications have what? (Score:2)
Huh? (Score:3, Insightful)
!seineew (Score:5, Funny)
Write your changing password on a Post-It (Score:5, Funny)
That's not much of a protest! (Score:2)
Re:Write your changing password on a Post-It (Score:3, Insightful)
Actually, the top dogs are the worst. Not only are the passwords simple, never change, and are written on post-its, they also tell me in idle conversation while I provide deskside support that it is the same password for their banking and stock websites. If only I wore a different hat. . .
Growing a little less true (Score:5, Insightful)
SOx is horribly aspecific, and boils down to "you'd better be doing the right thing". The irony of audit company failings leading to an audit company boom aside, that means auditors are scared, pedantic and detailed. In the case of our auditors that includes frequent, documented changes to passwords for both human and machine users, including all applications and components thereof. It's been a pain to implement because people have been used to systems working as TFA states. It's also quite a resource suck to go through each password change cycle. But doing so is best practice that was ignored in the past for the sake of expediency, and now it's enforced with a big stick. As an IT professional, that's not entirely unwelcome.
Why is it "best practice"? (Score:5, Interesting)
I can understand mandating a security protocol for systems that protect information subject to privacy. But if I have a company, and the only thing on my computers is my company's design information, my company should be able to choose the appropriate level of security for our business.
Why is a password that a user has committed to memory that never changes worse than a password that changes every three months that a user has to write down?
Re:Why is it "best practice"? (Score:3, Interesting)
So? Compramising a password in my head requires telepathic access.
Since telepathic access is harder than physical access, wouldn't that make the memorized password more secure?
toot the company horn (Score:3, Interesting)
Configuresoft http://www.configuresoft.com/ [configuresoft.com] has some great software called ECM for managing continuous compliance standards like SOX, PCI DSS, HIPAA, etc. ECM is in use in 9 of the 25 biggest companies in the world. We even have clients on RedHat and Solaris.
That said, we see companies with the blank password problem all the time. We do compliance assessments (pre-sales) where we ask the CIO and IT management a question like, "How many of your servers have admin-level acco
Missing facts, or the truth? (Score:5, Insightful)
Are they sure about that?
So where is this wide open back door? In every one of your applications.
These guys are paranoid.
Tell me that Apache/Tomcat has some secret passwords that will give a cracker access to my server. Or MySQL has a secret password that gives root access. Every app I can think of can have passwords changed, and none have hard coded passwords.
This is much ado about nothing.
Ya sounds like a load of bull to me (Score:3, Insightful)
Re:Missing facts, or the truth? (Score:3, Funny)
What makes you so sure he's white?
Re:Missing facts, or the truth? (Score:5, Insightful)
The idea that instead of USERS having passwords, the APPLICATIONS do now. You can't just auto lock them out after a certain amount of time with no change, if somebody forgets to change the password, you're down. So you've got s3cr3t456 hard coded in the data source config of your app, who's gonna change that? You better have procedures in place, and you better keep that config file locked down since you have a powerful DB account password in plain text in your front end app server. Some vendors obtusify that password with what looks like encryption, but unless you've set it up right and enter a password each time you start the app server, it's still trivial to decrypt.
Another sticky problem is access to the data is no longer controlled by the RDBMS, since that application account needs wide open access. One security hole in your in house written app can trash any part the application could need to write to. If you use the security/roles in an DB you can restricted access to the data to a much finer level. Principal of least access and all... Unfortunatly, that's how things used to be done and in the land of middleware aren't anymore.
I wrote a custom data source for a servlet once that would auth each user using the account in the db and connect as them to the db. It really breaks how server side java is supposed to work though. One of the big ideas of J2EE is you're supposed to move almost all the logic that used to be data related in the DB up a layer into the middleware. It helps sun take customers from big DB vendors, but makes real world security much harder.
It's a sticky set of problems in todays world, with no widely accepted solutions.
Re:Missing facts, or the truth? (Score:3, Insightful)
I think you and the mods missed the point. So how does tomcat talk to mysql? Do you use a password? Trust the IP? Bind to 127.0.0.1 or Unix sockets only?
Umm.. all my web applications use a password that I set in an xml configuration file. If I needed to change the password I'd change it in the database, change it in the config file, and restart the app. Anyone that's hard coding passwords into the application is an idiot and should be fired.
You better have procedures in place, and you better keep that con
Re:Missing facts, or the truth? (Score:3, Insightful)
I've got to ask: what kind of muppet hard codes the passwords into the app, when grabbing them from a [configuration file / registry setting / whatever] is so trivially easy?
The article talks about doing a recompile / QA / release cycle to update passwords. WTF?
Well, this has to be done sooner or later... (Score:5, Informative)
http://www.governmentsecurity.org/articles/Default LoginsandPasswordsforNetworkedDevices.php [governmentsecurity.org]
Hardcoded userids and passwords? (Score:4, Insightful)
What decade was this article written in? Who the hell 'hard codes' a user id and password into web based applications?
Re:Hardcoded userids and passwords? (Score:4, Funny)
It was written in 1972, back when all web-based applications were written in machine code. Don't you know anything about computer history?
Re:Hardcoded userids and passwords? (Score:2)
Damn, this means I missed the part where the web, and all reference to it, was removed in 1976 in order to appease the new rulers of Earth - who then removed all reference to themselves in 1981.
Re:Hardcoded userids and passwords? (Score:3, Interesting)
One very simplistic and small example is a Perl CGI script that accesses the localhost MySQL server. Something that looked like this:
$mysql_login = "foo";
$mysql_passwd = "bar";
Well, how was it going to handle the database login? If not in the script, then in a file? And if it's in a file, then is that file any bit more secure than the script--instead of hard-coding into the script, you'll
Re:Hardcoded userids and passwords? (Score:4, Funny)
Don't store the password in a text file. Put the database login and password in a database. Then put the login and password for that database in another database. And so on.
Frequency can be good or bad (Score:5, Insightful)
Re:Frequency can be good or bad (Score:2)
One place I was at had enforced complex random passwords. Nobody could remember them so the admin password was on a sticky note by the admins desk, similarly for all the user passwords.
Changing passwords is not a panacea.
What is this guy selling? (Score:2, Interesting)
The obvious and foolproof solution: (Score:2)
makes logging in much quicker, too.
Re:The obvious and foolproof solution: (Score:3, Insightful)
This is just one of the reasons I use Debian. (Score:5, Insightful)
No it's not. That's one of the major reasons to use free software and one of the best reasons to use a carefully audited free software distribution like Debian. Backdoors are just one of the nasty things that you can check for with an army of careful volunteers.
The only place I've really seen bad practices like this is with expensive closed source junk that gets shared out with Windoze users. The passwords are to prevent access to the program itself, how backward! There's hardly a point to using SSH on such a buggy and exploited platform as Windoze and Windoze lacks X forwarding, so few bother to use anything but telnet and ftp. They try to protect the kludge by putting it behind a firewall and locking down the wireless to the point of uselessness, but people walk their laptops in and out and something is always broken, everything is slow and full of popups. What a cesspool. I don't even want to think about what I've seen "upgrading" banks because I'm going to bed soon and don't want nighmares.
By way of contrast, my home network is all free. A gateway computer shares the network out, rather than restricts access into it. People are welcome to plug into my open wireless router, because they will see the same thing any of the other 250,000,000 internet users do. I've been running this way since 2000 or so and have yet to have a real problem.
Poor coding practices (Score:2)
passwords (Score:2, Informative)
What's the problem w/ long non-expiring passwords? (Score:5, Insightful)
Maybe I'm missing something. It's conventional wisdom that "best practice" is that "everyone" should change their password every x number of days. But often times folks have to change their passwords so often they end up writing them on sticky notes, or choosing the same easy eight-character password over and over and over, with the only variant being the numbers stuck at the end. And this is good for security how?
At a previous company our policy was to have fairly long (16 character) passwords that never expired. For my own password, I chose a pnemonic one that had certain combinations of substituted numbers and special characters. It was never cracked, even though we ran password scans regularly on our Windows domain and Linux boxen.
Show me the empirical evidence that frequently-changing, short passwords are better than long, unchanging ones, and not only will I change my password, but I might even change my mind as well. Until then articles like this are just perpetuating a mythology that people have come to accept as fact.
As it happens, I think passwords have outlived their usefulness. But that's another thread entirely...
Re:What's the problem w/ long non-expiring passwor (Score:3, Informative)
s. But often times folks have to change their passwords so often they end up writing them on sticky notes, or choosing the same easy eight-character password over and over and over, with the only variant being the numbers stuck at the end. And this is good for security how?
Did you RTFA? It isn't about passwords "folks" use to access applications. It is about the passwords that applications use to access other applications, and the fact that changing these passwords risks downtimes but not changing them
Passwords are Locks ... (Score:2, Insightful)
Frankly someone walking away from a live terminal is more dangerous. That's when an "honest" person, or someone with good intentions will make a mess.
Missing the Point (Score:5, Insightful)
What? You didn't read the article? Oh. Never mind.
XYZZY (Score:3, Interesting)
The Password (Score:5, Funny)
Many years ago I was acting as the system administrator for a test system in a large publicly held company. Periodically I would receive a call from someone who had not accessed the system recently, forgot their password and locked themselves out trying to logon. I would look up their password and unlock the system for them and they would go on their merry way.
One day I received a call from a young lady who was in just such a predicament. I looked up her password and informed her that it was 'DOME' and, just to be playful, told her the price for me being gracious enough to unlock her sign-on was an explanation of the meaning of her password. She became very embarrassed over the phone and pleaded that she could never reveal her secret. I of course replied that I would not give her system access until she did. After negotiating for several minutes she finally acquiesced but made me promise to never reveal her password meaning to any of her colleagues to which I gladly agreed.
"Well, what does it mean?", I asked.
She hesitated and then replied, "It's two words."
There was pregnant pause. I unlocked her system and simply said, "Have a nice day".
"
No, we don't... (Score:4, Insightful)
Then put them on their own network segment and mitigate their risk potential.
Much like most other networks, my network is a hybrid *nix/OS X/Win environment. I limit my damage potential by putting the [potentially] dipshit software on it's own segment. I limit the potential for damage further by only buying solutions that are sane (aka *nix based; because it has a 35 year history of being secure) or by buying solutions that offer SLA's that cover damages (very rare in the non-*nix world).
I work in a call-center, and our company will lose tens of thousands of dollars _each hour_ that our phone system is down. Our phone system is embedded hardware, but it still has legacy Windows "requirements". So, rather than trust those Windows machines, I isolate them and the damage they can do. The SLA contract guarantees us that if those Windows machines crash because they "caught a cold and couldn't infect anyone else, so they infected themselves to death", our company doesn't lose money [aka, spambots that can't get out].
Passwords vs. public key auth (Score:3, Interesting)
Any Web site offering you an account of some kind requires authentication, invariably in the form of username and password. Many users will just reuse the same username and password. Those that don't must use a password manager, whether it's the Web browser's autofill or a real, live, dead-tree notepad.
Most of these sites require you to transmit your password in the clear. So not only does the Web site operator have your password (which could be used to compromise your account on other sites if it's the same), but so does anybody sniffing your network.
Both of these problems would disappear if we used public keys to authenticate. You generate a key pair, and supply the same public key everywhere when creating an account. Your browser acts as the key agent (or connects to one like ssh-agent) and uses the private key to respond to an authentication challenge. No password is sent to the server, ever.
HTTP Digest authentication also neither transmits nor stores cleartext passwords, but the Web site operator does have to have it to set the password in the first place. HTTP authentication in general currently suffers from the problem that there's no specified way to log out. A solution [w3.org] to this problem was proposed through the W3C about six years ago, but it hasn't been implemented that I'm aware of.
COLO's the worst from experience scarly (Score:3, Insightful)
john the ripper on mainframes, as/400's - tend not to see that level of pre-emptive checking.
As a rule as a admin you should constantly try cracking your own systems passwords, each one you get that user owes you beer. Least they can do for potentialy saving there job and your company.
Re:COLO's the worst from experience scarly (Score:5, Funny)
Misconceptions (Score:4, Interesting)
For example, Apache has no hard coded passwords. But... what if you have your web application accessing a MySQL database on a different server? Well, then you need to login to that MySQL database. The password is stored in your web app. When was the last time that password was updated? And that, in theory, is easy to do because the web app isn't compiled and it's stored in a single location.
Another common scenario is a compiled Intranet app to, say, access Inventory information from a central database. It's common to have hardcoded logins to the database or web servers in apps like this. In fact, almost any app that does not require a user login, but does access secure resources, probably has a hardcoded login stored inside somewhere. Legions of these apps were coded by programmers who may be very competant, but are not security aware... they could well be stored plaintext right in the binary.
So the article may have been overgeneralizing, but it was quite accurate when it comes to business software.
The Raven
Re:Misconceptions (Score:3, Insightful)
For example, Apache has no hard coded passwords. But... what if you have your web application accessing a MySQL database on a different server? Well, then you need to login to that MySQL database. The password is stored in your web app. And that, in theory, is easy to do because the web app isn't compiled and it's stored in a single location.
Any webapp written in Java most certainly is compiled. Even if you're using a non-compiled languages you're an idiot if you hard code passwords into the application.
Fluffy (Score:5, Funny)
As long as you rename your cat frequently.
I just wish z8gderfgh wouldn't claw the furniture all the time.
Is He Serious? (Score:3, Insightful)
Really? OK, here's a simple solution to the problem: When someone hard codes a password that controls access to sensitive data such that the application has to be recompiled to change the password, fire them. Problem solved. There's no excuse for hard coding passwords, and I can't think of anyone I have worked with in the past five years that has suggested doing such an idiotic thing on a sensitive application. I've seen plenty of system accounts, but the credentials are always loaded at runtime (either from a file or the command line).
Is this really common? I'm pretty sure I've worked with my fair share of chimps over the years, but not anyone that stupid. Have I been dodging dumb bullets?
Never expiring accounts are the problem (Score:3, Informative)
Any system that requires authentication should also require identification, and each account should expire at some time. It should be posible to lock individuals out without imposing change of password on all other authorized users.
In fact never expiring passwords may increase security in everyday systems: When people are regularly required to change their passwords chances are that they will choose even worse passwords, simply because it takes time to find and learn a good password.
Repeated change of password gives no protection against brute force attack simply because you have no idea wether the hacker will go sequentially through all posibilities or if the new password has already been tried and hence has low probability of being tried again.
Instead, system administrators should make sure that chosen passwords has sufficiently high entropy before they are accepted in the first place and continuously try to crack user passwords - if a password is cracked, it is weak and must be changed.
The real unspoken taboo (Score:5, Insightful)
The only thing that stands between you and total compromise is a brick and a person with the willpower to put it through your window.
Are never-expiring passwords not so great? yeah. but what's the alternative? The friggin recomended password policies that are generated by the so called security experts are something along the lines of using a completely unique password for every situation, make each of those passwords not be any combination of numbers and letters that could be remotely construed as a real word in your native language, make sure it's nothing personally identifying, and change it once a month.
In other words have totally unrememberable passwords! And oh by the way don't write them down!
It's a completely unworkable system and if you enforce password policy systematically.. guess what? your users are forced to write the passwords down and then the people who instigate 85% of all unathorized accesses (your own employees) just need to look for the yellow postits near the keyboards.
-- Greg
I know a guy that uses the same pw on all servers (Score:3, Insightful)
I Call Bullshit (Score:5, Insightful)
On the other hand, on systems I administer, I don't have expiring passwords. I pick passwords that are 20 characters long and look like line noise. Sure, it's harder to memorize them, but I have more _time_ to memorize them because I never have to change them.
Re:Revent case of that in Japan (Score:2, Insightful)
It seems like unhardcoding it would be a lot less expensive than wasted real estate in Tokyo. Sounds like a great way to make a fortune!
Re:Revent case of that in Japan (Score:5, Insightful)
Couldn't they just intall locks?
Re:Revent case of that in Japan (Score:5, Funny)
No, of course not. That would ruin the story.
Re:Revent case of that in Japan (Score:5, Insightful)
Any why would it be vacant at bargain basement prices? You're telling me there's nobody in Tokyo that would love a cheap apartment that's fully featured whom isn't rich enough to pass on it? I'd move in, install some pad-locks, and my own security system for a couple hundred. Good enough for me, for a bargain basement price..
Re:Revent case of that in Japan (Score:3, Interesting)
Re:Revent case of that in Japan (Score:5, Informative)
With property prices the way they are here, if it was really 'bargain basement' prices, they would have sold regardless of the problem.
Re:Revent case of that in Japan (Score:3, Interesting)
Re:Not that much of a problem! (Score:2)
Re:Not that much of a problem! (Score:2)
This would be even worse than a non-changing password. If someone needs to change it to a different password everyday, they will not be able to remember their current password, and hence will probably just write it down somewhere convenient. Hence there will be postit notes of passwords floating around your office.
Some sys-admins do a really shithouse job purely because the power goes to their head. This sounds like one of those time
Re:Not that much of a problem! (Score:3, Interesting)
Now that the haughty quote has been delivered, I have the attorney's attention. Aside from everybody writing down their login password somewhere and subverting your agressive security, there's probably some other vulnerability in your network that could prove to make a daily password rotation useless.
And it's very stressful for people to change their
Re:Digital vaulting is the solutiong? (Score:2)