Hi Warren,

Might be an obvious question but instead of asking the iPhone / browser to do the encryption in script why not just add an SSL certificate on your ( or your clients ) server then any data sent to and forth can be encrypted.

Best regards,

Chris

Hi Warren, why don't you feel comfortable posting the password across the network? When people login the password will go over the network anyway.

Why not just post the raw password to base and then have asp.net encrypt the password? 

Kris

Hiya Chris,
Yeh unfortunately this is a small project and a SSL certificate cant be justified.

Cheers for the idea though.

Warren

Kris,
Doesn't the asp.net login control do some form of encrpytion when doing a logon?

Sending the password in clear text over a form post doesnt feel too safe, but yes the quickest way would be to send the password as it is and then do the encrpytion in the /base class.

However I just don't feel comfortable with that.

Warren

Well, there is a hole in your logic here, I think.

If you are sending the encrypted password via ajax, it is still sniffable. And if your ajax method signs you in based on that encrypted password, then I can still abuse you /base method, because it will actually sign me in even if I don't know the original password.

Or am I missing the point?

Hey Morten,
Yeh the encrypted password will still be sniffable but proivdes better security than just un-encrypted.

Here is my base method Morten:

public static string login()
{
    //Get the posted data
    HttpRequest post = HttpContext.Current.Request;
            
    //Get username and password from form posted data
    string username = post["username"];
    string password = post["password"];

    Member logonMember = Member.GetMemberFromLoginName(username);


    if (logonMember == null)
    {
        return "Error: Did not find member";
    }
    else
    {
        //User exists - check password
        if (password == logonMember.Password)
        {
            return "Success";
        }
        else
        {
            return "Error: Username and password do not match. Form pass: " + password + " memb obj pass: " + logonMember.Password; 
        }
    }

Morten or anyone else, if you can recommend an alternative solution to login in a member using just a <form> or AJAX I would like to hear from you.

Warren

(Small bit of background, I've been trying to help Warren with this off-forum, we've been bashing our heads with this for hours ... and just found the solution, here goes)

The problem with using the Crypto-JS library is that it encodes the characters using UTF-8, but when Umbraco encodes the password (via it's own Membership Provider), it uses UTF-16 ... so there's a mis-match between encodings - I don't "completely" understand it, but just know that it's "not the same".  So with that in mind, we tried out Paj's JavaScript MD5 script, (it also does HMAC SHA1, in the 'sha1.js'):

http://pajhome.org.uk/crypt/md5/index.html

Like Crypto-JS, all the native functions use UTF-8, but there are extra functions in there to handle UTF-16, so used the following snippet:

function b64_hmac_sha1_utf16(key, data) {
    return rstr2b64(rstr_hmac_sha1(str2rstr_utf16le(key), str2rstr_utf16le(data)));
}

Then we found another problem... that the base64 string wasn't being padded (with equals symbol =), but that was a quick fix.  At the top of the 'sha1.js' script, you can set the value of 'b64pad'.

var b64pad  = "=";

Now we get the correct Base64 encoded string of the HMAC SHA-1 hashed password... (jeez that's a mouthful!)

Right, time for a cuppa!

Cheers, Lee.

Well done Lee / Warren :)

I agree with Morten that without using SSL you are still passing the data insecurely, so if someone was to go to the effort of sniffing the data being passed to your server then with the encrypted data you are passing across ( in an un-encrypted form ) they can fake the login.

Maybe a way around this would be to pass a key from your server and then add this to the data that is encrypted and in your web service decrypt the data and remove the key element.

Just a thought :)

Even that would be crackable if they were determined and by the time you did implement all of this, it would have been cheaper to have bought a SSL certificate. If your client is so worried about security for the user logging in due to the possibility of the data being sniffed, what about all the data that is sniff-able once the user is logged in, if you are not using SSL everything can still be sniffed ( in theory ).

Cheers,

Chris

Hi Warren, the ASP.NET Membership provider will hash/encrypt the password (on the server side).  The login control still sends the password back to the server unsecurely unless you secure the entire transmission with SSL. 

You probably need to identify exactly what the security risk is that you're trying to address.  If it's network "sniffing", even if you encrypt the password in JS on registration, the user will still need to send the password back to the server on logon...  so the sniffer will get the password on logon instead.

However if you encrypt the password on the client side on login and registration, then you're still sending a payload which represents the password back to the server.  The sniffer would just re-send you're encrypted payload.

Try using Fiddler and logging in to some of your favourite websites and see your password sent in plain text :-)

I agree with the packet sniffing/security aspect... SSL is the way to go!  I was specifically helping out with the client-side HMACSHA1 encryption.

I have tackled this same situation for another client, we issued an authentication token from the server (a hash based on session id, client IP address and a pinch of salt), which would be passed back to verify the login ... it's probably got it's own flaws, but it served its purpose.

Cheers, Lee.

is working on a reply...