Security issue: Passwords stored in cookie

Discussions about Z-Way software and Z-Wave technology in general
Post Reply
Provo
Posts: 112
Joined: 19 Oct 2016 19:54

Security issue: Passwords stored in cookie

Post by Provo » 27 Oct 2016 18:47

I just noticed that the Z-Way gateway actually stores the user's credentials in cleartext – both the username and the password – in a cookie when selecting "Remember me" on login.

This is seriously not good from a security standpoint. The standard and sane way of doing persistent sessions is to store the session id (like, for instance, this phpBB forum does), not the complete login credentials of the user. Extracting the username and password client side is now as easy as getting the client to run "JSON.parse(decodeURIComponent(document.cookie.split(';')[3]).split('=')[1])".

You should fix this issue by only saving the session id, and probably do a security update fairly quickly.

maros
Posts: 103
Joined: 05 Apr 2014 11:21

Re: Security issue: Passwords stored in cookie

Post by maros » 29 Oct 2016 12:53

Z-Way 2.2.4 on Raspi B | My Zway GitHub repos | Amazon Wishlist to support module development

Provo
Posts: 112
Joined: 19 Oct 2016 19:54

Re: Security issue: Passwords stored in cookie

Post by Provo » 30 Oct 2016 11:02

Ok. So passwords are stored on the server in cleartext, saved in a cookie in cleartext and thus passed to the server many times during a session, and there's no SSL support for encrypting this traffic. So unless one has set up nginx for SSL support oneself or is consistently using find,z-wave.me, anyone on the same network with a packet sniffer or with temporary access to your configjson-XXX.json will have unrestricted access to control your z-wave-devices whenever he or she pleases.

I like Z-Way in many ways, but these are fairly serious security issues. Passwords has to be stored as hashes using strong hashing algorithms, and persistent sessions/logins has to be done with storing session ids, not credentials. To be perfectly honest, these things are so obvious and well known that I'm starting to wonder what other security issues the system might be having.

User avatar
PoltoS
Posts: 4846
Joined: 26 Jan 2011 19:36

Re: Security issue: Passwords stored in cookie

Post by PoltoS » 30 Oct 2016 11:38

Agree about password in Cookie. We will change this.

As for passwords in config.json, I can not agree. Look on all Unix systems. Once you have access to /etc/shadow, you have all hashes and it is a matter of 10 minutes to get your password. Even more, having access to your filesystem one can install additional s/w and Z-Way is not to blame about this. This is same with all other systems where password is usually one word (this is the case for most user defined passwords). We have discussed this with the community a long time ago and found that storing passwords in hash is a perception of security which is even more severe.

Provo
Posts: 112
Joined: 19 Oct 2016 19:54

Re: Security issue: Passwords stored in cookie

Post by Provo » 30 Oct 2016 17:21

It's good that you will fix the cookie issue.

Regarding storing passwords as cleartext, as I replied on the github issue (https://github.com/Z-Wave-Me/z-way-issues/issues/83), it is not a matter of 10 minutes to find the password from the hash if the hashing algorithm and password is good. You can't just drop security just because you think most users will create unsecure passwords. If you do a proper hashing, brute forcing of a password of decent entropy will be practically impossible. Which means that if anyone should gain temporary access to config, they wouldn't be able to use the hash to log in.

What I didn't write in that reply, is that I don't think your /etc/shadow analogy holds water for at least two reasons:

1) You have to have root access for reading /etc/shadow, while any user can read the config.
2) The passwords in /etc/shadow are hashed.

Storing passwords as hashes is not just security theater creating a false sense of security, it is a very real, basic and effective security measure. The login-mechanism is the lock. The password is the key. The hash is not the key. The hash is correlated to the key, but if done properly it's correlated only in a way which makes it practically impossible to use for figuring out the key. That's why you store the hash, and not the password itself.

Post Reply