http://permalink.gmane.org/gmane.comp.security.oath-toolkit.general hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.security.oath-toolkit.general/278 <pre>Package: liboath0 Version: 2.0.2-2 Severity: wishlist Hi, according to RFC6238 section 1.2 [0], "TOTP implementations MAY use HMAC-SHA-256 or HMAC-SHA-512 functions, based on SHA-256 or SHA-512 [SHA2] hash functions". It would be nice if liboath (and pam_oath) supported this. Thanks [0] http://tools.ietf.org/html/rfc6238#section-1.2 </pre> Alessandro Ghedini 2013-05-11T13:15:54 http://permalink.gmane.org/gmane.comp.security.oath-toolkit.general/277 <pre>FYI: The status of the oath-toolkit source package in Debian's testing distribution has changed. Previous version: 1.12.4-1 Current version: 2.0.2-2 </pre> Debian testing watch 2013-05-05T16:39:49 http://permalink.gmane.org/gmane.comp.security.oath-toolkit.general/276 <pre> Yes, exactly. I'd go with manually entering the offset at the same with the key. It's not hard to find out the offset anyway, and if you have lots of keys, changing the configuration every time you add one would be silly. If the drift is small enough, so that the clock on the hw token always stays within the window, then the offset could just be updated according to what the user gave, just as you said. But if the drift is larger, then the server would need to know the amount of drift beforehand to be able to compensate (without making the window bigger). And actually, 3 steps or 90 seconds a year is only about 3 ppm, and I've heard numbers more than 10 ppm for crystal oscillators, so it could probably be worse. I guess this could be an argument for using HOTP instead of TOTP. Hmm the usersfile has a couple of optional fields (last use timestamp, last used OTP, last counter value), so adding the offset as an additional field would require the users to fill in the optional fields to be able</pre> Ilkka Virta 2013-04-28T20:29:50 http://permalink.gmane.org/gmane.comp.security.oath-toolkit.general/275 <pre> I have a h/w key I use for ~2 years. In fact it has both issues - offset –130 steps and drift around -3/ steps a year. The first problem can be solved by either manually setting the shift in config or making a big window, so after the first successful login this shift will be stored in config. Then one can change window back to normal 3—5. The second problem is solved by the window — system always check +1/-1 step or more and then stores the calculated offset in config. The current code can be fixed to store the shift... I'm just not very familiar with C coding... -------------- &lt;&lt; at &gt;)%%&gt;{ On 28.04.2013, at 20:53, Ilkka Virta &lt;itvirta&lt; at &gt;iki.fi&gt; wrote: </pre> Sergey 2013-04-28T17:58:58 http://permalink.gmane.org/gmane.comp.security.oath-toolkit.general/274 <pre> Hmm. I thought about this (for other reasons) one day. I can see two different issues here: 1) The hw clock has a constant offset 2) The hw clock actually drifts during use, so the offset changes I guess you only saw the first problem right? I wonder if the drift actually would be a problem, and how does commercial stuff (like RSA) deal with it, if it does. Is the current code even supposed to do anything to handle this? </pre> Ilkka Virta 2013-04-28T16:53:09 http://permalink.gmane.org/gmane.comp.security.oath-toolkit.general/273 <pre> I don't think I did the upload (but I could be wrong) - can you check with the FTP masters on IRC or email? </pre> Daniel Pocock 2013-04-25T21:07:56 http://permalink.gmane.org/gmane.comp.security.oath-toolkit.general/272 <pre>I have a h/w key which works okay but is ~ 1 hour back in past. I've crawled through the sources and I've made a test. The problem is — I have to set my window = at least 150, and then, after some successful authentications I can't change it to normal 3—4. PAM library just doesn't use all that time drift info. The field called ‘start_moving_factor’ just keeps increasing by 130 every time I log in. And, as I see in the code it's not used with TOTP =( I can't keep window=150, this make the whole thing useless. Are you planning on fixing this? </pre> Sergey 2013-04-18T16:16:59 http://permalink.gmane.org/gmane.comp.security.oath-toolkit.general/271 <pre>Does anyone know what this is? I suppose it is a backport, but it isn't clear what it was uploaded to (squeeze-backports?), and what got me curious is that it isn't mentioned anywhere on http://packages.qa.debian.org/o/oath-toolkit.html or on http://backports.debian.org/changes/squeeze-backports.html /Simon Debian FTP Masters &lt;ftpmaster&lt; at &gt;ftp-master.debian.org&gt; writes: </pre> Simon Josefsson 2013-04-17T22:16:05 http://permalink.gmane.org/gmane.comp.security.oath-toolkit.general/270 <pre> I added myself there as mentor, in case someone is interested in joining as student. I must admit I have no idea about the timeline and processes, but if an interesting project/student comes along, I'll read up on it. /Simon </pre> Simon Josefsson 2013-04-17T19:21:50 http://permalink.gmane.org/gmane.comp.security.oath-toolkit.general/269 <pre>oath-toolkit_1.12.4-1~bpo60+1_amd64.changes uploaded successfully to localhost along with the files: oath-toolkit_1.12.4-1~bpo60+1.dsc oath-toolkit_1.12.4.orig.tar.gz oath-toolkit_1.12.4-1~bpo60+1.debian.tar.gz liboath-dev_1.12.4-1~bpo60+1_amd64.deb liboath0_1.12.4-1~bpo60+1_amd64.deb oathtool_1.12.4-1~bpo60+1_amd64.deb oath-dbg_1.12.4-1~bpo60+1_amd64.deb libpam-oath_1.12.4-1~bpo60+1_amd64.deb Greetings, Your Debian queue daemon (running on host franck.debian.org) </pre> Debian FTP Masters 2013-04-17T17:51:21 http://permalink.gmane.org/gmane.comp.security.oath-toolkit.general/268 <pre> On 12/03/13 05:14, Simon Josefsson wrote: I've proposed it here under the Debian umbrella, although the work doesn't have to be exclusively for Debian: http://wiki.debian.org/SummerOfCode2013/Projects#One-time-password_.28token.29_based_authentication_and_transactions I'd really prefer to find additional mentors to support this as well. Also, I misread the timetable, 18 March is not the deadline, it is just the day that they open the process for organisations to apply. </pre> Daniel Pocock 2013-03-12T21:57:22 http://permalink.gmane.org/gmane.comp.security.oath-toolkit.general/267 <pre> Hi. I'd be interested in participating but I currently don't have time to drive this. Maybe there is some umbrella organisation where this could fit into? That may improve the chances of actually getting anywhere... /Simon </pre> Simon Josefsson 2013-03-12T04:14:02 http://permalink.gmane.org/gmane.comp.security.oath-toolkit.general/266 <pre> Hi, Would anybody be interested in putting OATH-related projects into Google Summer of Code this year? I understand Google looks at the size of the community when deciding which projects to support. I feel that if we submit the projects collectively, we are more likely to cross the threshold required, and we may also get interest from students who will contribute improvements across all the projects. The deadline to propose this to Google is next Monday, 18 March. If it is going to happen, we probably need to put announcements on each of our web sites inviting students to come into the mailing list and discuss potential projects. Regards, Daniel </pre> Daniel Pocock 2013-03-11T09:46:29 http://permalink.gmane.org/gmane.comp.security.oath-toolkit.general/265 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi all, I've just released dynalogin 1.0.0, based on OATH toolkit It's documented in more detail on my blog, and further details will be published about integration patterns over the coming weeks: http://www.pocock.com.au/dynalogin-1.0.0-released The SHA224 checksum for dynalogin-1.0.0.tar.gz is d44af8071f5b03098d43d7820f61aeff2a3c0d97da4dfae1619ff731 Big thanks to Simon for providing the oath-toolkit, the dynalogin PAM module also started using the code from pam_oath. Regards, Daniel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJRI/4nAAoJEOm1uwJp1aqDHU8P/iQ3dWHyHN6EuE9wes9wUChc gTkyd8XnPBrBsm/fL8vJfgxZbq0+MoClhWUUCHi9PQgUmXvtt8+PpOFxOfw0F/fL W4jioziqg2h8BZZRnTHHrk9FxT4ggBCcUd7pcNIpZXcnFQZ/gEeXiF7ppP/2Qxce Razt9fuPyTmmQWu/J4FyOWzLx6cctIk33JuViTMayM50yIIFzKj3sDy5oHhrPXTz Zg2kUXuh0KN6tk4LVV/MZ58bT5nDZSxFexGGXhwu1abBaAnWSYAPOPKRJzkKIWlM HGkjVzQhftEcP</pre> Daniel Pocock 2013-02-19T22:35:19 http://permalink.gmane.org/gmane.comp.security.oath-toolkit.general/264 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I've recently added TOTP, TLS, PAM and a C client library to dynalogin code in github. https://github.com/dynalogin/dynalogin and the latest snapshot tarball, 0.10.1: https://sourceforge.net/projects/dynalogin/files/ I'm just wondering if anybody might have a look over the dynalogin code before I make a 1.0 release - particularly the code in libdynalogin/*.[ch] that interacts with oath-toolkit Any test results would also be very welcome Simon, the PAM code was based on your PAM module code, so I'm going to add your name to the credits as a dynalogin developer. Regards, Daniel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJREDsEAAoJEOm1uwJp1aqDOOwP/jTMVTcHpEonIQ7rKFU6DOLE DcqpZCg000Vh9r+Ggi6bNzXh03uU1CkqIXLI/FHRrGeYeqJU+xv1kOjOp8wn2Yw9 KcJcQ9iDuiRH4RyiKwlqr50TOC0dYJbyx2byYHKNAN2Ql8cVbb2r5Yqdy3rU4Tg0 NzXnjS4me0eh0d9IK71JglYUGeThwlujHG7QOAPVSr+RTvwY</pre> Daniel Pocock 2013-02-04T22:49:40 http://permalink.gmane.org/gmane.comp.security.oath-toolkit.general/263 <pre> Great, approved I would have to familiarise myself with the contents more closely, and I won't have time to do that before FOSDEM this weekend, so if you could do the upload this time I will start looking over the package contents in February </pre> Daniel Pocock 2013-01-29T09:00:18 http://permalink.gmane.org/gmane.comp.security.oath-toolkit.general/262 <pre>]] Daniel Pocock I've submitted a request to join now. I know alioth quite well, I'm one of the admins. :-) Simon answered this. Are you doing the sponsorship for the package or should I? </pre> Tollef Fog Heen 2013-01-29T05:39:22 http://permalink.gmane.org/gmane.comp.security.oath-toolkit.general/261 <pre> On 28/01/13 23:17, Simon Josefsson wrote: When they live on alioth, I just name them using the source package name When I clone them locally, I use a variety of different naming conventions though, to distinguish them from the upstream packages The package name is fine, you can look at the alioth gitweb to see examples of how other people name their packages Also, this is how the maintainer setup is done in debian/control: Maintainer: Debian Authentication Maintainers &lt;pkg-auth-maintainers&lt; at &gt;lists.alioth.debian.org&gt; Uploaders: Simon Josefsson &lt;simon&lt; at &gt;josefsson.org&gt; Vcs-Git: git://git.debian.org/pkg-auth/oath-toolkit.git Vcs-Browser: http://git.debian.org/?p=pkg-auth/oath-toolkit.git;a=summary and anybody who wants to participate has to both: a) request to join via alioth: https://alioth.debian.org/project/request.php?group_id=100821 and b) subscribe themselves to the list: http://lists.alioth.debian.org/mailman/listinfo/pkg-auth-maintainers (a) requires us to approve (as we are the group admins) a</pre> Daniel Pocock 2013-01-28T22:23:38 http://permalink.gmane.org/gmane.comp.security.oath-toolkit.general/260 <pre>]] Simon Josefsson Well, you're the maintainer so to the extent anybody owns the package, it's you. You're free to get sponsorship from whoever you want. :-) I'm happy to sponsor the upload, or Daniel can do it, either works for me. Cheers, </pre> Tollef Fog Heen 2013-01-28T21:35:16 http://permalink.gmane.org/gmane.comp.security.oath-toolkit.general/259 <pre>mån 2013-01-28 klockan 23:13 +0100 skrev Daniel Pocock: Excellent, thank you! Should we call the repo oath-toolkit-dpkg, to indicate that it also contains debian packaging, or is the common naming pattern to use the bare upstream repository name? Related, maybe the description should say 'Debian packaging of OATH Toolkit' instead. /Simon </pre> Simon Josefsson 2013-01-28T22:17:17 http://permalink.gmane.org/gmane.comp.security.oath-toolkit.general/258 <pre> On 28/01/13 23:06, Simon Josefsson wrote: $ ssh &lt;user&gt;&lt; at &gt;git.debian.org $ cd /git/pkg-auth $ /git/collab-maint/setup-repository oath-toolkit 'OATH toolkit library and utils' That should create a bare repo. You can then set your remote and push there. </pre> Daniel Pocock 2013-01-28T22:13:47 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.security.oath-toolkit.general