Karl Goetz wrote: > > Please, do not build infrastructures on weak bases! > > Is the channel logged? or did the discussion happen in #savannah? (If > the latter I can read my logs).
The discussion was at the #flouzo channel. Attached the log. The main discussion about the OpenID security was from line 175 to the end. It is not too much interesting, but anyway ...
<davi> Notes: <davi> * In gnuherds we auto-register entities (emails) if they are not yet registered. We send a email link to verify it is not a bot, etc. <davi> * We do not want to use OpenID due to delegating the authentication process is very risky since the security point of view. It is even risky if we are talking about _money_. <davi> For example, the integration of the authentication of Savannah and GNU Herds will not be realized using OpenID because of such cause, security. <dachary> ah <dachary> I was not aware of any security risks related to openid <dachary> davi: what are they ? <davi> Being the authentication process delegated to an external entity all depend of such external entity. <davi> If the system maintenance of such <davi> external entity is weak the users passwords can be stolen, etc. <davi> Besides, <davi> being the authentication process externalized <davi> the system can be attacked via "DNS spoofing" of the external authentication system. <davi> <dachary> I completly understand this. <dachary> But if someone is worried about this, openid can be limited to an openid provider installed on the same LAN and controled by him. <davi> If the authentication process it done in our system are us who have to care about all security, and we eliminate the "DNS spoofing" attack path because all the system is internal to us. <dachary> If you are relaxed about security, then you can accept any openid provider on the planet. <dachary> If you have security concerns you can limit the openid provider for example.org to openid.example.org <davi> Yes, OpenID can be limited to one or our LAN, for example enabling Savannah as OpenID provider. We talked with Beuc about it <davi> but at the end we decided just do an integration without OpenID <dachary> Yes. Or any openid provider installed on a controled machine. <dachary> For savannah it makes sense because Savannah already has a user base. <dachary> I agree. <davi> not if such machine have to be integrated via the use of DNS. DNS is weak, you know. <dachary> I don't understand. <davi> dachary write: "Yes. Or any openid provider installed on a controled machine." -- not if such machine have to be integrated via the use of DNS. DNS is weak, you know. <dachary> I still don't understand. You say that having example.org and openid.example.org is a security threat ? <davi> Could leave this decision open to discussion? <dachary> Oh ! We did not decide to implement *only* openid :-) We decided to go for openid for now because it's the path of least resistance. <dachary> There really is no other standard for authentication. <dachary> Am I making sense ? davi ? <davi> Yes if the communication is done through a public Internet link. We could use a VPN channel to avoid it. We are proposing the use of OpenVPN or similar as path of communication between the Savannah and GNU Herds machines <dachary> I don't think openid must be used for savannah/gnuherds <dachary> I'm not opposed to it <dachary> But I agree with you that it's not necessary <davi> IMO OpenID is a weak authentication standard since the security point of view. It is only good if the OpenID server is trusted, 100% secure etc. Else the better is manage the authentication in your system. The authentication is the door to the system, if it is weak all the system is weak. <dachary> I agree. <dachary> Do you think we must not support openid at all for the flouzometer ? <davi> Yep, I think we are to avoid OpenID in the integration because it is not needed and we do not want to promote the OpenID use. OpenID is good for blogs, etc. but not to something serious as money. <davi> Do you know any bank which allow you to login via OpenID? <davi> Yes, IMHO we should not support OpenID in flouzometer, but instead auto-register the user via email verification. <davi> You just send an email with a link and wait it click in it to verify. <davi> Note that this method is as much easy to the user as OpenID because he has just to fill a field, the email. Same with OpenID, one field, no more. * davi follow reading the log <dachary> how do you do that when integrating the flouzometer in mediawiki ? <davi> Why is it needed integrate with mediawiki? <davi> IMHO it is obviously not needed <dachary> I don't know. If people want to add a donation button in a mediawiki. Or wordpress. <dachary> the flouzometer can be integrated in a variety of context <davi> ah, I understand now; such integration <dachary> yes ? <davi> I am not sure, but I think the flouzometer would act as the interface and direct to the proper manager, as paypal buttons direct to the paypal site * davi follow reading the log <dachary> you mean we should design the flouzometer as web pages interactions instead of the integrated applet direction we took so far ? <davi> I am not sure yet. It is something me must follow thinking about. <davi> Notes: <davi> * <antoviaque> Ah, we need to have the names listed -- Yes, and do not list it if the user request an anonymous donation. But this could be a feature added later. <davi> <dachary> yes ? <dachary> ah <dachary> yes, noted, thanks <davi> If the user is already a registered user, with Name MiddleName etc. filled, and he does not request explicitly do an anonymous donation pledge, such Name MiddleName can be shown in the donation list <davi> <dachary> yes, absolutely, this is part of the specifications <davi> <dachary> antoviaque: I know you're making a big big effort on yourself to keep it to the bare minimum. I appreciate that, really. <dachary> :-) <davi> I absolutely agree that the design must the more simple and secure one. <davi> <davi> <dachary> antoviaque: the minimum is when the money flows from the donator to the recipient without legal trouble. <davi> ^ I would add: "and without fees" :) <davi> <davi> The micro-donation feature raises the fees problem. So micro-donations advice to allowing the use of a system to avoid fees. <dachary> "without fees" : do you know a bank / paypal equivalent that has no fees ? I dream about it but I don't think it's a realistic minimum ;-) <dachary> davi: I see what you mean. <dachary> Do you think it must be a feature of flouzometer ? <davi> I absolutely think it must! but maybe it is not needed in the first flouzometer version. Such feature can wait a little more. <davi> You can follow the short discussion at this thread: http://lists.gnu.org/archive/html/gnuherds-app-dev/2008-12/msg00036.html <davi> * Integrated micro-donations -- Importance <davi> * Integrated micro-donations -- Implementation <davi> (all just a proposal to take into account, as usual) <davi> <dachary> So the flouzometer would be 1) a web service to manage donations, 2) a user interface to make a donation, 3) a system to implement micro donations on top of a regular payment system <dachary> davi: is it what you suggest ? <proppy> back <proppy> davi: backlog ?: <davi> dachary, Yes something like that. We can follow thinking about it <dachary> do you think 3) can be developped by someone independently ? or does it have to be integrated in the flouzometer for some reason ? <davi> You can take a look too at: "GNU Herds virtual bank -- proposal" which try to avoid paying taxes, which would make impossible offer the microdonations feature. Link at: http://lists.gnu.org/archive/html/gnuherds-app-dev/2008-07/msg00018.html <dachary> I see it as a different banking system, as paypal or visa. I don't yet understand why it must be integrated. <dachary> Can you explain to me please ? <davi> To support micro-donations we have to be able to avoid the transfers taxes. With the virtual-bank feature we could avoid all transfers except the initial one which load the money in the virtual bank and the final one which retire the money from the virtual bank. Let me try to look for a screenshot of the system <dachary> reading the posts <dachary> Let me rephrase my question (forgive me if I'm slow) : <dachary> the flouzometer allows user U to donate X thru payment system S <dachary> S can be paypal, visa <dachary> if there is a micro-payment system without tax, in what respect is it different from paypal and visa (except for the fact that it does not take a commission) <dachary> the flouzometer will have a paypal adapter <davi> It is just another S: paypal, visa, micro-payment system (without tax) <dachary> the flouzometer will have a visa adapter <davi> cool, cool <dachary> the flouzometer will have a micro-payment adapter <dachary> ok <dachary> now <davi> paypal and visa is a must. <dachary> do you think 3) can be developped by someone independently ? or does it have to be integrated in the flouzometer for some reason ? <davi> I think 3) will not be ready for the first version because the micro-payment platform will not be ready for that time. so we do not have to care about it right now. Now we can care about paypal, and maybe visa too <davi> <dachary> ok <dachary> Thanks for clarifying this. <dachary> I thought you said we must modify the flouzometer design to integrate micro-donations without taxes and I was confused. <davi> no, no, we must delay the addition of such feature. * proppy installing mediawiki on ouzo <dachary> So the flouzometer would be 1) a web service to manage donations, 2) a user interface to make a donation, 3) a set of plugins for various payment systems, including micro-donations <dachary> davi: does this match your recommendation ? <davi> yes <dachary> Great ! <davi> We can follow talking about how integrate * davi follow reading the log <dachary> One last thing about openid : are you positive your recommendation is to avoid using it anywhere ? <davi> yes, avoid promoting OpenID <davi> because of <davi> it is only secure if you control the OpenID server and the transaction are not done on public Internet link, and <davi> in such conditions OpenID lose its sense to be used, IMHO. * davi follows reading the log <dachary> this is a tough decision as it creates a lot of additional work <dachary> would it be acceptable to use openid for testing purposes ? <dachary> write a user base mechanisme for the sake of testing the flouzometer is a little overkill <proppy> http://ouzo.flouzo.net/mediawiki/index.php/Main_Page installed <dachary> bbl <dachary> back * davi follows reading the log yet <davi> <antoviaque> It's GPL (don't know which version), so it means modifications to this code could not be AGPL right? <davi> I think GPL v3 is compatible with AGPL v3. <davi> but not GPL v2. * davi ends reading the log. Some notes more when dachary be back. <dachary> *very* painful upgrade <davi> :) <davi> Notes: <davi> * At gnuherds we try to avoid the use of JavaScript, allowing users use any feature, all the website, without having to enable JavaScript. Anyway this can be an exception if there is not way to avoid it. <davi> <davi> I absolutely agree about the below road-map: <davi> <davi> The flouzometer will need various adaptors anyway <davi> 1) do it for mediawiki <davi> 2) do it for wordpress <davi> 3) help davi do it for gnuherds <davi> <davi> However, we will have to wait to see the code, and how to integrate it, and only then we can expose other technical comments <antoviaque> Good! : ) <dachary> agreed <dachary> this is why the flouzometer is split in two : a webservice fully functional but not very user friendly (what is needed for gnuherds presumably) and a user interface (sample one with JS) that is an example of how it could be used (and could be used as an inspiration for the purely non-ajax client dedicated to gnuherds). <davi> good, good <proppy> antoviaque: hacked mediawiki integration http://ouzo.flouzo.net/mediawiki/index.php/Main_Page <davi> I am able to overflow it :) <davi> This is just feedback. <antoviaque> Nice proppy! <proppy> davi: yep currently there is no boundary for the flouzometer :) <proppy> however the webservice is supposed to expose the "goal" amount <proppy> I didn't fetch it yet <proppy> I'm focusing on mediawiki integration <davi> cool proppy1 <proppy1> now fighting with debian packaging <davi> I prefer debs to rpms! <proppy1> davi: dachary too ! <davi> no comment :) <dachary> :-) <davi> later <proppy1> debian package done :) <proppy1> and installed as a mediawiki extension <proppy1> http://ouzo.flouzo.net/mediawiki ... <dachary> antoviaque: ping <antoviaque> pong <dachary> davi: pong <dachary> antoviaque: join #savannah <dachary> something I got to tell you <dachary> antoviaque: no need Beuc's not there <dachary> here is an idea : add openid support to Savannah <dachary> and gna <dachary> and / or <dachary> add opensocial support (subset) to savannah or gna <antoviaque> huhu? <dachary> if they do that <davi> ping dachary <dachary> it means gna/savannah can be used as a basis for a third party application such as gnuherds <dachary> instead of integrating gnuherds into savannah/gna, have savannah/gna conform to standards and build on them <davi> dachary, The problem would be that OpenID is weak. <dachary> that leaves the security question open ;-) <davi> It can be attacked via DNS attack <dachary> let's forget about the money first <davi> weak* <dachary> I know <dachary> money transactions can be isolated into a safe environment <dachary> much in the same way paypal is used on non-secure websites <dachary> money related transactions need a very safe environment <dachary> and it must be confined <dachary> but not all gnuherds is about money transactions, is it ? <davi> no, it is not. <dachary> and for all that's unrelated to money, using standards is a good thing <davi> There is not money involved to post a notice, or to fill your resume, etc. <dachary> and IMHO the biggest problem gna.org / savannah.gnu.org have in that respect is that they don't adhere to any known standard <dachary> s/adhere/coform/ <dachary> therefore it would be a nice idea to push in this direction * dachary is fairly sure that Beuc will tell him it has been discussed before ;-) <davi> Using a weak and not-secure standard? IMHO openID is just good for blogs, etc. <davi> IMHO, a way to improve is not add support to weak standards <davi> IMHO people register an login at Savannah without any problem <dachary> davi: they do. But you have to ask Savannah for a spaecial adapter in order to interface with it. <davi> Anyway, it is good we are discussing this, because maybe I am mistaken <dachary> And Savannah / gna are weak already ;-) <dachary> davi: Mistaken about what ? <Edgar1> hello davi <dachary> About never using OpenID even when security is not a concern ? <dachary> Edgar1: hi <davi> dachary, It is good we follow discussing this subject, to get a final technical conclusion <antoviaque> dachary: about how secure openid is I think <Edgar1> hello dachary <davi> OpenID security is a joke, IMHO <davi> well, it is a fact. <dachary> antoviaque: could you rephrase please ? <davi> IMHO, the only good think about OpenID is its name <dachary> davi: what authentication protocol would you recommend ? <Edgar1> in my few personal experience(cause i don't use it lately), the openid secure to me is some good <Edgar1> i use the launchpad OpenID provider <davi> dachary, One which is not delegated to an external entity <dachary> "external" ? <davi> Edgar1, Being a OpenID user does not make such technology secure <antoviaque> dachary: I think the thing davi would like to clear up is how secure OpenId can be <antoviaque> Personnaly I think it's as secure as relying on email validation <dachary> OpenID is not delegating to an external entity by design. It can. But if you restrict to a localy operated provider it is not external. <davi> antoviaque, It is only secure if it is Savannah who provide the OpenID service <Edgar1> of course <dachary> davi: Savannah who provide the OpenID service: my point exactly. <davi> dachary, I agree with you about the 'locally' comment. <davi> yep <dachary> davi: I'm suggesting that Savannah is made an openid provider. Not that you can login to savannah with openid. <davi> dachary, But why OpenID and no another thing, as for example the current authentication system? <davi> We can think, <antoviaque> Something I don't get: if somebody can change his password on a website by getting email verification, how is that different security wise than relying on Openid identification? In both case you rely on the security parameters of an external email/openid provider <dachary> because OpenID is a documented protocol to identify a user. The current system is undocumented and compatible with nothing. <Edgar1> :-\ <davi> dachary, The OpenID, documented protocol to identify a user, is weak. For example, suppose Savannah is the OpenID provider. If it is able to login to GNU Herds using the Savannah as OpenID provider, I could attack the system and login to GNU Herds as any user and post a job offer in its name. That is because OpenID is a weak technology. <dachary> For that you would need the Savannah user password. <davi> I could be able to force to gnuherds to ask to another IP (controlled by me) instead of the Savannah IP. My controlled-IP will reply "authorized" so I could be able to log in to such _delegated_ authorization process. <davi> Note that OpenID works as a _delegating_ authorization process. <davi> Not when you are the provider, but <davi> with _any_ other service use it, it is weak <davi> So GNU Herds should not use it <davi> due to security reasons. <Edgar1> well besides OpenId, there are other options, i guess you have see in facebook, hi5, myspace or other social networks, which let you add as friends and invite them to that network by importing the contacts you may have <Edgar1> hotmail, gmail, yahoo provide that option or service for web sites <davi> yes <Edgar1> i guess it's possible to import user data from these services <Edgar1> and use it as it should in a webapp <davi> OpenID is not designed to 'import' data but to delegate the authentication process <davi> The OpenID service reply: Yes, he is authorized. or No, he is not authorized. <davi> Just that. <Edgar1> that seems kind of useless <dachary> (storm here, water in the house) <Edgar1> is it raining over there dachary <Edgar1> raining a lot i guess <Edgar1> or is it just a way to say something? <davi> OpenID is a joke about security. If you want only use it in local, then that is not 'OpenID'. OpenID has sense when you provide the authentication service to others, or use the authentication service of others, and <davi> using it in such way is a security joke. <davi> Just for blogs which nobody care who post. <davi> IMHO, not for posting a job offers, and of course not to manage your money. <davi> <davi> IMHO what users would like is features which works, and are secure to be used. <davi> To be secure we must control the authentication process. <Edgar1> openid to manage money it's a nightmare <davi> To integrate Savannah and GNU Herds we are proposing maintain the same data in both systems <davi> so both systems can be accessed with the same userID and password. <dachary> Edgar1: I've put towels where the leaks are, should be good. <davi> All, secure, of course, HTTPS, verification via email, with encrypted email if enabled by the user, GPG public key, etc <davi> IMHO, OpenID sounds 'marketing' not a serious technology. <davi> It is good for people who post in lost of different blogs, or similar, no more, IMHO. <Edgar1> well, maybe some people would ask you or rescue to evict or abandon the place dachary <davi> IMHO savannah does not need it, and must not propote such weak technology. <dachary> davi: I still don't understand how you could post a job on gnuherds without knowing the password of the savannah user. Maybe that's why I don't understand that OpenID is a weak technology. Could you please describe it ? <dachary> Edgar1: ahahah <davi> dachary, Well, to understand it you have to understand how a DNS server can be attacked <Edgar1> well, i guess it's to incorporate all the savannah users like they were gnuherds users too <Edgar1> share both services, with one identity <davi> IMHO that is a good option, Edgar1 <davi> It can not be more secure <davi> and it is easy for the end user <davi> Just one loginID, and just one password <dachary> davi: you mean that I could post a job offer on gnuherds without using savannah user password if the gnu.org DNS server are compromised ? <dachary> I understand that. <dachary> But this is not an OpenID weakness. I mean that all services @gnu.org will be compromised if someone takes over the DNS ;-) Apache and MySQL , you name it ;-) <davi> yes, because you can modify the DNS server so that instead talking to the IP of the Savannah authentication service, talk to another IP controlled by the attacker. Such IP can just reply "Authorized" when the attacker want <dachary> If I have gnu.org control I can do a lot better than that ;-) <davi> dachary, No if the authentication is done in local, <dachary> I steal the savannah user password when they login. That's a first ;-) <dachary> savannah.gnu.org goes to savannah.me-hacker.com and fakes the login page <dachary> standard phishing :-) <dachary> If you DNS is compromised *nothing* survives. <dachary> you effectively vanish from the internet and all users are abused <dachary> davi: don't you agree ? <davi> No, not so, because log of users would note the me-hacker.com in the URL of the browser <davi> Note the DNS service is not involved in internal service working. If the authentication is done in local no any DNS query is done. <dachary> I have control of the DNS : I change the IP address of savannah.gnu.org to be the IP address of savannah.me-hacker.com. That's what I meant. A HTTP redirection would be noticed, you're correct. <dachary> If savannah.gnu.org is an IP of my machine, it does not matter how authentication is done. You're finished. <davi> No because although you allow to login the user in your site the data which it keep would be empty or mistaken. so he would note it. <davi> If the attack replace all the site it would be noted easily by the users. <davi> If the attack replace only the authentication system it will not be noted. <davi> Do you see it? <davi> I login, and see all my offers, etc. <Edgar1> users may note the me-hacker.com, but most of the time doesn't note the savannah.gnu.org vs savannah.gnu.com <davi> The mimic gnuherds.org besides the webapp source code you need the data of the data base, offers, profiles, resumes, etc. <davi> <dachary> davi: you just need to replace the login page and store the stolen passwords, then proxy pass the request. And just do proxy pass for all other pages. <dachary> I tell you : if you seize control of the DNS you own the site. <Edgar1> well, let say a clone gnuherds.com(not the .org), a equal web design, but the hacker just want the user type his password and email <davi> The users who log in directly at Savannah would not have such security problem, because the authentication process would be done in local, Savannah. But the GNU Herds users who launch a request to the Savannah host would be weak due to this type of attack. <Edgar1> and then manually he would access to his information in the original gnuherds.org <dachary> davi: you're telling me that OpenID is weak because it can't resist a DNS takeover. I'm not sure I'm convinced. Because nothing can resist a DNS takeover. <dachary> are there other reasons why OpenID is weak ? <davi> dachary, No because the PHPSESS session cookie of the cracker-site would be different to the gnuherds one. You will have to run all the site in the same cracker-site else it will not work. <davi> That is a fact. <davi> That is how serious authentication works; after you login in such site you work all in the same site. <dachary> proxypass is invisible except for the incoming IP <dachary> cookies & all are transparently transmitted back and forth <davi> yeah, that is because if you do the login in the cracked-site it will <davi> send back the cookie of the cracked site, no the one of gnuherds.org <davi> So, it will not work when the proxy 'redirect' to gnuherds.org <davi> That is as a serious authentication process works. <davi> That is how gnuherds authentication is working. <dachary> the proxy does not redirect. <davi> I know it, so the ' <dachary> http://httpd.apache.org/docs/2.0/mod/mod_proxy.html#proxypass <davi> The fact is that the PHPSESS cookie which the cracked site return to the web browser will not work in the gnuherds.org site <davi> The user will have to work with the cracked-site all the time or else he would be in a log-out mode in the gnuherds.org one <davi> The current gnuherds authentication mechanism force it. <davi> <dachary> davi: if that's true then none can use gnuherds from behind a proxy <dachary> davi: if that's true then nobody can use gnuherds from behind a proxy <davi> proxy let pass cookies, so it works <davi> It is just that <dachary> exactly <dachary> the hacker site does just the same <dachary> only it saves passwords <davi> you do not manage to see that there are _two_ different cookies in your use case <dachary> the hacker site is a proxy <dachary> it's nothing more <dachary> just a two lines patch that writes the passwords to a file <dachary> other behaves exactly the same <davi> ah, you are talking about the man-in-the-middle attach! <davi> That will not work because <davi> gnuherds use a HTTPS certified <davi> to the login page will not show the right certificate * proppy has quit ("Leaving.") <davi> and the browser will warn to the user, at least FireFox, <davi> <davi> I should have begun with this argument. <davi> <davi> But note that <davi> if we use an OpenID authentication mechanism <davi> we do not have such HTTPS certificate method <davi> to protect the login page <davi> and the rest of the logged session <davi> work process. <davi> <dachary> that means a little more work from the hacker site to change the https urls into http urls (only show non https urls to the user and pass them as https to the real site) but it's not even complex <dachary> maybe users will be suspicious that they don't see the https:// in front <dachary> but it will work <davi> Yes, that attack would work if the user does not note the lack of HTTP Secured session <dachary> davi: although this is an interesting conversation, you can't reasonably argue that OpenID is weak if the only reason is because it can't resist a DNS takeover. <dachary> There must be another reason. <davi> Of course there are others <davi> but the above is IMHO the main one, because it show the weak it is. <dachary> I want to hear them please. <davi> Other: <davi> * dachary, I ask you delegate in my all your important decisions. <davi> s/my/me/ <davi> <dachary> (the above is not valid : a system is not weak because another can be compromised. It's like saying the pentagone security is weak because it will be compromised the chief of security is corrupted ;-) <davi> You would agree that authentication is the main decision in your life. Isn't it? <davi> dachary, A system is weaker and weaker as there are more attack paths to crack it. That is a security principle. <dachary> (a chain of security is as weak as it's weakest component and you're describing a situation where the DNS is the weakest component, which proves nothing about OpenID weakness itself) <davi> There is nothing 100% secure, but there are systems more secure than others. That is another security principle. <davi> <davi> No, I disagree, and any security expert would disagree with you! <davi> The more attack paths the weaker it is. <davi> The experience shows that. <dachary> I agree with that. <davi> Well, I have to take rest. <davi> see you <dachary> More paths means more opportunities to attack. <dachary> see you
