A thought about the first user experience

[Dean Roddey]

One big advantage of our own security is that we can (and do now) support non-Windows clients. We couldn't do that if we depended on Windows login as proof of access.

The setting of the password when resetting an account is just something I need to the time to do. It's pretty piddly in the larger scheme of things so it's not been done yet. But it will get done.

Security is pretty fundamentally ingrained in the whole product, so it's not going to go away or become optional. Doing anything that would change the system requires a secuirty token, else the product couldn't be secure. And if just passing some parameter or setting some flag would turn it off, the security would be worth nothing since any hacker could do that with a client, pull up to your house with a tablet, connect, and change your system.

It's easy enough to use environmentally based login info, or command line if you want, it works either way.

[LesAuber]

I'm with Dean. If I had kids or roommates I'd want access password protected.

[znelbok]

One big advantage of our own security is that we can (and do now) support non-Windows clients. We couldn't do that if we depended on Windows login as proof of access.

but you are connecting to a server on a windows machine which could do the pass through for authentication could you not?

I am no expert, but is there not many examples of this already existing, hence things like Raduis servers etc were implemented.

Regardless, what ever is said here, its not going to change anything. My view that sercurtity should be optional will never change, nor will CQC ever change the way its is done now.

We just have to hope that Dean has implemented true security (ie passwords etc not passed to the server from the client in the clear and passwords are not stored, e.g. only a hash of the password).

Mick

[Dean Roddey]

but you are connecting to a server on a windows machine which could do the pass through for authentication could you not?Mick

Not very safey. Our login procedure is completely safe over the net, because it doesn't have to pass any actual useful information back and forth. If we had to have the server log on for you, we'd have to pass the actual user name and password over. So it's much safer using our own system. Otherwise we'd have to use some sort of VPN scheme or SSL or whatnot just to protect the login procedure.

[znelbok]

you can pass a hash instead which does make it safe(er).

The clinet hashes the password, sends the hash and the server compares the hash to its list (in my simple terms).

Passwords should never ever be sent.

[Dean Roddey]

You don't even want to send the hash directly either, which our current scheme doesn't. It doesn't exchange anything other than randomly generated values.