I've seen in the XCML files that passwords and credentials e.g. for directory entries are always stored in clear text. Is there a way to use encrypted passwords? Bet regaerds Peter
On Thursday 16 October 2008 20:40:29 Peter P GMX wrote:
I've seen in the XCML files that passwords and credentials e.g. for directory entries are always stored in clear text. Is there a way to use encrypted passwords?
As mentioned on this page; http://wiki.freeswitch.org/wiki/XML_User_Directory_Guide you can use a1-hash values instead. hads
Hi, Yes, you can just return an a1-hash instead of a password. The a1-hash consists of md5(username:domain:password) see: http://wiki.freeswitch.org/wiki/XML_User_Directory_Guide regards, Leon On Oct 16, 2008, at 9:40 AM, Peter P GMX wrote:
I've seen in the XCML files that passwords and credentials e.g. for directory entries are always stored in clear text. Is there a way to use encrypted passwords?
Bet regaerds Peter
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Thanks, I got it for the directory password (a1-hash). But what about the voicemail-password and the passwords stored for external gateways? Best regards Peter Leon de Rooij schrieb:
Hi,
Yes, you can just return an a1-hash instead of a password.
The a1-hash consists of md5(username:domain:password)
see: http://wiki.freeswitch.org/wiki/XML_User_Directory_Guide
regards,
Leon
On Oct 16, 2008, at 9:40 AM, Peter P GMX wrote:
I've seen in the XCML files that passwords and credentials e.g. for directory entries are always stored in clear text. Is there a way to use encrypted passwords?
Bet regaerds Peter
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Honestly is that much of an issue? Your machine should be secure enough to not allow anyone but the user FreeSWITCH is running as read the configs in the first place. I'm not even that paranoid :P /b On Oct 20, 2008, at 9:09 AM, Peter P GMX wrote:
Thanks,
I got it for the directory password (a1-hash).
But what about the voicemail-password and the passwords stored for external gateways?
Best regards Peter
Hello Brian, i have learned im my life that any server can be compromized if anyone uses enough effort to hack it. Thus I simply try to prevent storing passwords in clear text. I am actually trying to setup a secure system with TLS/SRTP and handling clear text passwords didn't really fit into this concept. Best regards Peter Brian West schrieb:
Honestly is that much of an issue? Your machine should be secure enough to not allow anyone but the user FreeSWITCH is running as read the configs in the first place. I'm not even that paranoid :P
/b
On Oct 20, 2008, at 9:09 AM, Peter P GMX wrote:
Thanks,
I got it for the directory password (a1-hash).
But what about the voicemail-password and the passwords stored for external gateways?
Best regards Peter
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
On 10/20/08, Peter P GMX <Prometheus001@gmx.net> wrote:
Hello Brian,
i have learned im my life that any server can be compromized if anyone uses enough effort to hack it. Thus I simply try to prevent storing passwords in clear text. I am actually trying to setup a secure system with TLS/SRTP and handling clear text passwords didn't really fit into this concept.
Best regards Peter
If your server is compromised and they can read your config files they can read the file store, db, etc and have access to everything (VM?) that pin would have access to. -- Kristian Kielhofner http://blog.krisk.org http://www.submityoursip.com http://www.astlinux.org http://www.star2star.com
I think we can agree that the more passwords are available in clear text the more problems we will have if a system is compromized. Therefore it's common practise to not store passwords in clear text. In our case we use xml-curl to store the directory data in a database for a distributed freeswitch network. I simply try to avoid having a database with clear text passwords. VM-Passwords may not be a bigger problem, but gateway passwords and conference pins are. One way is of course to encrypt the passwords with e.g. OpenSSL/RSA, store it the database and decrypt it on the fly when it is needed. This moves the security implementation to the application side with some backdraws, as passwords can be retrieved with the decryption key and passwords are transferred through the network (of course via SSL) and the passwords are in the logs. This is how we do it for the time being. Another idea, as I propose, is not to store the passwords but hashes. To be honest: I do not understand this discussion. It would be wise to store passwords in an encrypted way. I have seen compromized servers on the client's side in the last years and security threats will even increase in the future. The more we protect our sensible data the safer the system will be for the future. There is a growing number of companies in Germany (even the very big ones as Deutsche Telecom) who recently had to tell their customers that a huge amount of sensible data was lost. I am not asking for doing it right now, but I would love to have it somehow on the roadmap for the future. Best regards Peter Kristian Kielhofner schrieb:
On 10/20/08, Peter P GMX <Prometheus001@gmx.net> wrote:
Hello Brian,
i have learned im my life that any server can be compromized if anyone uses enough effort to hack it. Thus I simply try to prevent storing passwords in clear text. I am actually trying to setup a secure system with TLS/SRTP and handling clear text passwords didn't really fit into this concept.
Best regards Peter
If your server is compromised and they can read your config files they can read the file store, db, etc and have access to everything (VM?) that pin would have access to.
if you want to test latest trunk i added code that *should* let you auth the vm using the same a1-hash also we added an "md5" api command to mod_commands so you can use it in your own apps. ${md5(some data)} On Mon, Oct 20, 2008 at 4:43 PM, Peter P GMX <Prometheus001@gmx.net> wrote:
I think we can agree that the more passwords are available in clear text the more problems we will have if a system is compromized. Therefore it's common practise to not store passwords in clear text. In our case we use xml-curl to store the directory data in a database for a distributed freeswitch network. I simply try to avoid having a database with clear text passwords. VM-Passwords may not be a bigger problem, but gateway passwords and conference pins are.
One way is of course to encrypt the passwords with e.g. OpenSSL/RSA, store it the database and decrypt it on the fly when it is needed. This moves the security implementation to the application side with some backdraws, as passwords can be retrieved with the decryption key and passwords are transferred through the network (of course via SSL) and the passwords are in the logs. This is how we do it for the time being. Another idea, as I propose, is not to store the passwords but hashes.
To be honest: I do not understand this discussion. It would be wise to store passwords in an encrypted way. I have seen compromized servers on the client's side in the last years and security threats will even increase in the future. The more we protect our sensible data the safer the system will be for the future. There is a growing number of companies in Germany (even the very big ones as Deutsche Telecom) who recently had to tell their customers that a huge amount of sensible data was lost.
I am not asking for doing it right now, but I would love to have it somehow on the roadmap for the future.
Best regards Peter
Kristian Kielhofner schrieb:
On 10/20/08, Peter P GMX <Prometheus001@gmx.net> wrote:
Hello Brian,
i have learned im my life that any server can be compromized if anyone uses enough effort to hack it. Thus I simply try to prevent storing passwords in clear text. I am actually trying to setup a secure system with TLS/SRTP and handling clear text passwords didn't really fit into this concept.
Best regards Peter
If your server is compromised and they can read your config files they can read the file store, db, etc and have access to everything (VM?) that pin would have access to.
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
just added vm-a1-hash as well that you can use to override the standard a1 hash for voicemail use only. Mike On Oct 20, 2008, at 7:27 PM, Anthony Minessale wrote:
if you want to test latest trunk i added code that *should* let you auth the vm using the same a1-hash also we added an "md5" api command to mod_commands so you can use it in your own apps.
${md5(some data)}
Thanks for your support for the vm-passwords. The most important part for us however is having hashed passwords for external gateway definitions (we have a lot) and securing pins for conferences. Do we have a chance to add this also? In our environment DTMF is of course transported via SRTP so this is more secure (although the key exchange by SDES is known to have security issues, as rtp streams may be replayed by a 3rd party, there is no replay prevention mechanism in SDES and therefore also not in freeswitch, hein?). Best regards Peter Michael Jerris schrieb:
just added vm-a1-hash as well that you can use to override the standard a1 hash for voicemail use only.
Mike
On Oct 20, 2008, at 7:27 PM, Anthony Minessale wrote:
if you want to test latest trunk i added code that *should* let you auth the vm using the same a1-hash also we added an "md5" api command to mod_commands so you can use it in your own apps.
${md5(some data)}
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Its called TLS... /b On Oct 21, 2008, at 4:30 PM, Peter P GMX wrote:
In our environment DTMF is of course transported via SRTP so this is more secure (although the key exchange by SDES is known to have security issues, as rtp streams may be replayed by a 3rd party, there is no replay prevention mechanism in SDES and therefore also not in freeswitch, hein?).
OK, I got it. The replay vulnerability only happens when key exchange is done via unencrypted SIP. I understand that with TLS the Invite message cannot be replayed as it cannot be seen in clear text. Brian West schrieb:
Its called TLS...
/b
On Oct 21, 2008, at 4:30 PM, Peter P GMX wrote:
In our environment DTMF is of course transported via SRTP so this is more secure (although the key exchange by SDES is known to have security issues, as rtp streams may be replayed by a 3rd party, there is no replay prevention mechanism in SDES and therefore also not in freeswitch, hein?).
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
the sofia library we depend on requires you to feed it plain passwords for outbound auth. We would have to pressure them to expose a way for us to pre-hash them. As an alternative, you can always use xml-curl + https url to fetch the configs from your db on the fly over a secure connection but that won't stop the hacker from running gcore on fs and finding them in the ram somewhere just like if someone wants to break into your house he can just take a chainsaw and cut a hole in the side and walk in. I'll ask the guy next time i talk to him. On Tue, Oct 21, 2008 at 3:30 PM, Peter P GMX <Prometheus001@gmx.net> wrote:
Thanks for your support for the vm-passwords.
The most important part for us however is having hashed passwords for external gateway definitions (we have a lot) and securing pins for conferences. Do we have a chance to add this also?
In our environment DTMF is of course transported via SRTP so this is more secure (although the key exchange by SDES is known to have security issues, as rtp streams may be replayed by a 3rd party, there is no replay prevention mechanism in SDES and therefore also not in freeswitch, hein?).
Best regards Peter
Michael Jerris schrieb:
just added vm-a1-hash as well that you can use to override the standard a1 hash for voicemail use only.
Mike
On Oct 20, 2008, at 7:27 PM, Anthony Minessale wrote:
if you want to test latest trunk i added code that *should* let you auth the vm using the same a1-hash also we added an "md5" api command to mod_commands so you can use it in your own apps.
${md5(some data)}
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
Certainly offering support for hashed passwords has benefits and as you mentioned can be done using something other than the flat file XML directory format and decoding on the fly. I think one reason it hasn't been looked at as a major issue yet is voicemail and conference passwords are generally only numbers so they can be dialed over a phone, even an 8 digit password is 10^8 combination which is not a whole lot of hashes to brute force, so compromising even one way passwords would not be a major feat. It may deter a compromised machine from giving up its secrets but it certainly is a very narrow frame of protection. ~Mitch On Mon, Oct 20, 2008 at 5:43 PM, Peter P GMX <Prometheus001@gmx.net> wrote:
I think we can agree that the more passwords are available in clear text the more problems we will have if a system is compromized. Therefore it's common practise to not store passwords in clear text. In our case we use xml-curl to store the directory data in a database for a distributed freeswitch network. I simply try to avoid having a database with clear text passwords. VM-Passwords may not be a bigger problem, but gateway passwords and conference pins are.
One way is of course to encrypt the passwords with e.g. OpenSSL/RSA, store it the database and decrypt it on the fly when it is needed. This moves the security implementation to the application side with some backdraws, as passwords can be retrieved with the decryption key and passwords are transferred through the network (of course via SSL) and the passwords are in the logs. This is how we do it for the time being. Another idea, as I propose, is not to store the passwords but hashes.
To be honest: I do not understand this discussion. It would be wise to store passwords in an encrypted way. I have seen compromized servers on the client's side in the last years and security threats will even increase in the future. The more we protect our sensible data the safer the system will be for the future. There is a growing number of companies in Germany (even the very big ones as Deutsche Telecom) who recently had to tell their customers that a huge amount of sensible data was lost.
I am not asking for doing it right now, but I would love to have it somehow on the roadmap for the future.
Best regards Peter
Kristian Kielhofner schrieb:
On 10/20/08, Peter P GMX <Prometheus001@gmx.net> wrote:
Hello Brian,
i have learned im my life that any server can be compromized if anyone uses enough effort to hack it. Thus I simply try to prevent storing passwords in clear text. I am actually trying to setup a secure system with TLS/SRTP and handling clear text passwords didn't really fit into this concept.
Best regards Peter
If your server is compromised and they can read your config files they can read the file store, db, etc and have access to everything (VM?) that pin would have access to.
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
especially if you are not using srtp and you can just sniff the dtmf =D On Mon, Oct 20, 2008 at 6:29 PM, Mitch Capper <mitch.capper@gmail.com>wrote:
Certainly offering support for hashed passwords has benefits and as you mentioned can be done using something other than the flat file XML directory format and decoding on the fly. I think one reason it hasn't been looked at as a major issue yet is voicemail and conference passwords are generally only numbers so they can be dialed over a phone, even an 8 digit password is 10^8 combination which is not a whole lot of hashes to brute force, so compromising even one way passwords would not be a major feat. It may deter a compromised machine from giving up its secrets but it certainly is a very narrow frame of protection.
~Mitch
On Mon, Oct 20, 2008 at 5:43 PM, Peter P GMX <Prometheus001@gmx.net>wrote:
I think we can agree that the more passwords are available in clear text the more problems we will have if a system is compromized. Therefore it's common practise to not store passwords in clear text. In our case we use xml-curl to store the directory data in a database for a distributed freeswitch network. I simply try to avoid having a database with clear text passwords. VM-Passwords may not be a bigger problem, but gateway passwords and conference pins are.
One way is of course to encrypt the passwords with e.g. OpenSSL/RSA, store it the database and decrypt it on the fly when it is needed. This moves the security implementation to the application side with some backdraws, as passwords can be retrieved with the decryption key and passwords are transferred through the network (of course via SSL) and the passwords are in the logs. This is how we do it for the time being. Another idea, as I propose, is not to store the passwords but hashes.
To be honest: I do not understand this discussion. It would be wise to store passwords in an encrypted way. I have seen compromized servers on the client's side in the last years and security threats will even increase in the future. The more we protect our sensible data the safer the system will be for the future. There is a growing number of companies in Germany (even the very big ones as Deutsche Telecom) who recently had to tell their customers that a huge amount of sensible data was lost.
I am not asking for doing it right now, but I would love to have it somehow on the roadmap for the future.
Best regards Peter
Kristian Kielhofner schrieb:
On 10/20/08, Peter P GMX <Prometheus001@gmx.net> wrote:
Hello Brian,
i have learned im my life that any server can be compromized if anyone uses enough effort to hack it. Thus I simply try to prevent storing passwords in clear text. I am actually trying to setup a secure system with TLS/SRTP and handling clear text passwords didn't really fit into this concept.
Best regards Peter
If your server is compromised and they can read your config files they can read the file store, db, etc and have access to everything (VM?) that pin would have access to.
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
participants (8)
-
Anthony Minessale
-
Brian West
-
Hadley Rich
-
Kristian Kielhofner
-
Leon de Rooij
-
Michael Jerris
-
Mitch Capper
-
Peter P GMX