srp_js.git - [srp

Age	Commit message (Collapse)	Author
2009-08-12	Rather than passing the necessary parameters to the SRP constructor, I've ↵	ausiv4
	made them hidden fields in the form. This way a bookmarklet will be able to read the fields, and authentication can be done without trusting the javascript sent by the server. I also organized urls.py
2009-08-12	When upgrading the user from a non-srp account to an SRP account, the client ↵	ausiv4
	must send the server the password. I wasn't happy about doing this in plaintext, so I've incorporated slowAES on both the client and the server to encrypt the password before it is sent, using the key generated in the first SRP transaction.
2009-08-09	Significant cleanup to srp.js.	ausiv4

2009-08-08	This adds upgrade functionality so that existing django apps can switch to SRP.	ausiv4
	If a user exists in the auth table but not the srp table, the server sends back the algorithm and salt needed to hash the password. The hashed password is used to authenticate the user. After the server authenticates the user and the user verifies the identity of the server, the user sends the password in plaintext. The server uses the plaintext password to calculate the verifier and stores. Finally, the client reinitiates the login process.
2009-08-07	This update separates the register functionality from the login library. The ↵	ausiv4
	login script is now .3 kb smaller, but there is a new 1.1 kb register file. I think that registrations are rare enough relative to logins that this should be a worthwhile tradeoff. This also prepares a framework for importing an update file, which will allow existing installations to upgrade from less secure authentication protocols, so some of the overhead in srp.js that was added here will help reduce the size as we add the update functionality.
2009-08-04	Removed debugging line from srp.js	ausiv4

2009-08-04	Improved documentation for srp.js.	ausiv4
	Made srpPath a part of the SRP object to reduce namespace clutter.
2009-08-04	Now the import_hashes function checks to see whether the srp file is packed ↵	ausiv4
	or not, and loads the packed or unpacked hash files accordingly. It occurs to me that perhaps all of the hash functions should be put into a single object to reduce namespace pollution.
2009-08-04	I've cleaned up the script path code so that it now packs properly. The path ↵	ausiv4
	to the srp script can be found in the global variable srpPath. If the server is using raw javascript files, this should be set to "srp.js". If the server is using packed files, this should be set to "srp.min.js".
2009-08-04	I've started working on the feature that will allow existing servers to ↵	ausiv4
	upgrade to SRP. Currently, I've added functionality that will allow the importation of hash.min.js. This is made possible by some code that executes when the script is loaded. This particular code doesn't pack properly, so currently I'm having the pack script append it to the end (unpacked). This requires that clients use the packed version for two reasons. First, the unpacked code lacks the function that gets the source path. Second, it loads hash.min.js. The first problem can be fixed if I can figure out how to get the code to pack properly. The second problem can be solved by checking whether the current script is "srp.js" or "srp.min.js", and loading either (MD5.js & SHA1.js) or hash.min.js respectively. Next we will need to write code where the server detects users who exist in the auth.models.User table, but not the srp.models.User table.
2009-07-28	Fixed srp.js for IE6.	ausiv4

2009-07-28	In this update we use jsPacker.pl to combine and compress javascript	ausiv4
	files. Instead of sending 6 javascript files totaling about 50KB, we now send 1 file totaling 21.1KB. After modifying any javascript files, run build-pack.sh to update srp.min.js. The login.html and register.html templates have been changed to send the one packed file. The file srp.js was modified so that it would pack properly. Necessary files from the perl version of packer are included, but they shouldn't be included on production web servers. The packer files are released under the LGPL.