Thread

Hey guys,

Just wanted to let you know that I’ve updated the docs with all of the suggestions I could remember or find on this thread.

Please let me know if you find anymore errors, omissions, or have any suggestions.

http://benedmunds.com/ion_auth/

Thanks!

Well done Ben.

Hey guys,

Just wanted to let you know that I’ve updated the docs with all of the suggestions I could remember or find on this thread.

Please let me know if you find anymore errors, omissions, or have any suggestions.

http://benedmunds.com/ion_auth/

Thanks!

Nice Ben!
already used your docs 😊

Hi guys, very nice lib Ben but I find a little issue.

When you try to update only a field like “email” in user table there is a DB issue.

First “must use db->set()” because trying to make an db->update without any set (l.823).
And then “unknow column user_id on table users” because just update users table (l.835).

So I’ve made this little fix if it could be help someone 😊 :

if (!empty($this->columns))
{
    // have to update?
    $makeUpdate = FALSE;

    foreach ($this->columns as $field)
    {
        if (is_array($data) && isset($data[$field]))
        {
            $makeUpdate = TRUE;
            $this->db->set($field, $data[$field]);
            unset($data[$field]);
        }
    }

    if($makeUpdate) 
    {
        $this->db->where($this->meta_join, $id);
        $this->db->update($this->tables['meta']);
    }
}

ben, just 5 mins reading your documentation. I decide to switch from dx_auth to your ion.
It was very clear, I love it.

Interesting library, good job. But to be honest, there are some pieces of code I don’t like at all.

Like the way “remember me” cookies are being stored. I would NOT recommend to store your password in cookies. Even when it’s sha1() encrypted. Concat fields, use salts, tokens… Whatever you prefer, but storing password in a file this way, it is just so risky.

Great job anyway 😊

Interesting library, good job. But to be honest, there are some pieces of code I don’t like at all.

Like the way “remember me” cookies are being stored. I would NOT recommend to store your password in cookies. Even when it’s sha1() encrypted. Concat fields, use salts, tokens… Whatever you prefer, but storing password in a file this way, it is just so risky.

Great job anyway 😊

For me $rmbcode = sha1(sha1(password + salt));

Well it’s not very good but not too bad at all… The way to reverse a sha1 is not very easy so…

These days modern browsers remember passwords for you, so I don’t think it’s a bad idea to rely on them, specially if your app contains _VERY_ sensitive data. Anyway, Drupal’s persistent login aproach does minimise impact a lot. It works this way:

- When the user successfully logs in with Remember Me checked, a login cookie is issued in addition to the standard session management cookie.[2]

- The login cookie contains the user’s username, a series identifier, and a token. The series and token are unguessable random numbers from a suitably large space. All three are stored together in a database table.

- When a non-logged-in user visits the site and presents a login cookie, the username, series, and token are looked up in the database.

- If the triplet is present, the user is considered authenticated. The used token is removed from the database. A new token is generated, stored in database with the username and the same series identifier, and a new login cookie containing all three is issued to the user.

- If the username and series are present but the token does not match, a theft is assumed. The user receives a strongly worded warning and all of the user’s remembered sessions are deleted.

- If the username and series are not present, the login cookie is ignored.

http://jaspan.com/improved_persistent_login_cookie_best_practice

maltzurra,

I don’t store the password in a cookie dude.  I’m just storing an sha1 of the password as the remember me salt in a cookie.

Hey Ben,

I noticed you are not storing the password, but you are storing a sha1(password) which is, in these days, far from ideal imho. It’s not that hard to get the password once you know the encrypted value. Just a matter of time.

It was just a personal recommendation as I feel a kind of obsession with security 😊

What is more secure?

storing salt in the database separately or not?

Interesting library, good job. But to be honest, there are some pieces of code I don’t like at all.

Like the way “remember me” cookies are being stored. I would NOT recommend to store your password in cookies. Even when it’s sha1() encrypted. Concat fields, use salts, tokens… Whatever you prefer, but storing password in a file this way, it is just so risky.

Great job anyway 😊

For me $rmbcode = sha1(sha1(password + salt));

Well it’s not very good but not too bad at all… The way to reverse a sha1 is not very easy so…

Double hashing isn’t actually more secure than hashing something once. You’d be better off using a secret key (a very long one that is) and a hashing algorithm such as sha512.

Maltzurra,

I definitely see your point.  I’ll go through and examine that code soon to see how to make it more secure, I’ll probably just create a random salt instead of the sha1 of the password as the remember code but I’ll post on here once it’s updated.

Thanks,

Dreamer111,

They are both pretty equal.  Not storing them separately (the default) should probably be considered a little more secure as the encryption algorithm is a little more complicated.

Just tried out the library - surprised that duplicate usernames can be registered with different email addresses.  When/why would anyone want this functionality?  I feel like most people would want to sign in with either username or email.  Can you describe the thought process behind allowing one or the other to be unique instead of requiring BOTH to be unique by default? 

I just can’t see it being useful to allow duplicate usernames registered under different emails, or duplicate emails registered under different usernames.  Actually seems like it could lead to confusion and identity issues.

Maybe I’m missing something, just hard to imagine that this works for real world sites.