|
Author
|
Message
|
|
A Sha
|
Thursday 23 October 2003 5:22:13 pm
See also RFC 2069.
|
|
Hans Melis
|
Friday 24 October 2003 12:32:55 am
I wouldn't call this an eZ publish security problem. About any site with logins works that way. Even a HTTP 403 with a WWW-Authenticate header transmits passwords in plain text. One way to secure it is using HTTPS, but at a performance cost. Second thing, do you use FTP and/or POP3? Two more protocols that transmit passwords in plain text. This is hardly a problem with the eZ publish software, but rather an internet problem.
--
Hans
Hans
http://blog.hansmelis.be
|
|
A Sha
|
Friday 24 October 2003 12:44:10 am
It is a problem that many internet protocols and applications have. But not all applications have this problem. Amazon.com doesn't have it, I am sure. It is possible to avoid this problem. EZPublish could avoid it, even without using SSL. (No, I do not use ftp and pop3. I use ssh, scp, and apop. Apop is not perfect but it's better than pop.)
|
|
Tony Wood
|
Friday 24 October 2003 1:05:10 am
Hi, Its about risk and the lengths you want to go to to protect your site.
http://www.w3.org/MarkUp/html-spec/html-spec_8.html#SEC8.1.2.2
Passes the userid and password in clear text, if you are concerned that your data is at risk then you need to ensure all login fields are protected by 128bit + SSL encryption.
The question you need to ask yourself are
1. Who am i protecting myself from?
2. What is the value of the data
3. What laws relate to data protection in my servers location.
4. What is my budget and how much am i prepared to spend on security.
5. What other risk exist in my server/client environment.
Its a fun and vital exercise to do, as you will find that the password encryption is sometimes the least of your worries as you can control that. The things that scare me are the things out of my control.
But most of the time you know the route to the server via traceroute so you can make a informed decision. ie. dont use a none ssl connection on a public or cybercafe connection. Most admin interfaces are protected by SSL so it not to much of a problem.
btw Amazone uses SSL in their form <form action=https://www.amazon.com/exec/obidos/flex-sign-in-done/xx method=POST>
and they still use <input name=password type=password size=10 maxlength=20> This is not really an eZ issue more of a general issue about secuirty. I hope this helps Tony
Tony Wood : twitter.com/tonywood
Vision with Technology
Experts in eZ Publish consulting & development
Power to the Editor!
Free eZ Training : http://www.VisionWT.com/training
eZ Future Podcast : http://www.VisionWT.com/eZ-Future
|
|
A Sha
|
Friday 24 October 2003 1:25:36 am
Hi Tony. This is also about risk and the lengths that the eZPublish creators want to go to protect eZPublish users, the risk of damage to the eZPublish reputation if someone hacks an eZPublish site, and the tradeoffs that the eZPublish creators want to offer their users (the people that use eZPublish to build web sites). Ideally each and every eZPublish user should not have to go through the same hackery in order to solve the same problem. I know that <input> data is transferred in the clear; that is why I wrote the original post.
It is not necessary to use SSL to protect the input from the attack I mentioned. RFC 2069 (and its later version RFC 2617) is designed for exactly this. There may be other solutions as well. The issue is not how to fix it. The issue is that it be fixed.
I have done an exercise similar to the one you suggested. Having people steal the identities of users on my site is not acceptable. I, and most users, want security on the web by default, not security by, "I fixed the application I'm using."
|
|
Paul Forsyth
|
Friday 24 October 2003 1:40:03 am
I am a little confused here. How does you secure the input tag in html? Server security i understand but that isn't anything to do with ez publish. paul
|
|
A Sha
|
Friday 24 October 2003 1:55:45 am
It is probably not possible to directly secure the <input> tag in HTML. Indirect methods like SSL could be used. The problem to be solved here (if it is to be solved) is that the user name and password are transmitted in clear text. The solution could involve using SSL, or RFC 2617, or something else -- I do not know. I have never used the method described in RFC 2617 so I do not know how it is typically done. But I do know that RFC 2617 has been implemented and that it should be possible to use it.
|
|
Paul Forsyth
|
Friday 24 October 2003 2:04:18 am
I don't know the rfcs' you mention but it seems to me the barriers are in the client itself. sure, the server can use ssl when serving you the pages, thats one way. the other is to secure the client and i don't know if current browsers support these rfcs'. again, this isn't an ez publish problem. paul
|
|
Tony Wood
|
Friday 24 October 2003 2:07:21 am
I agree if a system can be securer by default then it should be so.
I wonder what requirements and issues arrise from using a hash password from the client.
Browser (requires javascript, version, platform etc), Server software etc Do you have any examples? issues? etc. If its possible to implement on a shared server environment so to make it accessible to the eZ audience. Then it should be looked at. btw: I notice www.vignette.com use a hash password system. tony
Tony Wood : twitter.com/tonywood
Vision with Technology
Experts in eZ Publish consulting & development
Power to the Editor!
Free eZ Training : http://www.VisionWT.com/training
eZ Future Podcast : http://www.VisionWT.com/eZ-Future
|
|
Balazs Halasy
|
Friday 24 October 2003 2:08:57 am
When you're talking about RFC 2617, I believe you're referring to the "Digest" authentication method over HTTP. Well, as far as I know (please, correct me if I'm wrong), there is poor/"various" browser support for this auth. method; not to mention that it is as almost as easy to hack (once sniffed) as plaintext. It only requires a bit more effort from the attacker. Balazs
|
|
A Sha
|
Friday 24 October 2003 2:13:00 am
I'd suggest taking a look at the beginning of RFC 2617, and at the section on security (section 4). The text is pretty accessible and should make some of these issues clearer.
Here's another page about the html name/password in cleartext vulnerability: http://www.technicalinfo.net/papers/CustomHTMLAUthentication.html
I haven't read this page yet, but it looks quite informative. Googling will find other information. One thing to realize is that this problem is ubiquitous on the web. I do not believe that everyone simply accepts this vulnerability and moves on. It is possible for eZPublish to eliminate or at least reduce the severity of this vulnerability. This is possible is because of certain built-in capabilities in web browsers and the protocols they use.
|
|
A Sha
|
Friday 24 October 2003 2:15:20 am
Hi Balazs. I do not how how widely implemented RFC 2617 is. I suspect wide implementation, but possibly it is not widely implemented and one would have to do a custom implementation like described in the URL I gave in the previous post. I do not think it is correct that RFC 2617 is almost as easily broken as a cleartext transmission of a name/password pair.
|
|
Balazs Halasy
|
Friday 24 October 2003 2:21:16 am
As far as I know, digest authentication sends the server a one way hash of the username:password pair calculated with a time sensitive, server supplied salt value. In theory, the use of a salt value means that every authentication attempt with the same username:password pair will result in a unique hash and is not vulnerable to replay attacks. However, some people claim that this doesn't stop them from hacking a site.
The digest authentication mechanism was developed to provide a general use, simple implementation, access control that could be used over unencrypted channels. As already pointed out, it is not as secure as Kerberos or client-side private-key authentication mechanisms. In addition; it is also important to note that only the username:pasword is protected by the hashing mechanism and that without the use of an encrypting medium such as SSL all retrieved documents will still be visible to all parties with access to network traffic. Say, when a user changes his/her password, it will then be transferred in plain text. Last, but not least: as I pointed out in my last reply, I believe that there are still several browsers out there that don't support the digest authentication method. If necessary: you should secure your eZ publish site by pumping all traffic through SSL. Balazs
|
|
Tony Wood
|
Friday 24 October 2003 2:30:55 am
Hi Sha, Thanks for the info references. What i was trying to get at that the articles don't refer to is how to implement with the current browsers and shared server environments out that.
>> I do not believe that everyone simplyaccepts this vulnerability and moves on.
We do not accept the vulnerability, for sites that require it we implement PKI that helps make the site securer. To have these conversations is healthy. It would be useful if you see any other areas that could be reviewed and if necessary improved? Thanks Tony
Tony Wood : twitter.com/tonywood
Vision with Technology
Experts in eZ Publish consulting & development
Power to the Editor!
Free eZ Training : http://www.VisionWT.com/training
eZ Future Podcast : http://www.VisionWT.com/eZ-Future
|
|
A Sha
|
Friday 24 October 2003 2:38:26 am
Tony, I think that this link that I mentioned before discusses implementing schemes in html with existing browsers: http://www.technicalinfo.net/papers/CustomHTMLAUthentication.html
I am an eZPublish newbie so I don't know too much about other areas to review yet. Thanks for the interest though. I will keep my eyes open. Is there somewhere that documents how you use PKI? I would enjoy reading more about this. Balazs: I agree with everything you said, except that I don't know how widely RFC 2617 is implemented, and I disagree with this: "if necessary: you should secure your eZ publish site by pumping all traffic through SSL." This is security by "I got around the app's weakness", not security by default. Many eZPublish users will not even know this vulnerability exists, and will not even know to fix it. I still believe that it is possible to eZPublish to do much better than it is doing now, and that it should. Just because I cannot provide precise implementation details doesn't refute this. It just means that we have reached the limit of my knowledge. Some research may be required to find a good solution. I am certain that it's possible to do better than what's done now, without a prohibitive development effort and without prohibitive incompatibility. I am not asking for perfection here.
|
|
A Sha
|
Friday 24 October 2003 2:48:57 am
Oh, one more thing -- the client should never sign anything without using its own nonce (client nonce). (I don't know if RFC 2617 ensures this or not.)
|
|
Tony Wood
|
Friday 24 October 2003 3:00:03 am
Heres the info on PKI http://www.openca.org/ Nice to have you on the forums. Tony
Tony Wood : twitter.com/tonywood
Vision with Technology
Experts in eZ Publish consulting & development
Power to the Editor!
Free eZ Training : http://www.VisionWT.com/training
eZ Future Podcast : http://www.VisionWT.com/eZ-Future
|
|
A Sha
|
Friday 24 October 2003 3:07:58 am
Thanks Tony. I will take a look. Here's a page that purports to use a Javascript implementation of RFC 2617 (for the client side): http://hudsonfog.com/user-login.html
|
|
Tony Wood
|
Friday 24 October 2003 3:19:08 am
Nice example... Thanks
Tony Wood : twitter.com/tonywood
Vision with Technology
Experts in eZ Publish consulting & development
Power to the Editor!
Free eZ Training : http://www.VisionWT.com/training
eZ Future Podcast : http://www.VisionWT.com/eZ-Future
|
|
Paul Forsyth
|
Friday 24 October 2003 5:14:54 am
The javascript library used is here: http://pajhome.org.uk/site/legal.html
|
