I think the original analogy is very poor, personally. It implies that the responsibility shouldn't lay with the ISPs by comparing them with manufacturers of vehicles. ISPs are much more like the people who manage and regulate the roads and toll booths. Unlike card manufacturers with bad drivers, ISPs actually in an ideal position to effectively address the problems of infected computers. In addition, they provide the resources (which belong to the ISPs) that an infected computer requires in order to be a threat to the Internet at large (and thus other computers). It is the ISPs networks that they sell. And most ISPs actually have in their contracts with their customers (at least in the US) that their networks may not be used for crime, abuse, etc. So, the ISPs likely have legal standing already to enforce the issue.
Although, turning those users "off" without warning and giving alternatives is a bit extreme. It would be nicer (as I've seen with some ISPs in the US) if the user were notified that suspicious malware-related communication is coming from their Internet connection. And if not resolved after a notification or two, disable access until the problem is resolved. Again... it's the ISPs' networks that are also responsible for the problem... not just some end user's computer.
Yeah, one problem... Anti-virus is not terribly effective against a lot of the botnets out there! They update themselves more often than most A/V companies update their DATs. And many of them are managing to root-kit the system, so even if it's cleaned, hidden processes (even from the OS) just reinfect.
I work in security. I tracked down 2 systems just this week (a number of others I provided for the local sys admins to track down) that had spam malware (detected and tracked down through outbound traffic monitoring for a 15K+ employee network). One of the systems got a clean bill of health from McAfee... well, actually, it found malware, said it cleaned it, except for some running processes. So, reboot the system... all the malware came back. The system had a root kit that can really only be cleaned by a full re-install of the system (or an off-line boot CD that could possibly clean it if properly identified). And the user who didn't know better just assumed he was clean when the A/V software said he was, and that maybe he kept getting infected... but felt safe because the McAfee "status bar" was green.
So... while it sounds like a neat theory, I am highly skeptical of it being fully successful. It would reduce things greatly to ensure people are running A/V. Although, it also forces people to run A/V, and probably only "supported vendors".... i.e. pay someone to scan your system if you want to use the Internet, in addition to you Internet access fees. Not sure how I feel about the power posturing and shifts in this scenario.
I agree that it raises question as to why one should use them, but "down time" is not the biggest threat out there, if you wanna talk loss/cost. While one's time is valuable, I'm thinking that their bank account information, passwords, etc, might be slightly more valuable to them. Personally, I think good secure end-user practices is the best protection, I do think that a good A/V program is needed.
So, while there is malware out there that is less harmful, more of the malware out there is much MORE harmful... if you disagree, please provide your financial account information, or contact me to transfer all funds to a secured off-shore account... maybe buy me a new car too!;-)
But seriously... this is really bad, and REALLY stupid. But having no protection for most users risks damaging them in ways worse than a few hours of time to manually fix their issue. And from a corporate perspective, loss of sensitive information is a BIG deal and can cost a LOT more. And that's just talking about data loss. Being part of a botnet to help facilitate financial fraud and other badness... that's also double plus ungood... and irresponsible to not take measures to help keep your computer from playing a part in those crimes.
Anyway... I agree it raises question... but there more downside to malware than just downtime.
I completely agree. I also think that it can be attributed to a continuing breakdown of the perception that there is a gross incompatibility between Mac users and the rest of the world. While I still do field questions such as "Will I be able to open a Word file someone sends me," they are becoming less frequent. I even hear concern about whether someone with a Mac will be able to receive email from someone with a Windows computer. I think that as the Mac becomes more popular, more people realize that there really isn't a whole lot of compatibility issues for the majority of what they want to do.
Of course that will also consume massive amount of disk space if every change was being stored for all time. And what if users DON'T want to make a change, but did by mistake? Many times just browsing documents in some programs makes some sort of change (either meta data or actual mistaken keypresses). When a user closes the document, they can 1. be notified that something was changed, and 2. choose to say "No, I didn't mean to make changes." I would argue that always saving the changes and not telling the user could often lead to incorrect versions of documents being used.
>> Bottom line, my opinion, users are not lazy, they just want to get some work done without needing the equivalent of a Bachelor's in Computer Science to get that work done.
I wouldn't say user's are lazy, but they often don't seem to care about the choices that exist in what it is they want to do. Regardless of needing a bachelor's degree in computer science, how about at least understanding the complexity of the task they've chosen to do, or at least have some appreciation for the complexity. The average user is very simple minded. They don't want to know about the things they've chosen to do. They want only to know about the small piece of it that they have patience for. In that sense, yes, they are VERY lazy.
While I agree with some particular gripes that Platt has, I think his general approach is overly simplistic, does not address the actual CAUSE to the problem, and is unrealistic. As I'm sure many have already said here, tasks people want to do are NOT often simple, especially not when dealing with all the different variations and choices there are to be made when performing the task. Oversimplifying will frustrate other users. I think that David Thomas has a much more realistic and practical appreciation for the problem. It's not about lumping all users into a simple-minded bucket and catering to them. It's about understanding the users of a particular environment and working to streamline for those users. It's about understanding the needs and truly getting to understand the needs of the user. Platt does not do this. He has a preconceived notion that all users are like his view of the least common denominator. He has a statement to "programmers": YOUR.USERS.ARE.NOT.YOU. Well, to throw that back at him... our users are not him, either.
Platt uses a lame example (of many lame examples). The "Do you want to save" prompt. If it were to be changed to "Do you want to throw your work away?" more people will hit "Yes" by mistake. I'd be willing to best that statistics would show people are more likely to make that mistake and be frustrated than there is frustration with being asked to save. He just bitches because he wants it to be HIS way (see my comment about our users not being him). Sure, we all have our frustration with how certain software works and their defaults... but try seeing past your own narrow needs, and understand what the software is actually TRYING to cater to.
It's worth going and reading the comments on his blog. Many people quite intelligently rip his views apart. And also recognize... Platt is trying to sell a book... he's shooting for the "hype" and position that will get people "talking" about his book. It just makes me a HECK of a lot more skeptical about the validity to his claims, versus his attempts to sell a book:
> How do we prevent it? > How much time (in manhours/mandays) does it take? > How much does it cost?
I think that some other things are more important to a manager: What is the risk to the business? (regulatory violation, monetary loss, etc.) How much will a breach cost? (fines, downtime, system replacement, recovery, lost business, loss of competitive advantage) What is the risk of occurance? (how likely is a breach to occur?)
In all honesty (you may disagree), I think these questions come way before those you posted. Before a manager is going to ask about how to take action, they're going to want justification that they need to bother taking action. I agree that the answers to these questions (at least in short form) should be in the executive summary of the report.
Also, for anyone interested, I recently came across this discussion... while rare, it at least does look like people have raised the question before. This link is to a discussion thread from 2004. Although, they do go in loops about a solution.
A coworker who has also been looking for options on this came across this page on JBoss's site. At first glance, it seems this is an attempt to deal with the issue first mentioned. I think it's JBoss specific though. And it's just an interface. And of course, RedHat bought them, so who knows what the future of JBoss will be.
I totally agree. Other solutions are likely better than sticking with passwords if you're wanting to clamp down even more. I think that there are degrees of security, degrees of due diligence, degrees of concern. A good question to ask is how secure does it need to be in order for the level of concern to be acceptable? In most cases, we are talking about business decision to weigh against the pros and cons of various measures of securing information. Much like people who argue that human intervention for a password entry at server start would not work... well, it is acceptable for certain situations where the business can accept that in exchange for the benefit.
Anyway. The reality is that better solutions are not always an option, whether it's cost, a need to leverage existing technology or work, a need to enact improved security in a rapid period of time, resistance to change, or simply because the boss said so. So, the question is not a debate about the merits of this option against alternatives, but rather one about implementations available. Other designs may be great and worth mentioning, but they do have other costs/benefits, and may not be viable in many situations.
Thanks. I don't have a specific need exactly. However, the question has come up a number of times in the last few months (I work as an application security analyst), and know what would be a good idea in certain environments, but not have an existing solution. I was about to just write an apache module myself (thought it'd be an interesting project to try at least once)... but just never got around to it.
In all honesty, I would think that such an feature/module would be something that many would benefit from. So, if you do code it, I hope you make it available to anyone in need. I really wish more Java app servers had something like this. I wonder if they have "module" support that are hooked into the server startup process.
Anyway... if you do get motivated to code this up, I'd be happy to chat with you about implementation details to come up with a solution that would be generic enough to work for most cases.
Hmmm... possibly a viable solution in some situations. Thanks. I'll have to look at what ssh-agent can offer and how easily it can be utilized by web apps.
Largely, I'm looking for options for different environments that I am likely to have to review, and be able to offer solutions that are viable with given constraints.
That's true. Needing a password on entry is a problem if you have a requirement of allowing a system to perform unattended reboots. In many environments, however, this is not an issue. In most cases, I rather a server NOT come back on its own if it somehow reboots on its own. If I'm not rebooting it, I question the trustworthiness of the system anyway.
Granted, it's not a solution for all... but it's good for many. This is the same problem if you're using a signed SSL certificate requiring a password for use.
Not true. This is the type of thinking that I hear so often and people justify choices saying it's the best you can do.
However, if the credentials used by apps are encrypted (cryptographically strong) and the decryption passphrase is entered only at the time of server startup, then a physical compromise of the system, backup tapes, or the harddrive will not result in a compromise of your secret information. The attacker would still need to know the passphrase used when starting up the system... which is stored somewhere else... like in a notebook in a safe... or maybe on a sticky on the monitor (lame, but still better than on the server being compromised).
I think the question people don't ask often enough (especially developers), is "Well, IF the system is compromised, what steps could be taken to keep the important stuff protected?" Steps can always be taken to ensure greater protection (never absolute, but greater).
-- "The only absolutely secure computer is the one that is disconnected, turned off, and never been used." - Me
True. There are other ways, and other technologies. Kerberos or other token based single sign-on oriented technologies. Domain logins are fine, IF you're using all MS-based technologies. But combine a system that needs to access an LDAP resource, a PostgreSQL database, AND an SQL Server database... it gets a little tricky. Ideally, identity-session type approaches would be ideal, but is unfortunately not standardized across the board, and not always an option. Heck, just look at one of the most common Java Application Servers in the commercial world today... IBM WebSphere. When you define resources, it still just sticks the password into the XML files. I believe it does a base64 (even in WAS6). I've yet to see anything about enabling true encryption on such credentials for the resource definitions. *sigh*
Yes, you are right about the clarification of what I was asking. So then, my question to you... what do you use to handle the decryption and loading of passwords in memory for your applications? is it something home grown, or something out there for public use/access. I'm just surprised at the lack of solutions for this. It seems that so many applications out there still just rely on file system permissions to protect secrets, or that combined with base64 (many PHP apps come to mind).
Anyway... I would be interested in knowing what your implementation is for this.
I think you missed the point. This is not storing passwords for the purposes of authenticating users that enter their passwords. Yes, in that case, a hash function should be used (although, why anyone would reimplement such a thing that has been implemented a billions times over is beyond me).
The situation is not with authenticating user input credentials, but with an application needing to authenticate to remote services/resources (ie. the database connection, an FTP connection, etc). In this case the web application is the thing that is logging into another resource.
What I was asking about protects much beyond using simple file permissions to protect the secrets. In your suggestion, if an application running as the web server's user (which would otherwise be needed for apps that need to read their resource credentials) were to contain a flaw allowing access to the file system, those secrets could then be disclosed. Additionally, as someone mention, a physical reboot with access to the server or a stolen hard drive, or a stolen backup tape, would result in disclosure of the secrets. Of course, if the secret is available to an app directly, it could still disclose it if badly coded, but less likely if placed in memory than the hard drive (since directory traversal vulnerabilities are still quite common mistakes by developers).
In my original post, I am specific about the solution, and was more looking for anyone knowing about implementations. The solution is to have any secrets that applications need encrypted. The passphrase needed to decrypt them would be entered at server startup (much like with signed SSL certs). The server would decrypt and load the secrets somewhere in memory for the application to access (scoping access as needed). The app could then read that memory made available specifically to it to access the secrets/credentials. No one logged into the system (assuming normal memory protections are in place) could access the secrets, even IF they had access to the user that owned the file. Backup tapes are still safe, as is system theft, since the secrets are encrypted and the decryption password is not on the system.
I'm not talking about password obfuscation. In fact, I specifically pointed out the lack of security with it (ie. the ever-common base64 encoding). That's why I suggest strong encryption, with a passphrase entered on server startup (ie. not stored on the server).
If the authentication secrets are encrypted and can only be decrypted when someone enters the correct passphrase on server startup, then a compromised system will not result in someone being able to capture the secrets.
I do think you're starting to understand my point though, since you mention having human intervention when a collection of passwords is accessed. This is what I mean. On server start, the passwords are loaded out of an encrypted file/source, loaded into memory for the processes that need them. This would only be needed on server startup though, not everytime they're needed, relying on system memory protections.
This makes an assumption about the technologies available and supported. Sure, a single sign-on, ticket-based authentication/identity management solution would be great. However, that is not always a reality. I'd even venture to say it is much less often a reality. I've known many who try to go down this path, and seem to run into problems with systems that do not support them, and then try to come up with a hack to make it work, ultimately creating vulnerabilities with their hack.
So, while it would be nice, the reason I ask about a secured key store approach is because many applications and environments do not have the option (be it due to cost, technology, or available skillset), and a keystore solution is a bit simpler and more generic, while still providing sufficient security of the credentials.
True, a password on restart does create an issue with unintentional system restarts. Although, how often do those occur? And do you really want your system becoming publicly available when it unintentionally reboots? You have the same issue with a signed SSL cert. Personally, I'd rather a system be unavailable on an unintentional reboot until it can be reviewed. In an enterprise environment, the server is likely part of a cluster or balanced group.
I'm quite familiar with OWASP. I'm planning on going to play paintball with one of the founders in a few weeks. OWASP's Top 10 is a good reference for developers that don't know what web app security really is (beyond authentication and authorization). There are a number of other good resources for software security. Gary McGraw also has some good books. Defense in Depth (as OWASP and others typically call it), is definitely the way to go. Hell, if I REALLY want a secret safe, I encrypt it twice, with two significantly different algorithms, since the odds of both algorithms having a flaw is highly unlikely... but that's for the truly paranoid.
However, OWASP, nor others actually have anything that I've seen that discusses this specific issue, other than their guidelines suggesting this would be a good idea/approach. I was hoping that SOMEONE would know of implementations that do something like this. As an application security analyst, I work with developers and try to improve their practices (along with other aspects tot he dev process). But everytime the question of resource passwords come up, I can never offer a solution that does what SHOULD be done.
I don't follow your comment about public key encryption though. If the secrets are needed by the applications (ie. a DB login that the app/app server needs for DB access), then they would be needed by services on that system.
To be fair, I believe he's referring to a Perl hash, not a cryptographic hash. I assume he's inferring a Perl specific implementation of performing a symmetric key encryption on the values of a Perl hash. However, that suggestion doesn't address the issue of the decryption key being needed.
Yes. That was my question when I read this first reply. An encryption of values is exactly what I was proposing (whether it's ain a Perl hash or any other implementation). The real key, however, is being PROMPTED for a password on server start. Anything other than prompting would require storing it on the server, and thus compromising the notion of truly securing those secrets (ie. the passwords and credentials).
I really wonder, however, if anyone actually has an implementation for this issue. I guess I'll continue reading the responses.
No, I made my assumption based on experience in stores. Most stores I've been in in Southern California (major chains) have all M-rated games behind the counter, a sign saying you have to be 18 to purchase an M-rated game, and I've actually seen them ask minors for an ID and refuse to sell them a game. This was both last year and this year. I've only been in the stores during the Holiday season.
I understand that they're not now, in light of the original post... but still odd... I guess the companies were just enforcing their own policies, or maybe some other law that may still be "unconstitutional" but politically may be better for business. *shrug*
Well, Mr Coward... I was actually basing my comment off of experience at actual stores, where most of the stores I'd been to put Rated M games behind the counter and will not sell to anyone under 18. I guess these are just store policies, but seemed consistent enough to me that it was/is a reasonable assumption that a business would do this only because a law was in place requiring it. Good to see that some major store chains are simply doing what is "right" on their own. So, ignoramus? No. Just basing assumptions (which I stated as such) on experience in stores. Man... and a couple of MY threads were marked as flame bait and this doesn't? What is slashdot coming to?
Since when does something have to be absolute in order to be effective? As mentioned, power resets can be detected. There's also the idea of non-volitile memory, where power outages would not result in a reset. And there could be another method that would, but not realted to a power outage. And if a parent checks and noticed the v-chip is disabled or that their PW is not the same, they'd be caught.
Besides, a child COULD get around it. No doubt. But that doesn't mean that most will. It's one thing to change a channel to a Skinamax show. It's another to go the full length of resetting the TV. I'm willing to bet the percentage of kids that will go this extra distance is much smaller than those that would just flip the channel, especially with 3 to 8 year olds who likely don't know how to turn off the v-chip and may not even be looking for a skin-flic, but come across one. So... if a good percentage IS benefitted by the v-chip (say 70%, for argument's sake) that sounds pretty good to me.
What I still just don't understand... why are people so against parents having an OPTION to disable such things for their kids??? I mean, seriously! Whose rights are being stepped on that this kind of protection is such a bad thing??? I simply do not understand why people fight something that provides NOTHING but good, unless maybe you're under... in which case, I really don't care about your opinion. You can't vote on these things anyway.
Slashdot Mirror
I think the original analogy is very poor, personally. It implies that the responsibility shouldn't lay with the ISPs by comparing them with manufacturers of vehicles. ISPs are much more like the people who manage and regulate the roads and toll booths. Unlike card manufacturers with bad drivers, ISPs actually in an ideal position to effectively address the problems of infected computers. In addition, they provide the resources (which belong to the ISPs) that an infected computer requires in order to be a threat to the Internet at large (and thus other computers). It is the ISPs networks that they sell. And most ISPs actually have in their contracts with their customers (at least in the US) that their networks may not be used for crime, abuse, etc. So, the ISPs likely have legal standing already to enforce the issue.
Although, turning those users "off" without warning and giving alternatives is a bit extreme. It would be nicer (as I've seen with some ISPs in the US) if the user were notified that suspicious malware-related communication is coming from their Internet connection. And if not resolved after a notification or two, disable access until the problem is resolved. Again... it's the ISPs' networks that are also responsible for the problem... not just some end user's computer.
Yeah, one problem... Anti-virus is not terribly effective against a lot of the botnets out there! They update themselves more often than most A/V companies update their DATs. And many of them are managing to root-kit the system, so even if it's cleaned, hidden processes (even from the OS) just reinfect.
I work in security. I tracked down 2 systems just this week (a number of others I provided for the local sys admins to track down) that had spam malware (detected and tracked down through outbound traffic monitoring for a 15K+ employee network). One of the systems got a clean bill of health from McAfee... well, actually, it found malware, said it cleaned it, except for some running processes. So, reboot the system... all the malware came back. The system had a root kit that can really only be cleaned by a full re-install of the system (or an off-line boot CD that could possibly clean it if properly identified). And the user who didn't know better just assumed he was clean when the A/V software said he was, and that maybe he kept getting infected... but felt safe because the McAfee "status bar" was green.
So... while it sounds like a neat theory, I am highly skeptical of it being fully successful. It would reduce things greatly to ensure people are running A/V. Although, it also forces people to run A/V, and probably only "supported vendors".... i.e. pay someone to scan your system if you want to use the Internet, in addition to you Internet access fees. Not sure how I feel about the power posturing and shifts in this scenario.
I agree that it raises question as to why one should use them, but "down time" is not the biggest threat out there, if you wanna talk loss/cost. While one's time is valuable, I'm thinking that their bank account information, passwords, etc, might be slightly more valuable to them. Personally, I think good secure end-user practices is the best protection, I do think that a good A/V program is needed.
So, while there is malware out there that is less harmful, more of the malware out there is much MORE harmful... if you disagree, please provide your financial account information, or contact me to transfer all funds to a secured off-shore account... maybe buy me a new car too! ;-)
But seriously... this is really bad, and REALLY stupid. But having no protection for most users risks damaging them in ways worse than a few hours of time to manually fix their issue. And from a corporate perspective, loss of sensitive information is a BIG deal and can cost a LOT more. And that's just talking about data loss. Being part of a botnet to help facilitate financial fraud and other badness... that's also double plus ungood... and irresponsible to not take measures to help keep your computer from playing a part in those crimes.
Anyway... I agree it raises question... but there more downside to malware than just downtime.
I completely agree. I also think that it can be attributed to a continuing breakdown of the perception that there is a gross incompatibility between Mac users and the rest of the world. While I still do field questions such as "Will I be able to open a Word file someone sends me," they are becoming less frequent. I even hear concern about whether someone with a Mac will be able to receive email from someone with a Windows computer. I think that as the Mac becomes more popular, more people realize that there really isn't a whole lot of compatibility issues for the majority of what they want to do.
Of course that will also consume massive amount of disk space if every change was being stored for all time. And what if users DON'T want to make a change, but did by mistake? Many times just browsing documents in some programs makes some sort of change (either meta data or actual mistaken keypresses). When a user closes the document, they can 1. be notified that something was changed, and 2. choose to say "No, I didn't mean to make changes." I would argue that always saving the changes and not telling the user could often lead to incorrect versions of documents being used.
-Alex
>> Bottom line, my opinion, users are not lazy, they just want to get some work done without needing the equivalent of a Bachelor's in Computer Science to get that work done.
- that-just-works-and-one-that.html
I wouldn't say user's are lazy, but they often don't seem to care about the choices that exist in what it is they want to do. Regardless of needing a bachelor's degree in computer science, how about at least understanding the complexity of the task they've chosen to do, or at least have some appreciation for the complexity. The average user is very simple minded. They don't want to know about the things they've chosen to do. They want only to know about the small piece of it that they have patience for. In that sense, yes, they are VERY lazy.
While I agree with some particular gripes that Platt has, I think his general approach is overly simplistic, does not address the actual CAUSE to the problem, and is unrealistic. As I'm sure many have already said here, tasks people want to do are NOT often simple, especially not when dealing with all the different variations and choices there are to be made when performing the task. Oversimplifying will frustrate other users. I think that David Thomas has a much more realistic and practical appreciation for the problem. It's not about lumping all users into a simple-minded bucket and catering to them. It's about understanding the users of a particular environment and working to streamline for those users. It's about understanding the needs and truly getting to understand the needs of the user. Platt does not do this. He has a preconceived notion that all users are like his view of the least common denominator. He has a statement to "programmers": YOUR.USERS.ARE.NOT.YOU. Well, to throw that back at him... our users are not him, either.
Platt uses a lame example (of many lame examples). The "Do you want to save" prompt. If it were to be changed to "Do you want to throw your work away?" more people will hit "Yes" by mistake. I'd be willing to best that statistics would show people are more likely to make that mistake and be frustrated than there is frustration with being asked to save. He just bitches because he wants it to be HIS way (see my comment about our users not being him). Sure, we all have our frustration with how certain software works and their defaults... but try seeing past your own narrow needs, and understand what the software is actually TRYING to cater to.
It's worth going and reading the comments on his blog. Many people quite intelligently rip his views apart. And also recognize... Platt is trying to sell a book... he's shooting for the "hype" and position that will get people "talking" about his book. It just makes me a HECK of a lot more skeptical about the validity to his claims, versus his attempts to sell a book:
http://suckbusters2.blogspot.com/2006/12/web-site
-Alex
> How do we prevent it?
> How much time (in manhours/mandays) does it take?
> How much does it cost?
I think that some other things are more important to a manager:
What is the risk to the business? (regulatory violation, monetary loss, etc.)
How much will a breach cost? (fines, downtime, system replacement, recovery, lost business, loss of competitive advantage)
What is the risk of occurance? (how likely is a breach to occur?)
In all honesty (you may disagree), I think these questions come way before those you posted. Before a manager is going to ask about how to take action, they're going to want justification that they need to bother taking action. I agree that the answers to these questions (at least in short form) should be in the executive summary of the report.
-Alex
Also, for anyone interested, I recently came across this discussion... while rare, it at least does look like people have raised the question before. This link is to a discussion thread from 2004. Although, they do go in loops about a solution.
4 751&messageID=2718194
http://forum.java.sun.com/thread.jspa?threadID=55
http://wiki.jboss.org/wiki/Wiki.jsp?page=JaasSecur ityDomain
A coworker who has also been looking for options on this came across this page on JBoss's site. At first glance, it seems this is an attempt to deal with the issue first mentioned. I think it's JBoss specific though. And it's just an interface. And of course, RedHat bought them, so who knows what the future of JBoss will be.
I totally agree. Other solutions are likely better than sticking with passwords if you're wanting to clamp down even more. I think that there are degrees of security, degrees of due diligence, degrees of concern. A good question to ask is how secure does it need to be in order for the level of concern to be acceptable? In most cases, we are talking about business decision to weigh against the pros and cons of various measures of securing information. Much like people who argue that human intervention for a password entry at server start would not work... well, it is acceptable for certain situations where the business can accept that in exchange for the benefit.
Anyway. The reality is that better solutions are not always an option, whether it's cost, a need to leverage existing technology or work, a need to enact improved security in a rapid period of time, resistance to change, or simply because the boss said so. So, the question is not a debate about the merits of this option against alternatives, but rather one about implementations available. Other designs may be great and worth mentioning, but they do have other costs/benefits, and may not be viable in many situations.
Thanks. I don't have a specific need exactly. However, the question has come up a number of times in the last few months (I work as an application security analyst), and know what would be a good idea in certain environments, but not have an existing solution. I was about to just write an apache module myself (thought it'd be an interesting project to try at least once)... but just never got around to it.
In all honesty, I would think that such an feature/module would be something that many would benefit from. So, if you do code it, I hope you make it available to anyone in need. I really wish more Java app servers had something like this. I wonder if they have "module" support that are hooked into the server startup process.
Anyway... if you do get motivated to code this up, I'd be happy to chat with you about implementation details to come up with a solution that would be generic enough to work for most cases.
Hmmm... possibly a viable solution in some situations. Thanks. I'll have to look at what ssh-agent can offer and how easily it can be utilized by web apps.
Largely, I'm looking for options for different environments that I am likely to have to review, and be able to offer solutions that are viable with given constraints.
That's true. Needing a password on entry is a problem if you have a requirement of allowing a system to perform unattended reboots. In many environments, however, this is not an issue. In most cases, I rather a server NOT come back on its own if it somehow reboots on its own. If I'm not rebooting it, I question the trustworthiness of the system anyway.
Granted, it's not a solution for all... but it's good for many. This is the same problem if you're using a signed SSL certificate requiring a password for use.
Not true. This is the type of thinking that I hear so often and people justify choices saying it's the best you can do.
However, if the credentials used by apps are encrypted (cryptographically strong) and the decryption passphrase is entered only at the time of server startup, then a physical compromise of the system, backup tapes, or the harddrive will not result in a compromise of your secret information. The attacker would still need to know the passphrase used when starting up the system... which is stored somewhere else... like in a notebook in a safe... or maybe on a sticky on the monitor (lame, but still better than on the server being compromised).
I think the question people don't ask often enough (especially developers), is "Well, IF the system is compromised, what steps could be taken to keep the important stuff protected?" Steps can always be taken to ensure greater protection (never absolute, but greater).
--
"The only absolutely secure computer is the one that is disconnected, turned off, and never been used." - Me
True. There are other ways, and other technologies. Kerberos or other token based single sign-on oriented technologies. Domain logins are fine, IF you're using all MS-based technologies. But combine a system that needs to access an LDAP resource, a PostgreSQL database, AND an SQL Server database... it gets a little tricky. Ideally, identity-session type approaches would be ideal, but is unfortunately not standardized across the board, and not always an option. Heck, just look at one of the most common Java Application Servers in the commercial world today... IBM WebSphere. When you define resources, it still just sticks the password into the XML files. I believe it does a base64 (even in WAS6). I've yet to see anything about enabling true encryption on such credentials for the resource definitions. *sigh*
Yes, you are right about the clarification of what I was asking. So then, my question to you... what do you use to handle the decryption and loading of passwords in memory for your applications? is it something home grown, or something out there for public use/access. I'm just surprised at the lack of solutions for this. It seems that so many applications out there still just rely on file system permissions to protect secrets, or that combined with base64 (many PHP apps come to mind).
Anyway... I would be interested in knowing what your implementation is for this.
I think you missed the point. This is not storing passwords for the purposes of authenticating users that enter their passwords. Yes, in that case, a hash function should be used (although, why anyone would reimplement such a thing that has been implemented a billions times over is beyond me).
The situation is not with authenticating user input credentials, but with an application needing to authenticate to remote services/resources (ie. the database connection, an FTP connection, etc). In this case the web application is the thing that is logging into another resource.
Sorry, but I completely disagree.
What I was asking about protects much beyond using simple file permissions to protect the secrets. In your suggestion, if an application running as the web server's user (which would otherwise be needed for apps that need to read their resource credentials) were to contain a flaw allowing access to the file system, those secrets could then be disclosed. Additionally, as someone mention, a physical reboot with access to the server or a stolen hard drive, or a stolen backup tape, would result in disclosure of the secrets. Of course, if the secret is available to an app directly, it could still disclose it if badly coded, but less likely if placed in memory than the hard drive (since directory traversal vulnerabilities are still quite common mistakes by developers).
In my original post, I am specific about the solution, and was more looking for anyone knowing about implementations. The solution is to have any secrets that applications need encrypted. The passphrase needed to decrypt them would be entered at server startup (much like with signed SSL certs). The server would decrypt and load the secrets somewhere in memory for the application to access (scoping access as needed). The app could then read that memory made available specifically to it to access the secrets/credentials. No one logged into the system (assuming normal memory protections are in place) could access the secrets, even IF they had access to the user that owned the file. Backup tapes are still safe, as is system theft, since the secrets are encrypted and the decryption password is not on the system.
I'm not talking about password obfuscation. In fact, I specifically pointed out the lack of security with it (ie. the ever-common base64 encoding). That's why I suggest strong encryption, with a passphrase entered on server startup (ie. not stored on the server).
If the authentication secrets are encrypted and can only be decrypted when someone enters the correct passphrase on server startup, then a compromised system will not result in someone being able to capture the secrets.
I do think you're starting to understand my point though, since you mention having human intervention when a collection of passwords is accessed. This is what I mean. On server start, the passwords are loaded out of an encrypted file/source, loaded into memory for the processes that need them. This would only be needed on server startup though, not everytime they're needed, relying on system memory protections.
This makes an assumption about the technologies available and supported. Sure, a single sign-on, ticket-based authentication/identity management solution would be great. However, that is not always a reality. I'd even venture to say it is much less often a reality. I've known many who try to go down this path, and seem to run into problems with systems that do not support them, and then try to come up with a hack to make it work, ultimately creating vulnerabilities with their hack.
So, while it would be nice, the reason I ask about a secured key store approach is because many applications and environments do not have the option (be it due to cost, technology, or available skillset), and a keystore solution is a bit simpler and more generic, while still providing sufficient security of the credentials.
True, a password on restart does create an issue with unintentional system restarts. Although, how often do those occur? And do you really want your system becoming publicly available when it unintentionally reboots? You have the same issue with a signed SSL cert. Personally, I'd rather a system be unavailable on an unintentional reboot until it can be reviewed. In an enterprise environment, the server is likely part of a cluster or balanced group.
I'm quite familiar with OWASP. I'm planning on going to play paintball with one of the founders in a few weeks. OWASP's Top 10 is a good reference for developers that don't know what web app security really is (beyond authentication and authorization). There are a number of other good resources for software security. Gary McGraw also has some good books. Defense in Depth (as OWASP and others typically call it), is definitely the way to go. Hell, if I REALLY want a secret safe, I encrypt it twice, with two significantly different algorithms, since the odds of both algorithms having a flaw is highly unlikely... but that's for the truly paranoid.
However, OWASP, nor others actually have anything that I've seen that discusses this specific issue, other than their guidelines suggesting this would be a good idea/approach. I was hoping that SOMEONE would know of implementations that do something like this. As an application security analyst, I work with developers and try to improve their practices (along with other aspects tot he dev process). But everytime the question of resource passwords come up, I can never offer a solution that does what SHOULD be done.
I don't follow your comment about public key encryption though. If the secrets are needed by the applications (ie. a DB login that the app/app server needs for DB access), then they would be needed by services on that system.
-Alex
To be fair, I believe he's referring to a Perl hash, not a cryptographic hash. I assume he's inferring a Perl specific implementation of performing a symmetric key encryption on the values of a Perl hash. However, that suggestion doesn't address the issue of the decryption key being needed.
Yes. That was my question when I read this first reply. An encryption of values is exactly what I was proposing (whether it's ain a Perl hash or any other implementation). The real key, however, is being PROMPTED for a password on server start. Anything other than prompting would require storing it on the server, and thus compromising the notion of truly securing those secrets (ie. the passwords and credentials).
I really wonder, however, if anyone actually has an implementation for this issue. I guess I'll continue reading the responses.
-Alex
No, I made my assumption based on experience in stores. Most stores I've been in in Southern California (major chains) have all M-rated games behind the counter, a sign saying you have to be 18 to purchase an M-rated game, and I've actually seen them ask minors for an ID and refuse to sell them a game. This was both last year and this year. I've only been in the stores during the Holiday season.
I understand that they're not now, in light of the original post... but still odd... I guess the companies were just enforcing their own policies, or maybe some other law that may still be "unconstitutional" but politically may be better for business. *shrug*
Well, Mr Coward... I was actually basing my comment off of experience at actual stores, where most of the stores I'd been to put Rated M games behind the counter and will not sell to anyone under 18. I guess these are just store policies, but seemed consistent enough to me that it was/is a reasonable assumption that a business would do this only because a law was in place requiring it. Good to see that some major store chains are simply doing what is "right" on their own. So, ignoramus? No. Just basing assumptions (which I stated as such) on experience in stores. Man... and a couple of MY threads were marked as flame bait and this doesn't? What is slashdot coming to?
Since when does something have to be absolute in order to be effective? As mentioned, power resets can be detected. There's also the idea of non-volitile memory, where power outages would not result in a reset. And there could be another method that would, but not realted to a power outage. And if a parent checks and noticed the v-chip is disabled or that their PW is not the same, they'd be caught.
Besides, a child COULD get around it. No doubt. But that doesn't mean that most will. It's one thing to change a channel to a Skinamax show. It's another to go the full length of resetting the TV. I'm willing to bet the percentage of kids that will go this extra distance is much smaller than those that would just flip the channel, especially with 3 to 8 year olds who likely don't know how to turn off the v-chip and may not even be looking for a skin-flic, but come across one. So... if a good percentage IS benefitted by the v-chip (say 70%, for argument's sake) that sounds pretty good to me.
What I still just don't understand... why are people so against parents having an OPTION to disable such things for their kids??? I mean, seriously! Whose rights are being stepped on that this kind of protection is such a bad thing??? I simply do not understand why people fight something that provides NOTHING but good, unless maybe you're under... in which case, I really don't care about your opinion. You can't vote on these things anyway.