Is iCam Broker Server secure? I am concerned about my user name /password !!!

[kb1990]

After I read several threads on this forum (http://skjm.com/forum/index.php?topic=70.0), I am very concerned about how secure of my webcam.

As explained in the forum, iCam is using P2P technology, and need an iCam Broker Server to manange the connection. iCamSource sends my user name, passward, etc. to this server for registration. Since the broker server manages the Internet connection, it must also store my IP address.

I have no idea where this server is hosted, is it secure? If someone can access it, or hack it, that will be really bad. Some one can just login to my home computer and see my home camera!

I do not care if someone can retrieve a song or two from my computer, but I am REALLY concerned if someone can peep into my webcam and see my home.

I did not realize iCamSource will send my user name and password out, to be stored somewhere I don't know! 

I start to wonder if I should leave my webcam always on 24/7?

I am new to this forum, anyone else here has this concern?

K.

[Stefan]

kb1990 - I just want to clarify that your login and password are never sent to our iCam Broker Server. Both iCam and the iCamSource use your login and password to generate a 40-character random-looking SHA-1 hash string, and that is what is actually sent to the server.

You can read more about the SHA-1 hash function here: http://en.wikipedia.org/wiki/SHA_hash_functions

[kb1990]

Hi, Stefan:

Thanks for the explanation, which is kind of confusing. Looks to me that the user name and passward are encrypted first, BUT the information is still sent out to the broker server.

And when my iPhone need to connect to my computer, it must talk to the broker server first, right? Based on my user name, the server can find out where is my computer. I guess the server must have stored the information on my user name and password, and IP address.

[Stefan]

kb1990 - The login and password are not encrypted and then sent to the server. The login and password are never sent to the server. The hash is merely a unique representation of the login and password. You can't reverse the hash function and somehow extract the login and password from it. The hash function was designed to specifically to not work that way.

http://en.wikipedia.org/wiki/Cryptographic_hash_function

It is standard practice to store the hash of a password instead of the password itself. We do one better by keeping track of a hash of both the login and the password.

[aberrant]

Sorry, still not getting it.  If there's no cryptographic nonce that's exchanged between the source and the icam app, and the authentication is being brokered by your servers based on a static hash of the username and password, then what's to prevent you (or someone who's compromised your server) from just replaying the hash that is sent?

[Stefan]

Sorry, still not getting it.  If there's no cryptographic nonce that's exchanged between the source and the icam app, and the authentication is being brokered by your servers based on a static hash of the username and password, then what's to prevent you (or someone who's compromised your server) from just replaying the hash that is sent?

The direct authentication between iCam and the iCamSource also includes an additional hash that is not sent to the iCam Broker Server.

I suppose it could be though of as a "public" and "private" hash, both of which are derived from the iCam login and password. The "public" one is used to identify iCamSources and iCam clients on the same network to the iCam Broker Server, and the "private" hash is only sent between iCam and the iCamSource. If the "private" hash sent by iCam to the iCamSource is incorrect then the iCamSource will refuse the connection.

[aberrant]

Thanks for the quick reply.  Is there a whitepaper that discusses this in more detail for those of us who need a bit more assurance that the security issues have been thoroughly hashed out (pun intended)?

For example, it sounds as if you're adding extra source to the hash for the "private" exchange.  Is this source static?  Upon what is it based?  Who knows how it's derived?

[Stefan]

We have not written any whitepapers on the subject, but I can most definitely answer any questions that you may have.

The "public" hash is the SHA-1 of the login+password, and the "private" hash is the SHA-1 of the password+login. If you know the login and the password then you will be able to generate both hashes, but knowing just the "public" hash does not mean you are able to determine the "private" one.

[thedeeman]

using test/test I am actually watching some guy's camera I have no idea where it is.  it's his basement and I can see he has been dealing with leaks.
not secure.  simple as that.

[Jay]

Security with a login and password is only as strong as the login and password you decide to use.  Clearly, the login "test" and the password "test" is very easy for other people to guess and therefore, that particular login and password combination is not secure.  Make sure to use a login and password that can't be easily guessed by other people.

[OUAnthony]

thedeeman...using your deeply flawed logic, nothing is secure. You guessed someone's username AND password (that they obviously didn't intend to keep secret). Not sure how you connect that to the program not being secure. Stefan, you did a great job explaining the password/hash process.

[Stefan]

Stefan, you did a great job explaining the password/hash process.

Thanks!