Re: Plaintext passwords in Geronimo plans and config files
Actually, the keystorePassword for the Tomcat SSL Web Connector is indeed getting encrypted by the server in the config.xml, so it seems that the encryption for passwords in config.xml is built-in by default. [EMAIL PROTECTED] wrote on 02-22-2007 01:24:24 PM: On 2/22/07, David Jencks [EMAIL PROTECTED] wrote: I haven't found the code that does this, but I think that it encrypts config.xml rather than any plans. I could be very wrong although since plans aren't needed at runtime I can't see how encryption could be applied to them. I think it's in util or one of the alphabetically late modules in the list. :) I'm pretty sure we could find it by looking at the code that saves config.xml property values. Anyway, I assume that encryption in config.xml is what we're talking about here -- that is, encryption in the server config files after the application is deployed, not encryption in the deployment plan that's used only once. But it should be possible to hook in the encryption to saved plans or any other places where we have data that should be concealed. As you pointed out it's not really safe against a skilled attacker with access to the server configuration, but it could provide the level of no plain text passwords in server configuration assurance. Thanks, Aaron On 2/22/07, Aman Nanner/MxI Technologies [EMAIL PROTECTED] wrote: Hi, I have noticed that passwords in plans and configuration files in Geronimo (1.2-beta) are not encrypted by the server, and remain in plaintext. For example, passwords in: 1) Datasource connector plans 2) ActiveMQ connector plans 3) TomcatWebSSL Keystore passwords 4) Geronimo properties realm passwords Having these plaintext passwords in these configuration files pose an inherent security risk that would prevent us from deploying Geronimo out to customer sites. Are there any plans to have all these passwords encrypted? Thanks, Aman _ _ * This message is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. Unless you are the addressee (or authorized to receive for the addressee), you may not use, copy or disclose the message or any information contained in the message. If you have received this message in error, please advise the sender by reply e-mail , and delete the message, or call (collect) 001 613 747 4698. * __ * This message is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. Unless you are the addressee (or authorized to receive for the addressee), you may not use, copy or disclose the message or any information contained in the message. If you have received this message in error, please advise the sender by reply e-mail , and delete the message, or call (collect) 001 613 747 4698. *
Re: Plaintext passwords in Geronimo plans and config files
David Jencks [EMAIL PROTECTED] wrote on 02-22-2007 12:01:11 PM: On Feb 22, 2007, at 6:12 AM, Aman Nanner/MxI Technologies wrote: Hi, I have noticed that passwords in plans and configuration files in Geronimo (1.2-beta) are not encrypted by the server, and remain in plaintext. For example, passwords in: 1) Datasource connector plans 2) ActiveMQ connector plans 3) TomcatWebSSL Keystore passwords 4) Geronimo properties realm passwords Having these plaintext passwords in these configuration files pose an inherent security risk that would prevent us from deploying Geronimo out to customer sites. Are there any plans to have all these passwords encrypted? 1-3 of these are in module plans, which are unneeded after the module has been deployed into a car file. So, don't distribute the plans but the car files. That's an interesting idea, but we need to have the module plans distributed as part of the EAR, as the customer will need to redeploy our application if we provide them with custom software integration pieces at a later point in time. Currently with our customers that use JBoss or Weblogic, we provide scripts as part of our distribution that will unpack an EAR, add new custom EJB jars or WARs, and redeploy the EAR. We would like to do the same with Geronimo. What we could do, after deployment of our EAR, is encrypt the passwords in the plans ourselves using a script. When the customer needs to redeploy the EAR, we could have a script that would decrypt the passwords into plaintext, redeploy the EAR, and then re-encrypt the passwords after deployment. For (4), I'd suggest you use a non-toy authentication method such as ldap. Properties file based authentication is mainly intended for experimentation. We currently have our own custom realm that uses a DB for authentication. This custom realm is application-scoped within our EAR. Probably what we'll do is make the custom realm system-scoped, and use it in cases where the properties realm was being used. You can probably figure out how to extract passwords from the car files if you work hard enough. However, if you think this is a problem I'd like to remind you that security against someone with physical access to a machine or complete file system access is pretty much impossible: look at the recent HDDVD crack. In other words, if you distribute software to customer machines, you should assume that if they really want to they can extract any passwords you try to hide in the software. There are still safeguards that are used in the event physical access is breached. For example, passwords are usually hashed using SHA-1 or MD5 algorithm when stored in a file or database. In this event, someone who has physical access to the machine (be it an intruder or the database administrator) cannot determine what any individual's password is, since it is one-way hashed. Of course, one-way hashes are useless for the deployment plans unless the hashes can be provided to the underlying system. For example, if ActiveMQ accepted password hashes, then the passwords could be hashed in the RAR plan, and these hashes could be provided to ActiveMQ. Otherwise, a reversible encryption algorithm would have to be used to encrypt the passwords (so that they could be decrypted before being sent to the underlying system). I've wondered if it would be appropriate to provide a mode whereby you need a password to start geronimo or you supply a command line password to unlock the keystores on startup, but haven't got much beyond wondering if it would actually provide any additional security beyond that available on a properly secured server. From our experience, there are many customers that freak out if they see plaintext passwords ANYWHERE on a system, even if it is secured. I do realize your point about properly securing the server, but there exist certain security standards (EAL, for example) that likely would require visible passwords to be encrypted or hashed. Thanks, Aman __ * This message is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. Unless you are the addressee (or authorized to receive for the addressee), you may not use, copy or disclose the message or any information contained in the message. If you have received this message in error, please advise the sender by reply e-mail , and delete the message, or call (collect) 001 613 747 4698. *
Re: Plaintext passwords in Geronimo plans and config files
There is some built-in encryption available. My recollection was that the server tried to apply it to settings with password in the name, but it may have changed in 1.2-beta. Thanks, Aaron On 2/22/07, Aman Nanner/MxI Technologies [EMAIL PROTECTED] wrote: Hi, I have noticed that passwords in plans and configuration files in Geronimo (1.2-beta) are not encrypted by the server, and remain in plaintext. For example, passwords in: 1) Datasource connector plans 2) ActiveMQ connector plans 3) TomcatWebSSL Keystore passwords 4) Geronimo properties realm passwords Having these plaintext passwords in these configuration files pose an inherent security risk that would prevent us from deploying Geronimo out to customer sites. Are there any plans to have all these passwords encrypted? Thanks, Aman __ * This message is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. Unless you are the addressee (or authorized to receive for the addressee), you may not use, copy or disclose the message or any information contained in the message. If you have received this message in error, please advise the sender by reply e-mail , and delete the message, or call (collect) 001 613 747 4698. *
Re: Plaintext passwords in Geronimo plans and config files
On Feb 22, 2007, at 9:23 AM, Aman Nanner/MxI Technologies wrote: David Jencks [EMAIL PROTECTED] wrote on 02-22-2007 12:01:11 PM: On Feb 22, 2007, at 6:12 AM, Aman Nanner/MxI Technologies wrote: Hi, I have noticed that passwords in plans and configuration files in Geronimo (1.2-beta) are not encrypted by the server, and remain in plaintext. For example, passwords in: 1) Datasource connector plans 2) ActiveMQ connector plans 3) TomcatWebSSL Keystore passwords 4) Geronimo properties realm passwords Having these plaintext passwords in these configuration files pose an inherent security risk that would prevent us from deploying Geronimo out to customer sites. Are there any plans to have all these passwords encrypted? 1-3 of these are in module plans, which are unneeded after the module has been deployed into a car file. So, don't distribute the plans but the car files. That's an interesting idea, but we need to have the module plans distributed as part of the EAR, as the customer will need to redeploy our application if we provide them with custom software integration pieces at a later point in time. Currently with our customers that use JBoss or Weblogic, we provide scripts as part of our distribution that will unpack an EAR, add new custom EJB jars or WARs, and redeploy the EAR. We would like to do the same with Geronimo. You probably want to use similar methods for all the app servers you support, but for geronimo you might be able to package the additional pieces as plugins and distribute them in that form, which would once again eliminate the need to distribute plans. What we could do, after deployment of our EAR, is encrypt the passwords in the plans ourselves using a script. When the customer needs to redeploy the EAR, we could have a script that would decrypt the passwords into plaintext, redeploy the EAR, and then re-encrypt the passwords after deployment. Another approach for the db/jms connectors that I like although I'm not sure if its completely tested is to leave out the user/pw from the plans and use Subject based authentication. With this approach you'd add a login module to the security realm that would insert appropriate UserPassword credentials into the subject for each db/jms you need to use. When you need a connection to a db/jms these credentials would be used instead of those from the db/jms connector plan. I think this is plausible right now for users who are logged in but I'm not sure it would work for default subjects for unauthenticated users. For (4), I'd suggest you use a non-toy authentication method such as ldap. Properties file based authentication is mainly intended for experimentation. We currently have our own custom realm that uses a DB for authentication. This custom realm is application-scoped within our EAR. Probably what we'll do is make the custom realm system-scoped, and use it in cases where the properties realm was being used. You can probably figure out how to extract passwords from the car files if you work hard enough. However, if you think this is a problem I'd like to remind you that security against someone with physical access to a machine or complete file system access is pretty much impossible: look at the recent HDDVD crack. In other words, if you distribute software to customer machines, you should assume that if they really want to they can extract any passwords you try to hide in the software. There are still safeguards that are used in the event physical access is breached. For example, passwords are usually hashed using SHA-1 or MD5 algorithm when stored in a file or database. In this event, someone who has physical access to the machine (be it an intruder or the database administrator) cannot determine what any individual's password is, since it is one-way hashed. Of course, one-way hashes are useless for the deployment plans unless the hashes can be provided to the underlying system. For example, if ActiveMQ accepted password hashes, then the passwords could be hashed in the RAR plan, and these hashes could be provided to ActiveMQ. Otherwise, a reversible encryption algorithm would have to be used to encrypt the passwords (so that they could be decrypted before being sent to the underlying system). Well, if say AMQ accepted hashes, that just means that the passwords are less likely to be remembered by a human the hashed value has become a password. I've wondered if it would be appropriate to provide a mode whereby you need a password to start geronimo or you supply a command line password to unlock the keystores on startup, but haven't got much beyond wondering if it would actually provide any additional security beyond that available on a properly secured server. From our experience, there are many customers that freak out if they see plaintext passwords ANYWHERE on a system, even if it is secured. I do realize
Re: Plaintext passwords in Geronimo plans and config files
On Feb 22, 2007, at 9:35 AM, Aaron Mulder wrote: There is some built-in encryption available. My recollection was that the server tried to apply it to settings with password in the name, but it may have changed in 1.2-beta. I haven't found the code that does this, but I think that it encrypts config.xml rather than any plans. I could be very wrong although since plans aren't needed at runtime I can't see how encryption could be applied to them. thanks david jencks Thanks, Aaron On 2/22/07, Aman Nanner/MxI Technologies [EMAIL PROTECTED] wrote: Hi, I have noticed that passwords in plans and configuration files in Geronimo (1.2-beta) are not encrypted by the server, and remain in plaintext. For example, passwords in: 1) Datasource connector plans 2) ActiveMQ connector plans 3) TomcatWebSSL Keystore passwords 4) Geronimo properties realm passwords Having these plaintext passwords in these configuration files pose an inherent security risk that would prevent us from deploying Geronimo out to customer sites. Are there any plans to have all these passwords encrypted? Thanks, Aman _ _ * This message is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. Unless you are the addressee (or authorized to receive for the addressee), you may not use, copy or disclose the message or any information contained in the message. If you have received this message in error, please advise the sender by reply e-mail , and delete the message, or call (collect) 001 613 747 4698. *
Re: Plaintext passwords in Geronimo plans and config files
Another approach for the db/jms connectors that I like although I'm not sure if its completely tested is to leave out the user/pw from the plans and use Subject based authentication. With this approach you'd add a login module to the security realm that would insert appropriate UserPassword credentials into the subject for each db/jms you need to use. When you need a connection to a db/jms these credentials would be used instead of those from the db/jms connector plan. Is there any documentation on this? I don't think I could use it anyhow though, since our login module is DB-based, and so the login module itself needs a pre-authenticated DB connection. Well, if say AMQ accepted hashes, that just means that the passwords are less likely to be remembered by a human the hashed value has become a password. I don't think the hashed value wouldn't need to be known or remembered by any human as a human would always configure AMQ or an AMQ client with a plaintext password. The client would hash the value and send the hashed value to AMQ, and then AMQ would recognize that the password is hashed. If AMQ were itself to store the password as hashed, it would simply do a direct comparison. Otherwise, it would hash its stored password, and compare that hash with the hash received from the client. I think this is definitely a topic that needs further consideration. My preference is that we come up with a solution that actually provides some level of security rather than relying on obscurity and as a result my bias is to object to schemes that simply obscure information. They could still be useful and a good idea :-) The hashing mechanism provides actual security, rather than just obscurity, since a hash is one-way by definition (a plaintext password cannot be recovered from a hash). That being said, I think that obscurity is part of the security process. Even if something can still be theoretically cracked, it's always good to make it that much harder to crack. An analogy is a lock for your bicycle; somebody that's determine to steal your bike will likely be able to break the lock, but nobody would argue that a bicycle lock doesn't add a great deal of protection. Maybe a better analogy is how Java code is obfuscated; theoretically it could still be reverse-engineered, but it's much harder. Thanks, Aman __ * This message is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. Unless you are the addressee (or authorized to receive for the addressee), you may not use, copy or disclose the message or any information contained in the message. If you have received this message in error, please advise the sender by reply e-mail , and delete the message, or call (collect) 001 613 747 4698. *
Re: Plaintext passwords in Geronimo plans and config files
On 2/22/07, David Jencks [EMAIL PROTECTED] wrote: I haven't found the code that does this, but I think that it encrypts config.xml rather than any plans. I could be very wrong although since plans aren't needed at runtime I can't see how encryption could be applied to them. I think it's in util or one of the alphabetically late modules in the list. :) I'm pretty sure we could find it by looking at the code that saves config.xml property values. Anyway, I assume that encryption in config.xml is what we're talking about here -- that is, encryption in the server config files after the application is deployed, not encryption in the deployment plan that's used only once. But it should be possible to hook in the encryption to saved plans or any other places where we have data that should be concealed. As you pointed out it's not really safe against a skilled attacker with access to the server configuration, but it could provide the level of no plain text passwords in server configuration assurance. Thanks, Aaron On 2/22/07, Aman Nanner/MxI Technologies [EMAIL PROTECTED] wrote: Hi, I have noticed that passwords in plans and configuration files in Geronimo (1.2-beta) are not encrypted by the server, and remain in plaintext. For example, passwords in: 1) Datasource connector plans 2) ActiveMQ connector plans 3) TomcatWebSSL Keystore passwords 4) Geronimo properties realm passwords Having these plaintext passwords in these configuration files pose an inherent security risk that would prevent us from deploying Geronimo out to customer sites. Are there any plans to have all these passwords encrypted? Thanks, Aman _ _ * This message is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. Unless you are the addressee (or authorized to receive for the addressee), you may not use, copy or disclose the message or any information contained in the message. If you have received this message in error, please advise the sender by reply e-mail , and delete the message, or call (collect) 001 613 747 4698. *
