summaryrefslogtreecommitdiff
path: root/lib
AgeCommit message (Collapse)Author
2013-02-06changed SRP:Client so it can be used to wrap a user record on the serverAzul
2012-11-04making byte algo work in 1.9.3 - bumping versionAzul
in ruby 1.9.3 string[i] will be a char. Need to call #ord to make sure we have a charcode.
2012-10-11authenticate returns the user, to_json includes M2. bumped version to 0.1.3release-0.1.0Azul
This way the controller can easily use @user = @session.authenticate; respond_with @sessoin;
2012-10-11removed duplicate requires, bumped versionAzul
2012-10-05add to_json for session so it's easy to use in rails controllersAzul
2012-10-05bugfix - zero padded salts do not break login anymoreAzul
2012-10-05made m and m2 calculation srp 6A compatibleAzul
Also added session_test that tests agains values calculated with py_srp
2012-10-04using the SRP 6a algorithm for calculating MAzul
2012-10-04moved all server side auth stuff into session so i can remove the ↵Azul
authentication module
2012-10-04created session class to hold aa, bb and so forth - done for clientAzul
We have a session in the server already - duplication there now, merge next
2012-10-04more cleanup - no more duplicate password and username in ClientAzul
A client has a set of pwd and login and tries to auth with this.
2012-10-04simplifying modpow to default to BIG_PRIME_NAzul
2012-10-04some cleanup, sha functions now concat multiple argsAzul
also u does not depend on n
2012-10-04using BIG_PRIME_N and hashing the byte array - tests passAzul
We still calculate M differently than in SRP 6a
2012-10-03calculate verifiers and multiplier just like in py srpfeature-py_srp_compatAzul
Some other parts are still missing. Main issue was using hashes of hex representation rather that hashes of byte arrays
2012-08-06hand over the login on handshake like we normally wouldAzul
still missing the salt in this. auth should be more independent from registry to resemble the real process more closely
2012-08-06added authenticate! which raises SRP::WrongPassword if it fails, version 0.0.2Azul
2012-07-26we cache neither the verifier nor the secret in the session just in caseAzul
People might store the session in a CookieStore - which would probably be a bad idea anyway - but let's be save rather than sorry.
2012-07-26session is handled by the class that includes SRP::Authentication - not the ↵Azul
client
2012-07-26SRP::Authentication::Session holds the per session dataAzul
2012-07-26removing the remaining zerofillsAzul
2012-07-26both sides calculate their own uAzul
2012-07-26turned server class into authentication module - test green, example brokenAzul
The example seems to be broken due to changes in srp-js
2012-07-26removed debugging output and adjusted ruby client to new server apiAzul
2012-06-29adopted srp algo to srp-js way of doing things.Azul
all large integers are now send as hex strings. Using sha256_str all over the place. This finally gives me successful logins. Needs a log of cleanup never the less.
2012-06-28complete ajax flow is working - just auth failsAzul
Also we currently generate the salt on the server - this should happen on the client but for now i stick to the srp-js workflow.
2012-06-27moved to ajax workflow and integrated srp-js - not quite there yetAzul
* needs a bit of cleanup from the old workflow * are client and server using the same primes right now? * store multiple users on the server side
2012-06-26first steps towards adding a server side srp flow to the exampleAzul
2012-06-18initial commit - testing srp authAzul
* This is lacking a few steps. We confirm the secret is the same but no key is generated from it and it is transfered over the wire in clear. * this was inspired by https://gist.github.com/790048 * seperated util, client, server and test code