All traffic to and from babblevoice is carried via SIP and its companion RTP. We don’t encrypt any of the data between any end point. SIP communications are secured via usernames and password. A phone never sends a username or password in a call. An MD5 hash of the username and password along with a random string is sent by the phone, so anyone who tries to hijack this information will not be able to use it.
As part of creating the username and password in the babblevoice console, we auto generate a strong password to be used in phones. This strength is considered strong, so that a brute force attacker would not reasonably be able to guess it. It is the end users responsibility if they choose a weaker password to use.
Most phones are provisioned via HTTPS, usernames and passwords are sent and secured via HTTPS and we configure our servers to use TLS to encrypt and not SSL to ensure confidence in security.
Cisco phones use HTTP to download provisioning information, however the configuration files are encrypted using AES 256 CBC which is considered a strong encryption method. We use a strong encryption key which only the phone knows.
All calls which are recorded on the babblevoice system are stored in Amazon S3. Amazon have there own security policies on this product. When a user requests a download of a recorded file, babblevoice issues a URL to that file which is valid for 4 hours. These URLs are only issued via our API over HTTPS (see the notes above) so cannot be spied on.
Since day one, babblevoice has use open ID to authenticate users who wish to login and configure babblevoice. This is because