Slashdot Mirror
The Unspoken Taboo - The Never Expiring Password
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."
but I feel the need to expose the world's most sophisticated software. The password....is "password"
Somewhere in Tokyo there was a brand new apartment building put up with state of the art everything. Video screen doorbells, plush elevators, garbage disposals, efficient kitchens, the works.
But when it was found out that someone had already broken in using the non-reprogrammable security password, the price floor fell right out from under the developer. Now there is a relatively vacant apartment building in Tokyo with all the trimmings for bargain basement prices because there is no safety available if you live there.
Jesus saved me from my past. He can save you as well.
There's a reason it's called a secret!
Naah its ******** :D
a friend of mine actually does this
he uses a fixed number of asterik's
how many of us computer-savvy are guilty of doing this for our login accounts, web banking, Email, etc? I know i am.
This sig contains repetition and redundancy.
Spelling mistake.
Jesus saved me from my past. He can save you as well.
--
Evan
"$30 for the One True Ring. $10 each additional ring!" -- JRR "Bob" Tolkien
I wonder what CowboyNeal's "unspoken taboos" are...
Perhaps he would like to comment!
shhhhh... don't tell
The locksmith just changed my locks! Did he keep a copy? Is he trustworthy? I don't know... Shit! All applications have passwords? Could someone tell me how to hack notepad? I forgot I needed a password. Someone must have left it unlocked on my rig. Probably a hacker.
I have never met a security eng who work more than 4 years in the same company. I am convinced the streets are flooded with people who know the security schemes of their previous employers. Which IMHO is worst than knowing the never changing passwords.
Huh? What applications have these?
What? This certainly isn't the case where I work. I'd say it's a pretty big leap to assume that "every corporate network" has a wide open back door and "all applications have got pre-defined passwords."
Please Use these passwords, so I can borrow your stuff. Luggage: 1234 Windows: Password (or you can just leave it blank, and i will fill it in latter) Email: Password ATM: 1234 Home security: Just dont turn it on, ill do it for you on my way out. Please email me your info so I know which house, or device you want me to take care of for you. repairguy21@gmail.com
_JS
Listen, folk. This isn't as much of a problem as you'd think it is. I like to think of the application as Social Darwinism. At the company that I own (about 723 people), I literally fire people who don't change their never-ending passwords. They are security risks and hackers. Beware of them. However, in recent years, I have learned to become accustomed to the actions of these "insecure users." Case-in-point, THEY ARE STILL TOO MUCH RISK TO ME. I had some issues in the past with legally firing these people, but since I am also an attorney, I have been able to legally manouvre around these ways.
Now, if I were a regular sysadmin, I'd have to say to be really careful. The Novell machine that I have our IT staff runs requires employees to change the password literally EVERY DAY. The password must also be different, and the employee is fired if he or she is caught writing it down. Sounds a little weird, eh? But we have not yet been hacked.
A Word Of Advice: You Can Never Be Too Prepared
Excelsior--
!seineew era sreenigne epacsteN
After IT enforced monthly changing passwords requiring so many letters with numbers in between, now I write it on a post-it note and stick it on the monitor.
All your passwords are belong to us. Resistance is futile.
Actually for US companies, due to compliance with Sarbanes Oxley and Payment Card Industry DSS standards, the problems the article talks about -- unchanging inter- and intra-application credentials -- are (getting) less of an issue.
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.
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.
http://www.governmentsecurity.org/articles/Default LoginsandPasswordsforNetworkedDevices.php
Get your Windows Malicious Software Removal Tool Here for FREE! - http://fedora.redhat.com
"Now since it is clearly impractical to rewrite applications on a regular basis, just to change the user ID and password, the result is that the user ID and password never changes."
What decade was this article written in? Who the hell 'hard codes' a user id and password into web based applications?
-- I care not for your foolish signatures.
Nobody is ever going to figure out the last four of my ssn plus my cat's name plus my birthday. Wait....ummm.....you should probably ignore that.
The never expiring password might be bad, but I think security policies that enforce password expiration after too short a period are perhaps even worse, because they lead to insecure passwords being selected. Never changing a password can certainly be a security risk, but if it is a very secure password, that is still better than rotated ones that are constantly insecure IMO.
PASSWORD - as if we keep the password quiet we will be safe !!
This is case on specialised hardware & software where there is no ubiquitous access. You can disable the alarm but you have to be there at the moment and it's most likely "ringing" already. I believe the weekly-changing-password-taped-under-the-keyboard IS ubiquitous (in Certain ranks) and yet it requires the same level of physical access as the first scenario. At my school, the CS dept, "rebeled" against the School's IT policy of 90 day changing password, we are now given never-expiring passwords. No one forgets them, no one writes them down and it stays that way.
Rule 2: Writing a spec is like writing code for a brain to execute.
Reading the article seems like reading a sales pitch.
Whilst the article bemoans a perceived security flaw in system design, it end with offering the device of a "digital vault", and indicating that it's the platform-independant miracle cure.
See, this is why I use biometrics to validate database connections in my web app. Granted, it means I have to stand in a data center 24/7 pressing my thumb up against the fingerprint reading device to allow visitors into my site. Which, by the way sells biometric database verification for your very own PHP app! Buy now, but go easy - my thumb doesn't need a slashdotting! But you can be darn sure that no bad guys will get past my watchful thumb. Anyway I gotta go now it's taken me 45 minutes to write this because I keep getting interrupted for some reason...
Wtf is digital vaulting? And what good is an article that just throws around buzz words as a solution but never defines them.
Lame article. Very lame.
I guess paranoia sell product, 'In every one of your applications'. Not everyone uses closed source, and any administrator that hardcodes in passwords should be fired. No new bit of technology is going to help you, if all you use it crap.
I think I just cashed out all my cool points.
Oh wait, you want the list of applications that DO have default passwords.
My bad.
abolish passwords.
makes logging in much quicker, too.
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
more and more mundane....
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.
Friends don't help friends install M$ junk.
This is just a result of poor coding practices. Good coding practices ensure that any authentication details (login/password) are not embedded in the application.
meh
ALL applications DO NOT have built in unchangeable passwords, some may, but most dont. Stating ALL apps have a certain feature is plain crazy - unless you have written every app that exists on the planet.
Free Blog submission, find blogs, tools and more at LS Blogs
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...
Obviously this talk about "never expiring" passwords means those that are written down on post-it notes and therefore are left for even archaeologists thousands of years in the future to read.
Therefore a simple solution is needed: Exploding post it notes with a 1 day timer.
This post will self detonate in 3
2
1
Make sure to change your password! It was fudge.
You never realize how much manually made unmanaged "linked" lists suck, till you have src.link.link.link.link...
.. and Locks only keep honest people honest.
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.
Proof by very large bribes. QED.
I go to the receptionist's computer and email IT to come and reset my password everytime I need to log in, since I forgot it.
paintball
Either create an algorithm in your software or set an expiry date on pw's.
It sounds complex, but I'm not yet convinced that it is. Feel free to elaborate...
Most companies I've worked for had standardized password that didn't change, even with staff changes. Those passwords tend to be pretty obvious too. For example, if I had worked for Wal*Mart (which I didn't), the root password for all the Unix boxes might be "wal*pass", the administrator password for every Windows PC might be "adminsam1", and all the accounting users might use "acctuser".
If the new way is so good, how come the world wasn't going to hell before? Did Enron and Worldcom go bust because the passwords wern't changed? Or did they go bust because our government coddles corporate criminals - in the cases suits stealing money is even illegal in the first place.
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?
paintball
Our old time & attendance system (I wont name names) that we got rid of a couple of years ago after only 2 years of service had a backdoor on all the timeclocks. If you entered the main phone number of their head office on the keypad you had essentially administrator rights on the terminal to change the time/etc. You could not disable this feature.
Disclaimer:I work for Configuresoft
Configuresoft http://www.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 accounts with blank passwords?" They, of course, say they have none, unless they are honest, in which case, they admit that they do not know. We do our assessment and give the CIO a report that shows 1-2% of the servers have accounts with blank passwords and maybe 50-75% have accounts with passwords older than a year.
Going through an audit sucks, but it sucks less when you can hand some canned reports to the auditors for at least a portion of the audit.
Ummm, Jon, aren't you supposed to be dead...? - Otter(3800)
What a lot of replies on this post are missing is that TFA is discussing passwords for programs to log in to other programs. It has nothing to do with user passwords.
What? You didn't read the article? Oh. Never mind.
I can fairly confidently say that all my important apps, open and closed source, have no hidden backdoors. Most simply have no oppertunity to have one, a video editor, for example, does not run any services much less any Internet services, thus nothing to get in through. For the servers, I am unconcerned because of the intense amount of scruitny. I mean sure, in theory a closed source server like IIS could have a master back door. In theory even Apache could have a back door snuck in as per Ken Tomphson's method with a C compiler (http://www.acm.org/classics/sep95/). However that's extremely unlikely in both cases.
Why? Well products like that face an extreme amount of scrutiny. Hackers, good and bad, are trying to break in all the time. We know this, because every once and awhile they succede via a bug that gets patched. Well, such a universal backdoor would very likely be discovered by these people. After all, no matter how well you try to obfuscate it, the traces will be there in disassembled code and yes, people DO pour over that looking for ways in.
I'm sure some apps have universal backdoors, but I'd bet they are pretty few and far between. There's simply no reason in most cases, and the discovery of such a thing would really shoot to hell the credibility of the company that made the software.
I remember first using Apple Network Assistant to administer a network of Macs. The default password was 'XYZZY' which is, of course, the 'password' for Zork. Fortunately, even back when said network was a mix of OS 7.6.1 and 8.1 Macs, the Zork reference was too far in the past for the middle school students to even have a clue about....
End of Line
"
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".
"
http://www.TheGamerNation.com/Forums
...and programming effectively with the (end)user in mind. most of us upon reflection will realise that any properly coded "secure" application will need to ship with a password already enabled. The programmer needs to ensure that the end user not only creates an unique password for personal use, but also creates a scenario where only physical access can "uncreate" any thusly made password via code from a generated passcode sheet (for example).
Corporations should be more concerned about those that can break in via their unchanged admin password on their routers.
For every present, there is a past
Comment removed based on user account deletion
This is different from a backdoor password how?
I'm thinking of the best password of that time, "Joshua."
Heh. I've been using the same password for 10 years. It's 8 characters with special characters. John the ripper couldn't crack in a reasonable time 5 years ago and it can't today. That's good enough for me.
All applications have got pre-defined passwords that never change.
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].
Don't think that a small group of dedicated individuals can't change the world. It's the only thing that ever has.
is to not use the same password everywhere, but to come up with a password SCHEME. something that uses the name of the site in a way that you can use the scheme everywhere but have it different for each site yet be immediately recalled.
it raises the bar towards the unlikely event that an attacker has compromised more than one of your systems and can comprehend the pattern you're using.
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 to this problem was proposed through the W3C about six years ago, but it hasn't been implemented that I'm aware of.
In general, it is safe and legal to kill your children. -- POSIX Programmer's Guide
Of all the pentests i've done the number of colo box's (mostly the mainframes and applications on box's) have.....default passwords still active. generaly there not disabled nd all the colo/customer does is add there own on top ignoring the defaults.
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.
That is a great idea. Have registrars require the correct information for the account with the registrar, but don't list it in the whois information. However, I do wonder how much it would cost the registars to do something like that themselves.
I can't believe I did that again. Replied to the wrong post. Sorry.
With the technology available today, the best answer to the password problem is get rid of it. Users would be given a personal certificate from a an issuing authority that is chained to a central controlling authority. The personal cert public key would be associated with a user account or some other system that uses ACL security. That personal cert private key would be 'burned' to some sort of portable media like an ID card or thumb drive. When the private key is burned to the media, a PIN is associated with it. Resoures that the user would need access to would be secured using the user account which now has an association with the cert. To access the resource, the user would be prompted to insert or attach the media with their private key and type in their short PIN number. When they are done, they take their media and leave. Of course there is much more back end crap that goes with this, but it does work if implemented correctly. The only BIG downside to this is physical security of the device which contains the private key...but it's the same concept as an ATM card that has access to your checking account as long as you have a simple 4 digit PIN...
-- SMTP: Spam and Malware Transfer Protocol. Also used on rare occasion to transmit e-mail messages.
I was just working with a colo server that's roughly 4,000 miles from my den using terminal services. In my pajamas. Copy/paste, run apps, etc. Good enough pipe and the performance is almost indistinguishable from physically sitting at the box. Completely secure (unless you know something a few million other people who do the same thing don't). Funny enough there are 5-7 people logged into there right now as well, from another one of the company's locations. They have limited accounts and run a custom app written in some .NET thing. Never had a problem. The server doesn't even hiccup, and it's not a really big box at all.
But I suppose that's not 'cool enough' for you... X forwarding, what a concept. And 'Windoze', that's cute.
I can't deny the value of logging to a console on a BSD box halfway around the world over SSH, but you're completely over the top there man. Might want to inform yourself a bit.
If someone has the pap admin password for Linksys's PAP2, I am sure a lot of folks in the VOIP scene would greatly appreciate sharing of wealth :-)
you haven't tried rainbow crack with a big enough database yet...
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 means that anyone with access to the source code or configuration has access to your data collections.
Login: rms
Password: rms
It's true no man is an island, but if you take a bunch of dead guys and tie 'em together, they make a good raft.
I have many passwords that are all longer than 12 characters, use upper and lowercase letters, numbers, and do not resemble common words. Such passwords are required in a few of the systems that I use. What makes it worse is when you're expected to change it. As if anyone was going to be able to guess it in the first place. I usually just change one character in the password when it asks me to change it and then change it back to its original value. That'll teach them.
Well the problem is, unless you have a bulletproof memory you'll still have to write passwords down if you want to be secure. Trying to remember 50 secure 16 character passwords is pretty hard, so if you are using passwords that long, odds are they're the same password. The problem here is that the owner of xyzsite.com may now have your password to abcsite.com. Of course odds are nobody will check, but if you use that argument there's no real point in using passwords.
"And we have seen and do testify that the Father sent the Son to be the Savior of the World"
1 John 4:14
That's pretty obtuse, but no matter how long I am away from a place I can calculate these things rapidly, and it is not particularly easy to crack. The few places where it really matters (banks, for instance), there are other policies in place on their side to mitigate my exposure anyway.
Even so, I think the approach you described above is enough. That's true as long as you are a normal person like 99.999% of everyone else that uses the places where you have accounts. If you were unusual in some respect, it would be safer to create really difficult passwords with a time component and change them on a regular basis.
But come on...for almost everyone that's overkill. People that really want to crack something and make a pile of cash are not going for Joe User. They are embezzling from inside the company or worse.
rms was right. passwords are a way of the big brother to control you, not for your own good, but for their good. if possible, never create a password. never save anything you dont want others to know. information should be free anyway, and sharing should be encouraged. But seriously. Who wants to remember all ASDF24tsdfgnfadigh438t passwords that make no sense. Passwords and security are just illusion of privacy! THERE IS NO PRIVACY!
"Dome" around here is a coffee shop a la Starbucks...
But in their stores they often have a mural with an old sail ship with their logo on the back. Problem is the boat is narrow, so they put it across two lines...
DO
ME
I believe in cryptonomicon the thing to do for unbreakable "passwords" was to instead use passphrases, run them through the encryption program which would then fill out whatever "password" field you need with the now nonsense encrypted private passphrase.
But I guess since you could always Van Ech Phreak the monitor, or use mic's to pick up the keystrokes, or....
Yeah paranoia only gets you so far I guess.
Speaking of which: fe1fg2jKmN3.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
I've notice many people here are misunderstanding the article. While the article does incorrectly state that 'all applications have hard coded passwords', I think what he meant was that 'nearly all applications that access secure resources over a network have hard coded passwords', and this is quite likely true.
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
"I will trust Google to 'do no evil' until the founders no longer run it." Hello Alphabet.
Here's one that's written in JavaScript so you can run it remotely wherever or as a Mozilla/Firefox extension:
http://crypto.stanford.edu/PwdHash/RemotePwdHash/
http://crypto.stanford.edu/PwdHash/
PwdHash takes your generic password and uses it to hash the address of the site you're accessing to generate a site-specific password. This way you only have to remember your single generic password but each site never sees it.
q
Trojan horses -- the definitive answer
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 favorite closed source C compiler doing these days? :)
The best way to predict the future is to create it. - Peter Drucker.
As long as you rename your cat frequently.
I just wish z8gderfgh wouldn't claw the furniture all the time.
it's a blue bright blue Saturday hey hey
I work in IT, and actually found this concern completely new. This problem actually never even crossed my mind until now. I guess I don't take my job seriously enough.
You should just make a little text file on your desktop and put it in there, That way nobody will find it when your computer off...er...
I knew a guy who wrote 'door' games for BBS's. He was the first person to tell me that "every" program out there has a back door somewhere in it, that will give the author free roam of the host system. He would put a keyword in somewhere, that would open up a command.com session that would let him do anything he wanted. Ya, this is way back..
Since then, I've written plenty of stuff. I can't think of anywhere I've ever put in a back door or hardcoded password. Very occasionally, I may do:
if ("$password" eq "mypassword"){
$auth = 1;
};
But if I do, it's because I suspect the original author's password validation was completely broken, and I wanted a quick and dirty way around it. Statements like that never stay around for more than a minute or two, and never make it to a live site.
I suspect there may be people out there that *DO* put back doors in. I also know they are the ones who will be ripped a new one, when it shows up on the Internet, and the company is embarassed over it.
I am definately one of those people who doesn't like to be embarassed, nor ripped a new one, therefore nothing I ever put out there will ever have a hardcoded password nor backdoor in it.
Since I write in scripting languages, it's pretty freakin' easy for anyone who gets something from me to verify this.
Serious? Seriousness is well above my pay grade.
Right. A simple googling and you find out the piece linked to is written by someone who works for the company that (surprise, surprise!) has the solution for your privacy-password concerns. Slashdot already has paid advertisements, they certainly don't need to be giving them away for free and calling them "stories".
"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.
My favorite is the one Dell forces onto corporate customers so they can support them:
Username: admindell
Password: delladmin
All applications have got pre-defined passwords that never change.
All is a pretty strong word. It kinda makes that sentence complete horse shit.
I don't think you're missing anything -- I've seen talks by people from Microsoft even advocating one, decently unguessable password (they recommend a 'passphrase' instead of an individual word).
Honestly, why have a password of "snoopy" when you could have one of "SnoopyWentToTownToday" ? Not going to be in *any* dictionary, that one.
uh-uh
I can't read an article by someone who is supposed to be educated that cannot seem to grasp the difference between a noun and a verb. "Logon" is a noun, and "log on" is the verb. You do not "logon" to a system, you "log on." You do have a "logon," not a "log on." Do these people really pass their GE courses in college, or is this what happens when you graduate from unaccredited school like DeVry?
Yeah, some people do put backdoors in, but as you say, its crazy... Like you I have put them in my test code, usually when developing password routines, so I can get in If I screw up, or to bypass logins whilst testing, but they dont stay in code that is released. Programs can be disasembled, single stepped through, analysed, and backdoors will be found if they exist. Cant imaging any massive large scale apps like the original poster is on about having a backdoor, they would have been looked at thousands of times by people. Custom made apps are more likely to have something in, but only if the dev is mental, as once caught, that company would lose its reputation for trust and security. The original article may have carried some weight if it actually stated names of these packages that have the unchangeable "backdoors".
Free Blog submission, find blogs, tools and more at LS Blogs
maggie - used by cartoon baby pedophiles
monkey - used by primatophiles
buster - used by obsolete-shoe-brand-ophiles
bandit - used by Jonny-Quest-Canine-ophiles
Those who sacrifice security to condemn liberty deserve to repeat history or something. - Benjamin Santayana
The most important aspect of a password is that it is obscure and would take cracking tools a long time to break (so has numeric characters).
Then place a webcam on the computer.
Left-blink=0, Right-blink=1, double-blink=enter.
for a company which handled a LOT of oil industry data. They had a windoze domain admin account for sophos to do it's stuff to all the pcs. The password was 'antivirus' an audit team got it on their third guess.
hahaha.
I've been trying to figure out any famous people named "Maggie". I didn't even think of the Simpsons. Doh.
Serious? Seriousness is well above my pay grade.
Hi, I'm new here too. I couldn't help but notice we seem to be about 70% of the article reading population in this thread.
This is really a bunch of total crap. I have worked in many different areas, and in any real business, people are not hard-coding backend-system-passwords into their code. They are specified in configuration files. The article is probably written by some consultant trying to sell that "digital vaulting technology". Whatever that is.
Seriously, app servers need passwords that don't change. That's just the way it is. The "best practice" in this situation is to simply use a very strong password. Meaning 32 random characters presumably autogenerated. If no one ever needs to type it in, there's no excuse.
Now all the others I can expect, but "maggie", I just don't get that one. Have to admit, it sounds more than a little perverse.
threadeds blog
> As it happens, I think passwords have outlived their usefulness. But that's
> another thread entirely...
Yeah, when I travel around the country, using my Gmail account from net cafes and friends houses, I think the same thing. Much better if it requires some hardware like an iris scan or card swipe that won't be available in most of the places I log on from. Better still, don't require a password to log on - simply type in the username of the account whose email you want to read and get on with it. All that `enter your password` and `password not recognized - please try again` is so old fashioned.
In order for these applications to get access to data, they have to "logon" to the systems and applications that store the data, and since the credentials to logon are in the application, they are embedded in the code. Now since it is clearly impractical to rewrite applications on a regular basis, just to change the user ID and password, the result is that the user ID and password never changes.
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?
Stop-Prism.org: Opt Out of Surveillance
Oh, it's only the expired passwords. I see...
Oh, now I understand: the site does use ASP, but it's not your site...
Say you are the sysadmin at company X, you build a server to spec. This spec includes the root password as well as passwords for each application. You now remember the passwords in that spec. Next year you decide to leave.
If the passwords in that spec are 'never expiring' you can gain access to that machine (and any DBs, etc.) and any other machine built to that spec. The problem is not personal passwords that are not shared with anyone, it's private passwords that are shared with few. Once one of those few become untrusted (they have left the company or been fired) that password has become a vulnerability.
As you read the article, the first thing you note is really that this "trusted" person may still be able to authenticate after he leaves his job. The problem is not that the password never expires, but that his account never expires or there is just one shared account.
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 issue that he's talking about is the web application talking to the database, or other backend system, as a system user. This has absolutely nothing to do with the end users identity, or their password.
All of the enterprise scale systems I've been involved with employ Mutually Authenticated SSL (MASSL) between back end servers. There are not only no unencrypted communications between back end servers, but no passwords involved at all. This does require lifecycle management of certs on the backend, but that's the price you have to pay. Certs expire and need to be re-issued, but these in conjunction with firewalls means no one can take them and connect to servers without getting onto the boxes that you need to connect from and write an application that uses the certificate stored on the box you need to connect from.
If you can do that, then the least of your problems are related to passwords.
As opposed to the spoken taboo?
Its been said previously on /. that the best thing to do is make your password the same as your cats name. Mine is 25@jDWQ0! and I change her name every thirty days.
"Flags are bits of colored cloth that governments use first to shrink-wrap people's brains..."
> All applications have got pre-defined passwords that never change.
Like anyone could ever know that. Gosh!
a friend of mine noticed the alarm system was the same as the one at home. He had read the manual and wondered if the initial security code was still active. Needless to say, he annoyed at least one vice principal.
Someone hates these cans.
Again we get back to the basic security facts that are: If you have a copy of the secret used to access the data, then anyone who can impersonate you also has that secret. This digital vault product punted by these people is total snake oil. The only way you can have a machine that has security for service account credentials is a hardware secret store and even that only changes the problem to being how to protect you hardware secret store interface. In the end you would be better spending your money on other ways to protect your data.
Look, let me bring some flippin reality to this whole security thing..
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
Slashdot, would a spell-checker for posting be too much to ask? It's not rocket science!
an ordinary md5 gives you more than enough for now.
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 network authentication, you should ideally combine these measures with a protocol like SRP.
Xenu loves you!
I do have to agree that citing a buzz-phrase like digital vaults is a very lame way to end an artical. But that said, it's an interesting technology to apply to solve this problem.
Mind you, it doesn't actually solve it as many unsolved issues remain (escalation of privledges from within the application, administartive access, development backdoors, key management, migration to the new architecture, etc.) but it's nice to have a new tool to apply to the problem.
Below is an explainatin of "Digital Vaults":
Digital Vaults enable users across the internet to share access to sensitive information in a simple secure way.
A major challenge that is faced by all organisations selecting IT technology is trying to clearly understand how a particular solution may address the challenges they are tasked with solving. And this often involves trying to understand what various vendors mean when using generic terminology.
The term "Digital Vault" has come to the fore in the last few months and now several vendors are offering technology under the umbrella of digital vaulting. So what should you understand? A simple acid test to apply to anything claiming to be a digital vault is the following. Does the digital vault hide items from those who have no right to see them, and does it ensure that those with access rights are monitored every step of the way.
The term vault should be used because it relates to the vault in the physical world. Every enterprise relies on few priceless items that must never be lost or exposed. The danger of losing or exposing these priceless items is vital to the enterprise's business continuity and can even threaten its very existence. In today's business world, a large percentage of those items is in digital format. Most business enterprises today will still use the physical vault to securely store copies of the critical data, but this is impractical when on the one hand you are required to make that data available on a day to day basis for those who need to view, and modify the data, and at the same time you are required to keep it under "lock and key" so that those who are not entitled to see it are kept away from it.
Bringing it back to the physical world analogy; the physical vault can only be accessed by those who have privileges to do so, and once in the vault, only those safety deposit boxes that you have the right to open should be made available to you. For those who saw the the Bourne Identity (movie), you may remember the scene when the hero enters the bank and gains access to the vault. He is then provided access to his private safety deposit box - well the digital vault needs to mirror this physical scenario. So the digital vault should be a mirror image of the physical vault. Critical data needs to be stored in a secure location, and should be visible only to those with the rights to see it.
Another key factor in identifying a Digital Vault should be its ability to mimic all existing security processes and procedures in the organisation for handling sensitive information. For example, most organisations will have clearly defined policies and procedures defining how sensitive physical items are handled. For example, who has access to the physical vault, and the security boxes? Are individuals allowed to access on their own, or is a dual control mechanism in place, for example dual keys? Does staff have to be authorized to enter, and are there times of day when access is permitted. These and many more procedures are found in organisations, and a Digital Vault must be able to address these procedures as is. It is not advisable to try and redefine policies and procedures to fit technology - the technology has to fit.
A digital vault by its very nature is going to provide some standard services to ensure that its contents are protected, such as being a long-term repository, highly secured regardless of overall network security and regardless of the physical topology of th
Its not users who are broken, it's systems not taking account their likely behaviour and fixing it technically.
In the city I live, I did some warwalking to test kismac and for at least 70% of the networks, you could just enter the IP address of the router and the user/pass would be the default ones, allowing you to remotely control it from any browser. How comes people do not realize? I thought of dropping a note in the mailboxes of companies with badly configured wireless networks saying something like:
"hello, did you know that the user/pass of your router is ***** / *****? Yeah, so do I. You should considering changing it".
"Words of wisdom: drop that zero and get with the hero" -- Vanilla Ice
I once hosted a designer who insisited on all passwords being the user name backwards for all clients. Recipe for disaster for sure. Is that #2 or #3 in the password hackers manual?
Eric C Williams E-Builders, LLC
If you can retrieve the password how can you tell a user their information is secure?
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.
* Winners compare their achievements to their goals, losers compare theirs to that of others.
they all seem dog names to me. Yes, I know a guy who owns a dog called "macaco" [monkey in portuguese] -- hell, his cousin owns a cat named "papagaio" [parrot] and a dog named "gato" [cat]!!!
then again, who am I to speak? my 6yo's turtle is called "piriri" [an infantile word for "diarrhea" -- my son had it when he got the turtle as a birthday present]
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
Only the Shadow knows.
Maggie Mae. If you don't know who that is, ask Rod Stewart.
Perhaps the monkey hopes to make president or the user is just monkeying around. More till ad nauseum on this one.
Buster Keaton or "now wait a minute buster"
Smokey and the Bandit
How about the security of the password management in browsers? I mean, if you share your computer IE, AFAIK, doesn't even allow you to password protect your passwords. Firefox lets you do this, but just exactly how safe is it??
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."
Sounds like your "security savvy profesionals" are nothing more than squirrely amateurs.
Real men (and women) don't use passwords. Real people don't need passwords.
Y' see, there's this little thingamajig called SSH, the Secure SHell. This watchamacallit allows you to create something called public-private key pair. It just so happens that in the process of creating this lovely pair, you're asked for the pass phrase that'll protect your private key.
So you generate the key pair. You configure your SSH servers to allow only this type of authentication. You store your private, pass-phrase encrypted key on a USB stick, CompactFlash(TM) card, or even a CD-ROM, what ever suits your fancy.
To get in, now you not only have to know the pass phrase to decrypt the private key, but you also need a physical token. And because public-private key authentication is based on challenge-response, no password of any kind is EVER transmitted over the wire.
Amateurs.
In the days of old, you would just kill the man (or people) who knew the secret when he was done. Ivan the Terrible did it, I'm sure many other rules did too. Nowadays it would be a bit harder to do this... hence the reason for outsourcing it to some third world country where such things are easier to do.
"Waste not one watt!" - CZ
For my own password, I chose a pnemonic one that had certain combinations of substituted numbers and special characters.
Grishkin is nice: her Russian eye
Is underlined for emphasis;
Uncorseted, her friendly bust
Gives promise of pneumatic bliss.
It's mnemonic, not pnemonic. Pne- suggests breath, vapor; mne- is memory. "Pneuma" is the Greek word for a blast of air, "Mnemosyne" is the goddess of memory.
Eliot's joke is on a tire, and a pun on the use of "pneuma" for "the breath of life."
I have one common (but not quite as easy to guess) pasword for several internet forums.
Things that are really critical, however, get their own password. My computer access at work, for instance (and so far I don't do homebanking at all).
C - the footgun of programming languages
Now that you mention that, the set amount of +5 funnies has inceased to nominal state and all is well and good with the universe yet again.
'coz monkeys just kick ass!
And 'coz we're kin to the apes, and at a porn site we're indulging our primative desires.
Like BMC Patrol
Like some triggers in Sybase
Like some administrative applications in Oracle
Like Windows clusters
it's not a dirty little secret at all.
That is a better idea than a PostIt note, but almost every PC has hidden shared directories that are available to anyone on the same network (known or not). Take it one tiny step further and ZIP the file with encryption. My ZIP password is non-trivial, since length and special characters matter.
Now you have a single file that is fairly safe to copy to every machine, email, and keep on a USB drive. To crack a ZIP file requires a brute force method. ZIP is portable and already loaded on every other system - Windows, Mac, Solaris, AIX, HP-UX, Irix, and Linux.
The main thing is to keep a primary file in one location and use all the other copies as READ-ONLY. Placing this file into RCS/CVS/Subversion on a central server might be worth it for some, but not me. $HOME and my desktops are good enough.
This technique has the added benifit of creating multuple backups.
Sometimes I have to wonder how submitters get through with word-by-word copying from other sites.
Is there really nothing else happening/bothering anyone?
and IIS is about as secure as Apache if Apache were as popular as IIS, right? Honk, Honk, try again.
Those idiots in Redmond like to say that nothing is better than their crap, but they can't or won't make it so. Windoze will approach free software stability when you can net install the latest version and freely share and improve the source code. Other than that, you are at the mercy of who knows what that you can't remove that is maintained by relatively few people who's bosses are all about the $ not the code. I'm not going to say free software is perfect, but I will say that it's much better than anything else. Equating the quality of free software with M$ is one of the more insulting lies Microsoft ever came up with.
Friends don't help friends install M$ junk.
I work for a IT firm and, though we give the strong password speech regularly, some of our clients are so opposed to having to do something as difficult as remembering a password that we let them keep their insecurity rather than risk losing business. I wish it were possible to be hard line and just force people to use strong passwords; but, when they can fire us for doing so; it seems a little quixotic. Until end users are willing to accept that they, personally, need to take some responsibility for their data security, all of this will continue to be a joke. After all, Wells Fargo comes by their house and makes sure their doors are locked and the alarm is set everytime they leave home. Why shouldn't Symantec to the same for their PCs?
WARNING: Smoking this sig may cause lowered IQ, insanity or short term memory loss. It is also really bad for your monit
The requirement for changeing your password is that it must be changed before a brut force attack can 'guess' the password. That was before password hash tables that makes the brut force attack a matter of minutes.
You are correct - passwords are not enough in these times. But that's another thread entirely...
zenray
For my own password, I chose a pnemonic one
You mean, a password so sucky that you could REMEMBER it blows?
You see? You see? Your stupid minds! Stupid! Stupid!
I know the head IT guy of a certain company that sets the root password on all his servers to be the same 6 letter word that he also uses for all the web apps and databases I develop for him. I tell him he should really REALLY not do that... but he keeps doing it. I am just a contract worker for him, so I don't have the power to change them. He's had various servers hacked about 3 times in the last 4 years, leading to much panic and re-installing and backup restorations... but yet he doesn't change his ways! And updating software and security patches on his servers?... forget about it, I think he's still using the same system as the first day it was setup.
Meh.
I also used postit's to retain passwords, but I was going through so many of them. NOW ITS POSTED ON A WHITE BOARD IN MY OFFICE. How secure is that. If I could only retain my passwords, none of this would be necessary. The tangent issue we have in my corp. is that they have no centralized authority so I have lists of passwords that all require changing at unsynchronized intervals. This is security insanity!!!!
I put mine under my keyboard.
Raise your children as if you were teaching them to raise your grandchildren, because you are.
The article states:
"In order for these applications to get access to data, they have to "logon" to the systems and applications that store the data, and since the credentials to logon are in the application, they are embedded in the code. Now since it is clearly impractical to rewrite applications on a regular basis, just to change the user ID and password, the result is that the user ID and password never changes. So what's the big deal you might ask? Well there are a number of things."
What applications is this guy talking about? Where I work for instance, passwords are not allowed to be stored in property files or code, they must be stored in a secured db. How do you get access to said secured db? With an id and password that expire every x days and must conform to certain rules. How does an application access said db? Through a datasource which has access to the id and an encrypted copy of the password - the same password that has to be changed every x days, etc.
Going on means going far
Going far means returning
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.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
joke ruins YOU!
"Our interests are to see if we can't scale it up to something more exciting," he said.
Where do you bank?
"Our interests are to see if we can't scale it up to something more exciting," he said.
I change my Slashdot password religiously.
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.
Nathan's blog
I think the key thing here is the importance of security for you and for them. Why should they care if their porn site access is compromised? It doesn't affect them at all if someone else views pictures under their user name. From their point of view, you're the ones obstructing access by changing their password on them. Of course, from your point of view, the compromised accounts are lost revenue. It's all relative, you see. Especially on those incest sites...
This sig has absolutely no significance and serves only to take up screen space and waste the time of the reader.
What the hell are non-hashed passwords doing in that table? Are they nucking futs?
Free Lesson to Programmers Everywhere
When you store passwords for a site/application you create, you store the HASH of the password. The hash is basically gobblygook that the password gets translated to. You can't get the password back once you hash it. That's the point. When you call the help desk because you forgot your password, they create you a new one. They can't tell you, because it's technically "impossible" to do so.
It's also a good idea to prefix your password with a 'secret'. It adds another layer and actually increases the security a little bit. So you do:
$hpass = sha256($SECRET . $pass);
insert into users (username, password) values ('$user', '$hpass');
You should use algorithms like SHA256 for new applications, SHA-1 is alright for current applications, and MD5 is no good anymore.
When you want to check the passwords, do:
select password from users where username = '$given_user';
if (password == sha256($SECRET . $given_password)
good, login successful
A few other things to note:
1. Don't postfix passwords with a constant (well, that won't help at all-- prefixing will though)
2. You can probably truncate a SHA256 hash down to 160 bits or something, but don't unless you have to.
3. Hashing something twice doesn't help MD5(SHA(x)) is no better than the hardest of the two to break.
Wer mit Ungeheuern kämpft, mag zusehn, dass er nicht dabei zum Ungeheuer wird. --Nietzsche
The issue, is not the hard coded plain text passwords, as these are quite naive. The issues come down to not understanding how to use a password.
From TFA: "The good news is that there are solutions available that will allow you to once and for all face up to this unspoken taboo and eliminate this threat. The solution is digital vaulting technology." ...and? Any links to this "digital vaulting technology"? Are their any reputable vendors in this space yet? How does it work? What does it do?
Passwords should be changed to protect against more than brute force attacks.
If your password is very complex, it can stand up to the threat of a brute force attack. One reason passwords are required to be changed at intervals with the idea that by the time a password is brute forced, it has already been changed.
But complexity does not protect from other threats, such as shoulder surfing, keystroke monitors, administrators, attackers that have root on your box, passwords shared with other employees, etc.
In these cases, changing the password reduces the window of exposure. In many systems, an attacker can't change the password, because it will tip off the victim. So changing the password will remove the attacker's access.
marc
I found out this about a software vendor of our company's and I was horrified to hear there was a single password, and even more horrified to know what it was -- it was pretty simple. So I made them change it, and they've hated me since. Good, I say, they shouldn't have been such twits to begin with and now they know that I know how incompetent they are.
So what could make this even worse? I work at a hospital and the application in question contains patient info (AKA ePHI, w/r/t HIPAA)! My life would be so much simpler if I didn't know as much as I do while still knowing too little to write my own clinical software.
And since the applications do not have any integrated security such as VPN technology, the passwords to these accounts are often stored in clear text (not encrypted), thus becoming visible to developers, support staff and anyone that has access to the application code.
Just what do they think the connection is between using VPN (fundamentally a communications protocol) and whether or not a password is embedded in the source code? *sigh* The impression I've gotten of the whole article, reinforced by things like that sentence, is that it exemplifies the saying that a little knowledge is a dangerous thing.
You forgot Thatcher, former Prime Minister of the United Kingdom. Maybe the others are nicknames of other former Prime Ministers?
If you must moderate, please moderate as irrelevent, not something bad, because I'm sure someone will find this interest
In today's environment, this article doesn't jive with reality. Any programmer that hard-codes a password should be fired. There's simply no excuse for not providing the necessary mechanisms to change it as business needs change. A hard-coded password is just the result of a lazy programmer or a programmer with a bent on damaging company assets.
Now before I get flamed for this post, I am a programmer - not a manager. Unfortunately, a lot of companies and developers don't have the standards I do, and this sort of thing gets to be a problem. If the product were spec'd correctly from the beginning, this shouldn't be a problem. Even more than that, I can't recall the last time I installed a Microsoft product that didn't allow me to change the service account passwords if I so chose. Much as we might not love MS, at least they can do something right once in a while.
If you have an n-user license, it doesn't matter if it is 50 instances of the same user or 50 different users. However, in a high-traffic application, if you remove the connection pool from the mix and require every user to create a new connection, you lose a HUGE amount of scaling power.
I remember debugging a piece of this 4-tier J2EE app this other guy at the office had written and was horrified at the performance. We had a 10Gb/s link to another site where we were, basically, screen-scraping an old VT-100 app (egads, that was awful). This thing was sooooo slow it was a joke. I mean, pulling a couple 10k records, you could easily read the data as it lazily scrolled down the screen. After about a minute, we'd run out of database connections. Turns out, dude's code was opening and closing the database connection for each record--that is, roughly 116 times per second. He only really had one at a time, but latency eventually caught up and locked-up the app as the DB server was cleaning up the closed connections.
THAT is where this connection-pooling, single login business matters and makes sense. Say you have 400 users. They're each pulling up a record every, say, twenty seconds. Total transaction time from open to close is, say, five seconds. So, you need to have 100 connections to avoid maxing out. That's about as much as even a fairly substantial server can handle, but more than that, if you're using a commercial DB, that could be several hundred thousand dollars in license fees. Now, say you have a pool of 50 connections and you remove 2-3s from each transaction because you're removing the login-logout cycle. Suddenly, you only need 10 connections, having cut not only your hardware requirements, but reduced your licensing burden by probably 70-80%.
That's not necesarily true. I follow the same approach. The first password (which I memorize) is for an encrypted password storage. When I need to access something, I can read its password from the device. Most frequently used ones will tend to stick, just from frequent use.
Obviously one must be really careful with the master password, but once proper care is taken, you have both the advantage of a hard to guess password (random, probably) and ease of retrieval. That's why it is always memorized.
Combine that with S/Key, and you've got some hell of a security system.
GPG 0x1B479C78
the Minnesota legislative auditor released a report this week.
hundreds of no password accounts on the mainframes.
passwords last changed in 1982, etc.
google "Minnesota Legislative Auditor" to get the report.
hilarious reading.
If it sucks or blows, shouldn't it be pneumatic?
pnemonic seems to be a cross between pneumatic and mnemnomic.
Fuckit, I'll just throw letters around, and let everyone else decide where they're supposed to go.
You see? You see? Your stupid minds! Stupid! Stupid!
If my remote Linux box crashes and restarts, then IF I had secure passwords I'd have to log in and enter the passwords (eg for the https certificate) by hand. Whenever it happened, wherever I was, whoever I was doing.
So I have hard-coded passwords and it can crash and restart any time it likes and it doesn't bother me (and the organization gets perfect continuity even if I'm in the subway at the time).
People should think long and hard about passwords instead of having something obvious. I worked on a PC a few months back where the customer had WindowsXP Pro on their system and had 2 logins. Both logins had passwords. The first user password I didn't know so I tried clicking the "?" for the clue. Again, nothing I could just guess.
I clicked on the second user "?" and to my absolute surprise, the clue was "my wife". I typed the NAME OF THE TOP USER as the password and sure enough, into Windows I go!
I know this is just a home user where security is not an issue, but it's unnerving to know people actually do this. Why have a password so obvious. Don't bother with a password at all!!
You moved your mouse. Please restart Windows for changes to take effect.
The problem from the article is how do you authenticate the apache script to the database without giving permanent access to database for any programmers who see the code.
One answer is to authenticate the machine running Apache to the DB, rather than just a username/password pair. For example you could use something like IPSec so that the only machines able to connect to the database have the right IP address and certificate.
This way often you will never need to give the programmer access to the production apache machine ever!
If you do give them access to the apache machine, the problem is solved when you revoke their access (unless you were stupid enough to ever give them root access).
Finally, you can use a username/password pair to prevent other applications (and their developers) on the same machine from ever accessing unnecessary information from other projects etc.
evertried lophtrack ? if you have such acounts give them a damn long password with combinations of non regular charcters like !@#$%^&*()_+ etc use caps and lower case letters. Make it at least 16 digits long. And don't use simple words like "Ajax" because it's a normal word a dictionairy attack wil have it cracked in a minute.
I know you're out there. I can feel you now. I know that you're afraid. You're afraid of us. You're afraid of change.
Ya, I thought of that one too.. That really weirds me out. Is THIS the face you want to think about, while going to look at porn?
Serious? Seriousness is well above my pay grade.