ruby_srp.git - [ruby

Age	Commit message (Collapse)	Author
2013-02-06	changed SRP:Client so it can be used to wrap a user record on the server	Azul

2012-11-04	making byte algo work in 1.9.3 - bumping version	Azul
	in ruby 1.9.3 string[i] will be a char. Need to call #ord to make sure we have a charcode.
2012-10-11	authenticate returns the user, to_json includes M2. bumped version to 0.1.3release-0.1.0	Azul
	This way the controller can easily use @user = @session.authenticate; respond_with @sessoin;
2012-10-11	removed duplicate requires, bumped version	Azul

2012-10-05	add to_json for session so it's easy to use in rails controllers	Azul

2012-10-05	bugfix - zero padded salts do not break login anymore	Azul

2012-10-05	made m and m2 calculation srp 6A compatible	Azul
	Also added session_test that tests agains values calculated with py_srp
2012-10-04	using the SRP 6a algorithm for calculating M	Azul

2012-10-04	moved all server side auth stuff into session so i can remove the ↵	Azul
	authentication module
2012-10-04	created session class to hold aa, bb and so forth - done for client	Azul
	We have a session in the server already - duplication there now, merge next
2012-10-04	more cleanup - no more duplicate password and username in Client	Azul
	A client has a set of pwd and login and tries to auth with this.
2012-10-04	simplifying modpow to default to BIG_PRIME_N	Azul

2012-10-04	some cleanup, sha functions now concat multiple args	Azul
	also u does not depend on n
2012-10-04	using BIG_PRIME_N and hashing the byte array - tests pass	Azul
	We still calculate M differently than in SRP 6a
2012-10-03	calculate verifiers and multiplier just like in py srpfeature-py_srp_compat	Azul
	Some other parts are still missing. Main issue was using hashes of hex representation rather that hashes of byte arrays
2012-08-06	hand over the login on handshake like we normally would	Azul
	still missing the salt in this. auth should be more independent from registry to resemble the real process more closely
2012-08-06	added authenticate! which raises SRP::WrongPassword if it fails, version 0.0.2	Azul

2012-07-26	we cache neither the verifier nor the secret in the session just in case	Azul
	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-26	session is handled by the class that includes SRP::Authentication - not the ↵	Azul
	client
2012-07-26	SRP::Authentication::Session holds the per session data	Azul

2012-07-26	removing the remaining zerofills	Azul

2012-07-26	both sides calculate their own u	Azul

2012-07-26	turned server class into authentication module - test green, example broken	Azul
	The example seems to be broken due to changes in srp-js
2012-07-26	removed debugging output and adjusted ruby client to new server api	Azul

2012-06-29	adopted 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-28	complete ajax flow is working - just auth fails	Azul
	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-27	moved to ajax workflow and integrated srp-js - not quite there yet	Azul
	* 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-26	first steps towards adding a server side srp flow to the example	Azul

2012-06-18	initial commit - testing srp auth	Azul
	* 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