The newLISP on Rockets blog

Hashing and salting user passwords


Post #: 31
Post type: Blog post
Date: 2012-10-04 00:01:50.000
Author: Rocket Man

It's generally considered to be a bad idea to keep clear-text passwords in your database. If the database is ever compromised, hackers will have everyone's passwords.

What most sites do is hash the passwords using a one-way algorithm, like SHA1, which is a 160-bit encryption. Newlisp has a SHA1 function included in the module crypto.lsp.

Unfortunately, hackers these days use dictionary-based attacks, where they take every word in the dictionary (and many common password combinations that include numbers or years) and then just run them through SHA1 or the equivalent, and check to see if they match the compromised stored password hash.

To prevent this, people have been adding salt to the passwords and then encrypting THAT. Salt is just a random number. Each user gets its own Salt, which is stored in the user database. This way, attackers would have to run separate dictionary attacks for every user, and that's assuming they know the salting algorithm.

I found a great article on password security here: http://phpsec.org/articles/2005/password-hashing.html

It outlines the whole process and shows how to handle it in PHP. I'm building in the equivalent in Rockets using newLISP code, which will be part of the user sign in process.



Views: 4199


Cookies! Fresh out of the oven!


Post #: 29
Post type: Blog post
Date: 2012-10-03 21:28:17.000
Author: Rocket Man

After much soul-searching, I went ahead and implemented the delayed-write method I talked about in my earlier posts.

At first I tried to overload (print) and (println) and it worked but jumping in and out of different contexts made messed up my ($POST) functions, and I thought I'd simplify my life by just defining new functions: (display) and (displayln). Then at the end you (display-page). You can also (display-image) and (display-post-box). Kind of a theme going there.

Anyway, (set-cookie) now adds a cookie to the header that will get posted when the page itself is displayed. It seems to be working, so hopefully I can now work on getting user sign-in happening on the Rockets blog!



Views: 3584


Posted from my iPhone


Post #: 28
Post type: Blog post
Date: 2012-09-27 00:11:21.000
Author: Rocket Man

Yes. It was.



Views: 3639


Try it on your iPhone...


Post #: 27
Post type: Blog post
Date: 2012-09-26 23:11:12.000
Author: Rocket Man


Thanks to Bootstrap's "reactive" ability, you'll notice it gets automatically reformatted and the menus work differently.

I think it's pretty neat.



Views: 3984


Fancy graphics!


Post #: 26
Post type: Blog post
Date: 2012-09-26 23:10:52.000
Author: Rocket Man

Courtesy of Bootstrap, the open-source CSS and Javascript library released by Twitter.

Bootstrap is based on jQuery, which I use a lot and which will be fully integrated into Rockets.



Views: 3677


YAY!!!


Post #: 25
Post type: Blog post
Date: 2012-09-25 23:56:24.000
Author: Rocket Man

Small and fast....



Views: 3604


Benchmarking...


Post #: 24
Post type: Blog post
Date: 2012-09-25 22:29:23.000
Author: Rocket Man

It's in there. Scroll down to the bottom of the page.



Views: 3731


Cookie Conundrum Continues...


Post #: 23
Post type: Blog post
Date: 2012-09-25 22:06:13.000
Author: Rocket Man

I've been thinking about the Cookie Conundrum and I think it goes beyond just Cookies...

If I want to do a redirect on a page, as Dragonfly does with Response:redirect (something I use all the time) I have to set the headers to be a 302 Redirect. Again, these headers have to be sent before any other text is shown, so it has to be printed at the beginning.

I have changed the way Rockets works to use the Dragonfly model of just loading everything into a big global variable called STDOUT, then delaying printing until the end where you print the headers first and then STDOUT. Only I can't force the delay because there isn't a main program in charge of loading each page, so you have to remember to add the new function (display-page) at the end of your pages for it to work.

Hmm. Not sure about this. I'll think about it some more.



Views: 3571


Thinking about cookies...


Post #: 22
Post type: Blog post
Date: 2012-09-25 00:07:42.000
Author: Rocket Man

In order to get separate users to sign on and post messages, I need to set some cookies. This leads me to what I call a Cookie Conundrum.

I can define a function to set cookies that is executed somewhere in the page (like rockets-main.lsp) But cookies are set in the header, using the line Set-Cookie. The header is the first thing printed out by the script, and I won't know what the cookie is until later in the script.

What Dragonfly does is caches everything being (print)ed and (println)ed into a big old global variable called STDOUT. Then at the very end of the script it prints the headers (which have already been calculated by the script) followed by STOUT. This involves overriding (changing the default behavior) of (print) and (println). I could do that, but is there a way to do it differently? Can you set a cookie and somehow have it remember to print that cookie in the next header on the following page?

It's something to think about...



Views: 3474


It's fast enough...


Post #: 21
Post type: Blog post
Date: 2012-09-21 06:49:09.000
Author: Rocket Man

Said Han Solo.

No, I'm totally going to add that stuff. Very cool.



Views: 3971


Topics


Rockets
Test