How not secure is this? in Developer Help

ID:778528
 
May 27 2012, 11:48 am
(See the best response by Keeth.)
Client New()

        client << browse_rsc('login_browse/background.png', "background.png")
        client << browse({"

        <html><body background=background.png scroll=no>

        <form action="?whatever" method="get">
            <input type="text" name="username" />
            <input type="password" name="password" />
            <input type="submit" value="Login" />
        </form>

        </body></html>"}
        ,

        "border=0;size=272x256;can_close=0;can_resize=0")


client topic

client
    Topic(href)
        //do whatever with href here
        alert(src, href)


It feels really not secure. How can I make it so the password isn't just being thrown around?
#1 May 27 2012, 11:51 am
#2 May 27 2012, 11:57 am
In response to The Motto (#1)
The Motto wrote:
You Can Look at This one http://www.byond.com/developer/Yusuke13/PasswordLoginDemo

Not relevant to browser forms.
#3 May 27 2012, 11:59 am
Maybe You Should be Saving It to A Save File
#4 May 27 2012, 12:03 pm
In response to The Motto (#3)
The Motto wrote:
Maybe You Should be Saving It to A Save File

The password is coming from a browser input. The input is then some how sent to the server. During this process, the password is completely exposed (look up html forms and the password input type). The solution is to run MD5 on it, but I don't know how to make that happen BEFORE it arrives at client.Topic(href). In other words, when the user clicks on the submit button in the html form which contains the password, the password needs to be encrypted before being sent to client.Topic.
#5 May 27 2012, 1:06 pm
Ok so the gist of what needs to happen here is when the input form button is clicked, the password is changed to the md5 value and then submitted to the server. The server then checks to see if that md5 value matches the md5 value stored on the server. The problem is, I don't know how to get the javascript to use the same md5() function from DM. I've tried other md5 type scripts from google code for example, but they don't produce the same results.
#6 May 27 2012, 1:11 pm
Wow, I got it to work! nvm!
#7 May 27 2012, 1:35 pm
You should not be relying on what the client gives you, in this case, to determine what to put in your database. Basically you're going to assume that what they're giving you is a valid MD5 hash, when they could spoof it and send you a string of 32 "a" characters. I don't really know of a way to secure the connection here, but I do know that relying on the client to format your data for you is just a bad idea in general.
#8 May 27 2012, 1:42 pm
The md5 hash of the password is what is sent, and what is saved.

The only way to generate that hash is to know the password.

Lets say you knew the hash of a user's password. If you put that hash into the password box, it would get hashed and wouldn't generate a match.

The only way to really take advantage of this is to circumvent the outgoing packet switching the form's data with your own hash that you would have had to obtain either using a packet sniffer on target's computer, or some other crazy method (monitoring the server's network traffic illegally?).
#9 May 27 2012, 1:45 pm
Here's how the client sends the information:

        client << browse({"

        <html><head>
            <script src="http://crypto-js.googlecode.com/svn/tags/3.0.2/build/rollups/md5.js"></script>
            <script>
                function hash(t) {
                    return CryptoJS.MD5(t);
                }
            </script>
        </head>
        <body background=background.png scroll=no onload="document.hashe.password.focus();">

        <form name="hashe">
            <input type="text" id="password" />
            <input type="password" id="username"  />
            <input type="hidden" name="location" />
            <input type="hidden" name="time" />
            <input type="submit" value="Login" onclick="location.value=hash(username.value);time.value=hash(password.value);" />
        </form>

        </body></html>"}
        ,

        "border=0;size=272x256;can_close=0;can_resize=0")


username and password values are actually not even included in the form (they have id instead of name, input controls without a name tag are ignored by form submissions). We do some confusing wording of values to try and throw script kiddies off (I've changed the words to meaningless crap in this example).
#10 May 27 2012, 1:51 pm
In response to FIREking (#8)
Best response
FIREking wrote:
Lets say you knew the hash of a user's password. If you put that hash into the password box, it would get hashed and wouldn't generate a match.

This isn't what I was really going for, but I am assuming you are using Javascript to handle all of this, right? Since it's all on the client's side. As such, if I wanted to, I could just open up the client-side form and make alterations, if I wanted to. I could make it not hash my password before sending it, and you would have no clue, cause you are just gonna take my word for it that it is hashed (cause that's how you set up the client to work).

There isn't necessarily anything wrong with this, except that faulty clients (perhaps those edited on purpose) will end up possibly registering an account with a password like "cakepie" as opposed to a real hash. And then they'd lose the ability to access that account without another edited client that allows you to bypass the hashing.

It's not a huge problem, I just wanted to let you know that people can do that if they want to. BYOND HTML pages are stored in the cache and are directly accessible, so I can edit them if I want to. Or if I was clever enough, I'd just spoof the entire form response and send my own.
#11 May 27 2012, 1:57 pm
Hmm, yeah the only time I see this being a problem is during registration. At which point we have to ensure that the password is actually being hashed.

Since md5 is always the same length, I could just check length during registration to make sure the client isn't modified.

I suppose then you'll raise me one by saying what if they make their password the same length as an md5 hash....

I dunno?

For what its worth, this is only the login form. I haven't written the registration form yet. I suppose I can do that in a much more secure environment (like requiring you to visit a php page that doesn't reveal what it does with any of the supplied information).
#12 May 27 2012, 2:39 pm
I could make the server only accept logins from a login server, and the login server will only display a back-end page. If the user tries to submit data in whatever way he wants using his own page, it won't be properly formatted like it would be from the login server therefore rejecting the data.

This could be easily accomplished by hosting a php script on a web host and making the client browse it. If you try to bypass using this page, your information won't be correct.