From: Volker G. <vo...@m-...> - 2010-11-18 03:39:55
|
chr...@nv... <chr...@nv...> schrieb: > MD5 protected ?. Do you mean this one > http://en.wikipedia.org/wiki/Digest_access_authentication > > This is definitively better. Agreed. > Our did you develop your own mechanism ?. If you did, please add a > salt to the password before hashing, e. g. calculate md5(password > concatenated with username) to prevent dictionary attacks. Just a quick note, because this is a common misunderstanding: Adding a salt does _not_ solve the security issue. You need at least HMAC. Everything below that is snake-oil, as the attacker can simply resend the whole hash (including the salt) to authenticate, without ever needing to know the plain text password. The salt is only useful to avoid recovering the plain text password, which is only an issue because people often reuse their password for other services. > I plan to make the authentication modules pluggable to avoid "nasty" > constructs. Indeed, that's what standards like HTTP Digest Auth are created for. :-) > About https: > The performance penalty depends on the chosen cipher suite between > the client and the server. > For key establishment asymmetric cyphers are used and they are always > expensive. After agreement on the session key, symmetric cyphers are > used, e.g. AES --> fast, 3DES --> not so fast. Please correct me if I'm wrong, but this sounds like premature optimization to me. The WMS/WFS requests usually involve database queries, geographical filters and the like, which are a lot more expensive than encryption. Also note that the data transfer rate is often the bottleneck, so people "waste" even more CPU power for things like data compression. More often than not, the "performance penalty" is just a lame excuse for not getting the SSL/CA stuff right. ;-) Greets, Volker -- Volker Grabsch ---<<(())>>--- |