IRC logs of #tryton for Wednesday, 2012-04-25 #tryton log beginning Wed Apr 25 00:00:01 CEST 2012
-!- smoldersan( has left #tryton00:30
sisalphello, about proteus, I found
sisalpis it the only documentation about it ?10:20
yangoonsisalp there is also the README inside the repos10:21
sisalpyangoon: tahnk you10:24
sisalpso to use proteus, one must understand tryton quite deeply10:24
sisalpwhich doc should be the right starter ?10:25
sisalpand would the log of client-server communication be a reference source ?10:28
yangoonsisalp no, client<->server is jsonrpc10:29
sisalpyangoon: and proteus is not ?10:29
yangoonsisalp but you can take a look at module tryton-tools10:29
yangoonthere is a script inside using proteus: localize_modules.py10:30
yangoonand you can take a look at the scenarios in the modules10:30
yangoonthey should be translatable quite easy10:31
yangoonsisalpthere is also in module tryton-tools for example10:31
sisalpyangoon: Thank you, I'll start there but will certainly come back ;-)10:32
yangoonsisalp good luck10:32
sisalpce que je souhaite c'est que les tableau de la catégorie sur deviennent des élément dans la comparaison des produits sur o-o.fr12:33
sisalppar exemple : nombre d'utilisateurs ou volume disque etc...12:34
sisalpSorry, mistyped in the wrong discussion, don't consider that ;-)12:35
sharoonthomascedk: I am looking at Issue 342002 and I was wondering why the format for date time is '%H:%M:%S' (i might be missing something)13:27
cedksharoonthomas: because it is the standard way13:27
sharoonthomascedk: so this is for date time to time conversion ?13:28
cedksharoonthomas: yes but I'm not sure to understand your question13:29
sharoonthomascedk: to be honest i don't :P i was wondering what this patch is doing13:30
cedksharoonthomas: allow to define the precision for time13:33
sharoonthomascedk: from what i understand the patch allows limiting the resolution of time part in a date time/time field on the client side13:33
cedksharoonthomas: yes13:33
sharoonthomascedk: the problem i see is with the default fields like create_date and write_date, their precision will be reduced to the default precision ?13:35
sharoonthomascedk: i see that the test case creates a record and if the resolution is lost, it should have blown up13:35
cedksharoonthomas: create_date and write_date are special fields13:38
rhubnerHi nicoe!16:02
nicoerhubner: hello16:04
rhubnernicoe: thanks by trust16:06
rhubnernicoe: We need to talk somethings to start the project16:07
rhubnernicoe: I'll build the stage for the development (blog, repository, correction bug) but I need to know somethings...16:10
rhubnernicoe: I wonder what are the tables that store historical/logs and sample queries for these tables, this is possible?16:14
nicoetake a look at the module account_invoice_history16:23
nicoeor product_cost_history16:24
rhubnernicoe: I'll see it... furthermore, do you have something to talk?16:27
nicoeI think the first think that you should do is understand how the history work in tryton16:29
nicoeThen find a way represent this in the tryton client16:30
rhubnerOk nicoe, i'll have lunch.. thanks16:44
sharoonthomascedk: Do you have a few minutes to talk about 2 factor authentication ?18:05
cedksharoonthomas: ok18:06
sharoonthomascedk: We get a lot of request these days for 2 factor authentication in tryton18:06
cedksharoonthomas: what do yo mean?18:07
sharoonthomascedk: and it is easy to manage on the server side, thanks to user and authentication being a model18:07
sharoonthomascedk: but on the client side it is difficult to handle18:08
sharoonthomascedk: currently we have password based authentication. We want to make it 2 factors. A password + an OTP (or something else, like pass codes, phone call, sms etc)18:08
cedksharoonthomas: I don't see any advantages18:12
sharoonthomascedk: well, its easy to understand because many people use weak passwords, or they use the same password everywhere or they even write down their passwords and its easy to steal18:13
sharoonthomascedk: so having a second factor reduces the probability of compromising the system by half18:13
sharoonthomascedk: even gmail supports two factor authentication now18:14
cedksharoonthomas: so drop the first as it is insecure18:14
sharoonthomascedk: then if somebody steals your key they have access18:14
sharoonthomascedk: the probability of being compromised does not get reduced18:15
cedksharoonthomas: it is false about gmail18:15
nicoeTwo-factor authentication is not useless. It works for local login, and it works within some corporate networks. But it won't work for remote authentication over the Internet.18:15
nicoequoting Bruce Schneier18:16
sharoonthomasnicoe: it works for remote logins too, we have implementations using Duo Security and yubikeys and it works flawlessly18:17
sharoonthomasnicoe: even our SSH logins have two factor authentication18:17
cedksharoonthomas: except that it store the session in the browser for months18:20
nicoeof course it works, sending password out there in clear text works too. The question is : is it secure ?18:20
nicoeAnd obviously it is not as secure as people think it is18:21
sharoonthomascedk: Well triton sessions are managed on server side and validity is configured by the user ?18:22
sharoonthomasnicoe: i did not understand the question. is it if 2 factor authentication is safer than single factor authentication (what is already there ?) i think yes is an answer for tha18:23
cedksharoonthomas: for me, it is not18:26
cedksharoonthomas: the security level of a system = the weak point of it18:26
sharoonthomascedk: can you explain please ?18:26
cedksharoonthomas: I can not it is basic logical18:27
sharoonthomascedk: and the weakest point in the case of tryton is authentication18:28
sharoonthomascedk: does this not add an extra step to protect it ?18:29
cedksmarro: don't understand18:29
smarrocedk: hi... what?18:31
cedksmarro: oups wrong completion18:31
cedksharoonthomas: don't understand18:31
sharoonthomascedk: from what i understand, you said that the highest security level of a system is the security of the weakest point of the system18:32
sharoonthomascedk: so the weakest point in the case of tryton, is the authentication part where someone stole or guessed a username and password ?18:33
cedksharoonthomas: no, the weak point is the user18:34
cedksharoonthomas: if you can not trust your users, you can not authenticate them18:34
sharoonthomascedk: its not a matter of trust, users of an ERP system can be anybody from the directors of the company to packers at the warehouse18:35
cedksharoonthomas: security is a matter of trust18:35
sharoonthomascedk: alright, so in your point of view there is no added value to a second factor of authentication ?18:36
cedksharoonthomas: not that much, depends of what you want to achieve18:37
sharoonthomascedk: well unlike the article nicoe sent, the goal of a second factor of authentication is to mitigate the risk of a weak password or a common password.18:37
cedksharoonthomas: don't understand18:38
nicoesharoonthomas: not unlike, just like the article I sent18:39
nicoeBut it does not work whe you use an untrusted network18:39
sharoonthomasnicoe: cedk: why ?18:39
nicoesharoonthomas: because people can still use mim attacks18:41
nicoesharoonthomas: it's explained in the article18:41
sharoonthomasnicoe: if you are talking about MIM in the sense of stealing a tryton session, it really doesn't matter if the user has a password, 2 factor, 3 factor or even more.18:44
sharoonthomasnicoe: but if you are talking about MIM stealing passwords, then that problem is mitigated by 2 factor authentication18:45
sharoonthomasnicoe: 1. because the second token if at all entered by the user is a one time password, not valid for second use18:45
sharoonthomasnicoe: 2. in recent implementations, the second token is an activation from a mobile app (on smartphones), phone calls, sms etc18:46
nicoeSo you demonstrated that it is in fact useless18:50
cedksharoonthomas: what is the problem you try to solve?18:51
sharoonthomasnicoe: it is intact useless in mitigating MIM attacks and thats not the purpose of the two factor authentication18:51
sharoonthomascedk: the problem i try to solve is: imagine that i was quick enough to read your key strokes sitting right next to you at TUL 2011 when you logged into your Tryton (username is already in cleartext), i have access to your triton db just with that18:52
cedksharoonthomas: so change password often18:53
cedksharoonthomas: analyse activies18:54
sharoonthomascedk: exactly the required solution, but automatic in 2 factor authentication where second factor is a new password every x seconds which you don't have to remember18:54
cedksharoonthomas: so just use the second password18:54
cedksharoonthomas: as the first one for you is not secure18:54
sharoonthomascedk: that alone doesn't solve the problem because stealing your key alone would be sufficient to gain access18:55
cedksharoonthomas: so secure your key18:57
cedksharoonthomas: and again if you consider that password can be read and key can be stolen, there is still no security18:58
sharoonthomascedk: the probability of pulling both of is much less than pulling any one of these ?? you got to agree to that18:58
bechamelcedk, sharoonthomas: what about something like ssh privates keys ?18:58
cedksharoonthomas: no18:59
bechamelgmail token works by sending an sms, other solution works with decated harware, it's not easy to deploy19:00
cedksharoonthomas: If I can stole you password, I probably can stole your key also19:00
sharoonthomascedk: what if the key is your phone ? you may not realize that i stole your password but definitely your phone, or that hardware token with your car keys ?19:01
cedksharoonthomas: I could just have copied you SIM card19:02
cedkas I already said, security is a matter of trust19:03
sharoonthomascedk: yep i could have, but thats a lot more of complicated things than just stealing a password19:04
cedksharoonthomas: I think it is more complicated to steal my password than my phone19:04
cedksharoonthomas: my password is in my mind19:05
sharoonthomascedk: ok i give up19:06
bechamelACTION really thinks something like ssh privates keys would do the job ...19:07
sharoonthomasbechamel: sounds good, and is secure but the only problem is its not portable19:07
bechamelsharoonthomas: not portable with repect to ?19:08
sharoonthomasbechamel: AFAICS you will need your private key on whichever machine you try to access triton from ?19:09
bechamelsharoonthomas: yes this is the feature actualy :)19:10
cedkbechamel: for it doesn't change anything19:10
bechamelsharoonthomas: this defeats the "I was quick enough to read your keystrokes"19:10
bechamelcedk: ^^19:11
cedkmore over, with a token/key you give the authentication to a third party that you don't control :-)19:12
bechamelcedk: who is the third party ??19:13
cedkbechamel: the token builder19:14
cedksharoonthomas: any way, if you have a fixed lenght token generator, you can just append it to the password and make your validation19:15
bechamelcedk: isn't this discussion about implementing it in tryton ?! :)19:15
cedkbechamel: I don't know, 2FA is often about token19:17
bechamelby the way, my wife used to work for a company that was using peoplesoft, and they were using a vpn to access it. Crypot and security stuffs are difficult to implement correctly, maybe it's better to use existing solutions.19:18
bechamelcedk: a token is just a number19:18
bechamelcedk: the 2FA of gmail is just a number that google send by sms to your phone19:20
-!- Mayank1(~mayank@ has left #tryton19:20
cedkbechamel: I guess the question was about adding 2FA to Tryton19:24
cedkbut as the login form is stored in the client, it can not be customizable19:24
cedkbut the login form is displayed before connection to server19:25
bechamelcedk: if it's the only problem, it's not a big deal :)19:25
cedkwe could imagine add a method on server that will describe the required fields for login and call it when the server is enter19:25
bechamelthe main questions should be: 1) what are the main threats 2) what are good solutions against them ?19:26
bechamelfor 1) i see: a)somebody reading over your shoulder, b) MIM, c) a bot that try to test all the passwords19:28
bechameliirc c) is not a problem as the server add an exponential delay between attempts19:29
cedkbechamel: b neither as there is certificate validation19:31
bechamelcedk: yes19:32
bechamelas we already have ssl support the next logical step is IMO to support ssl client certificates19:33
cedkbechamel: I don't think so19:34
pilouIs server certificate checked by the client ?19:35
bechamelpilou: there is a fingerprint stored in .config/tryton/2.2/known_hosts for each server19:37
bechamelpilou: but it don't remember how it is used19:39
cedkbechamel: just check the fingerprint19:40
bechamelcedk: yes but how it is useful ? does it stop MIM ?19:40
cedkbechamel: if fingerprint is wrong, it stop19:41
bechamelcedk: so it does not stop mim19:41
cedkbechamel: don't understand19:42
bechamelcedk: lets say i manage to intercept traffic between the server and the client, I just need to forward networks packet from the client to the server and vice-versa to see everything19:44
cedkbechamel: just encrypted traffic19:44
bechamelcedk: is the fingerprint generated or it is a checksum of the ssl certificate ?19:46
cedkbechamel: don't know19:47
bechamelcedk: I just read the code: it's a checksum of "peercert" which is the result of sock.getpeercert()19:48
bechamelcedk: so it should prevent mim19:49
piloucedk: does the use of m2crypto instead of checking the fingerprint seem like a good idea to you ?19:54
cedkpilou: don't understand what you want to do19:58

Generated by 2.11.0 by Marius Gedminas - find it at!