-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello everyone,
this week I again spent some time polishing and refactoring old code as well as extending OCRA support within oath-toolkit. *Work done this week* .) Add man pages (this were just some simple additions to a Makefile and some gdoc comments for methods) .) Add method for pseudo randomly generating challenge strings based on type and length (e.g., NUM 8 -> 12345678, HEX 6 -> A5B6C7, ...) .) Refactor and extend usersfile storage to support OCRA as algorithm .) Add method to usersfile for just retrieving the mode; this is needed for knowing the challenge parameters .) Refactor and extend PAM module to support OCRA one way authentication The PAM module now retrieves the mode for the user who tries to authenticate (according to the usersfile). If the mode is not OCRA, everything works like before. If it is OCRA, the module parses the OCRA suite parameters and generates a challenge string according to the specification. This challenge string is converted to a byte-array (for passing to the validation method). If the OCRA suite specifies that a counter should be included as input to the hashing function, the counter value stored in the usersfile is used (and, after successful validation, incremented by one). If neither timestamp nor counter is specified, the OCRA values would be potentially susceptible to a replay attack (because the OCRA value would solely be dependent on the static secret key and the challenge value, which might be repeated given enough authentication attempts). It is therefore recommended to either include timestamp or counter or to choose a big challenge length. As soon as the missing hashing methods are established, I would like to include password hashing as part of the PAM module. If a password is stored in the usersfile and password hashing is specified as part of OCRA suite, the usersfile_authenticate2 method should calculate a hash of the password using the specified hashing method and include it as part of the datainput. I am not quite sure whether the PAM module should support two-way authentication (i.e., the user gives a challenge, the pam module generates and displays an OCRA value and a new challenge, the user validates the displayed OCRA value and calculates its own value based on both challenges, the PAM module validates this OCRA value). There are basically two approaches: having a global OCRA suite parameter and key for all users (i.e., as PAM module parameter) or having a different suite and key for each user. The latter would be a little bit more flexible and secure. I would need to read up a bit more on PAM api methods (for my current changes, I left the user interaction part basically untouched, in this case, I would need to add more code of my own). I am not yet sure whether and how to include session information as part of the PAM process - my current opinion is that this is unnecessary (as it would make the module less easy to use with tokens). I think session information will be more relevant next week when I implement OCRA for dynalogin - since we have a TLS / TCP session :) and control both server and client. *TODO* .) Support for SHA256 and 512 (in general, pending feedback/input by mentors) .) Support for password hashing as part of the PAM module (depends on ^) .) More extensive testing of the PAM module .) Maybe add two-way authentication support *Plans for next week* .) Finish hashing methods (if possible) .) Start working on dynalogin If possible, I would like to finish the dynalogin part until next Friday. This consists of three parts: Extending the existing data sources to support OCRA; designing and implementing an OCRA protocol for dynalogin; extending the PAM module to support OCRA (this is a different PAM module than above ;)). I will be ony holiday from July 22nd until August 2nd - I will probably not work much during this period (depending on spare time and net access). As always, my code is on github[1]. Kind regards, Fabian 1: https://github.com/Fabian-Gruenbichler/oath-toolkit/commits/ocra -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBAgAGBQJR4DLVAAoJEK4xK/RwikTnjPwQALXxOXTWGrxW+mrK3ZpN4XtX JYWGzi1YTiuRD0Rm/Si+BfEw9LVbVzHWE/aHBMit23GYBmu8SXBoolIHZh6gP0Ay YQuhgZyk12hYoM1p36yxk5cAx5m02+e4FyldVPqRJdfvxOe7P2dz1QAMQ7/DpxOF iy9yCE5gAK6GjlhUk1mWZOzLE5bUsKHEPX9ZmrlnfaIir6zcjOzyo+fZii8eqdtr WpMupd4GCIlnBTypkrr5gqgT/FvKT7cmgZxqDVNvWG+thj/iSo9POfYTUDxuQqkd DnMae69sf5NKRN0BRZIgMyVmY+KMnZfR2Ib50Qq3Avl8uCUsXlZErVab5cn8rhXK RSum/8I7Km/EexM3qrzdJn0KgjKnP1RBU5VDnp9QK8dNhiKqSUlNAEZ/Hs3roUyO 0B0tPOSmjZ4sPNLVG5o3Xlpo3sxqHvKALqsc+HoTp/AjJghyYXYhA1tIF4pSjp2u NIx4fgzJYbeOX3cfUlmsUR6BcMT5YDJqLDLCeWaDHMnd5/JJ6zEVNGfQhCaC5Mrf GdXfRoxCwgok7TlhkXjRjPvMMWxesH1kdwqVwbJoUD+80Ezr620S8PDFniay5Qta pmSJ/Oh/jrGaoB7GNxtR3s0Me0NtvVHFKIE4yUC89V4C6Nw5IY/h7OxZcalnT0An 6K7mXphmrbSoBWTsVqN1 =q3a2 -----END PGP SIGNATURE----- _______________________________________________ Soc-coordination mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/soc-coordination
