A securerer login page



  • First off: fuck you Community Server, for breaking the BACK button and making me type this all over again.

    I graduated just under a year ago.  I've kept my college email going just for larks-- though this means I have to keep on top of the 45-day password change policy. While that's a wtf, it isn't the wtf.

    After changing the password, I got forwarded back to the college's Content Management System portal page, which is powered by Blackboard (much in the same way you can power a light bulb between your teeth by rubbing a gerbil against a sweater, stuffing it up an orifice, then jumping into a washing machine full of leaky car batteries).

    Now, if any of you have used Blackboard before, you'll know its a Ring Cycle of wtf, bad design, horrible UI, and all around crappiness (much like Community Server...grrr!)

    I figured; why not test out the new password?  Typity-type-- click submit-- only to end up at the vanilla login page with the error "No credentials were submitted".  Not bad usernme/password.  That's odd, though, because I can see my user name and starred out password right there.

    Oh, wait, I say, seeing the familiar red-S at the bottom-right. I must not have whitelisted the school's site through No Script yet.  I'll just hit Temporarily All… wait a minute.
    Okay, I'm all about the whole "don't disable a chunk of a site then complain when you break functionality" thing-- but why does a login page need Javascript-- especially to the extent that not having it completely breaks the login mechanism?

    CTRL-U to the rescue!  A quite peruse, and-- well, here's the gem:




    <FORM ONSUBMIT="return validate_form(this)" METHOD="POST" ACTION="https://youknowmyname/webapps/login/" NAME="login" >

               <INPUT VALUE="login" NAME="action" TYPE="HIDDEN">

                    <INPUT VALUE="" NAME="one_time_token" TYPE="HIDDEN">
                    <INPUT VALUE="" NAME="encoded_pw" TYPE="HIDDEN">
                    <INPUT VALUE="" NAME="encoded_pw_unicode" TYPE="HIDDEN">

    Var _userChallenge = false;
    function validate_form(form)
    {
      form.user_id.value = form.user_id.value.replace(/^\s*|\s*$/g,"");
      if ( form.user_id.value == "" || form.password.value == "" )
      {
        alert( "Enter a username and password." );
        return false;
      }

      //short-cut if challenge/response is disabled.
      if ( !_useChallenge )
      {
        form.encoded_pw.value = base64encode( form.password.value );
        form.encoded_pw_unicode.value = b64_unicode( form.password.value );
        form.password.value =  "";
        return true;
      }
    // … snip unreachable code …
    }



    Okay, for those TL;DR folks: screw you, too. Get an attention span.

    For everyone else, here's quick rundown of what its doing:


    -    Going into an always-true if statement (uhh, okay, maybe its some debugging something-- though the unreachable code was even more retched)
    -    Encoding my password in base64-- {checks for that S in the https, yup, its there}
    -    Encoding the password in a different way, but in UNICODE!
    -    Clearing the password box (because, and maybe I'm wrong on this, an HTML password box certainly doesn't clear itself when you go back to the page…)
    -    Filling in some "hidden" values on the page with the encoded text
    -    Submitting


    So, and let's try to keep the brains-leaking-out-nose:brains-remaining-in-skull ratio low, it is…
    Encoding my password-- then encoding it again-- then sending it over an HTTPS connection-- to a server which (I pray to Shiva) already has my password encoded (though a one-way Hash would be nicer)-- all the while breaking the Submit button.

    Did no one stop to think that if the client-side is compromised, then they can just steal my password before the hash?  And if their https sessions are compromised, then they have much bigger problems on their hands?  (Double so if the authentication server is compromised?)
    AND that by providing a second data point, it only makes it easier to crack my password?

    The worst part of this?  Just hours before seeing this, I was catching up on my archived wtfs. I came across [url=http://thedailywtf.com/Comments/The-Revealing-Spreadsheet.aspx#238147]this post[/url] and thought to myself, "This must be a troll, because no one would actually do that!".

    Sidenote: If you are someone who would actually do that, please cc all replies to [url=http://www.blackboard.com/company/careers/open.postings.Bb] Blackboard's Career section[/url]

    Sidenote 2: Community Server's preview function is broken, so I'll just hope my formatting will work.
     




  •  We use Blackboard too.  I feel your pain.  At least our Math department got so fed up that they rebelled and set up a Moodle server.

    Oh, and just to add to the WTFness of Blackboard, it turns out that when a teacher needs to make a correction to anything posted on his or her Blackboard class page, the corrections are not pushed to the students until sometime around 2am the next morning.  One of my professors last semester was angered by this quite a bit.



  • @halcyon1234 said:

    So, and let's try to keep the brains-leaking-out-nose:brains-remaining-in-skull ratio low, it is…
    Encoding my password-- then encoding it again-- then sending it over an HTTPS connection-- to a server which (I pray to Shiva) already has my password encoded (though a one-way Hash would be nicer)-- all the while breaking the Submit button.

    Did no one stop to think that if the client-side is compromised, then they can just steal my password before the hash?  And if their https sessions are compromised, then they have much bigger problems on their hands?  (Double so if the authentication server is compromised?)
    AND that by providing a second data point, it only makes it easier to crack my password?

    Well, first off, there's absolutely no more information in the unicode encoded string rather than the ascii version, from any cryptological or information theory point of view.  A second *identical* data point is not a second data point!

    And secondly, the only WTF here comes from your misinterpretation of what they're doing.  They're not base64 encoding it in order to protect it in any way at all; base64 is an encoding, not an encryption.  I think they're encoding it simply to canonicalise it nicely and not have to bother about escaping or quoting.

    Do you have TamperData installed?  See what happens if you insert an apostrophe in the middle of the base64 encoded password string! 

    Err.. actually if you're hoping to keep on sneaking about the college mail account after leaving, maybe you don't want to draw that kind of attention to yourself.

    @halcyon1234 said:


    The worst part of this?  Just hours before seeing this, I was catching up on my archived wtfs. I came across this post and thought to myself, "This must be a troll, because no one would actually do that!".

    Surely tha'ts not the same thing at all, your form is at least using a POST, so nothing goes in the querystring at all?




  • Re the silly base64 and unicode hidden values, I suspect the designer didn't have a clue about char sets and how to stop the browser having to wrongly guess the char set, and the code you see was their attempt at hacking around the fundamental flaw in their server side code. I've met people who didn't know there were chars outside of ASCII and people who couldn't understand why anyone would use a comma in place of a decimal point... these are things every developer has to face in the end.



  • @DaveK said:

    nd secondly, the only WTF here comes from your misinterpretation of what they're doing.  They're not base64 encoding it in order to protect it in any way at all; base64 is an encoding, not an encryption.  I think they're encoding it simply to canonicalise it nicely and not have to bother about escaping or quoting.
     

     Okay, point conceded.  But that just raises a further wtf:  If the two pieces of data are identical, what the heck is the point of having a second one?  Just in case the first one gets lost?

     [quote user="DaveK"]Do you have TamperData installed?  See what happens if you insert an apostrophe in the middle of the base64 encoded password string! [/quote]

    Oh jeeze, it gets worse.  Okay, I just installed TamperData (neat tool, thanks).  I was going to check things out, just to see what the outbound data looks like.  And get this-- that chunk of javascript doesn't actually work. It still submits password=hunter2&enc_password=&uni_enc_password=

    So they need Javascript enabled to submit the login form, so that a chunk of javascript can run-- that does nothing.



  •  And it also seems that this product is from the same people who produced a bug like this:

    http://seclists.org/bugtraq/2004/Jun/0155.html

     Basically, I upload my Super Sensitive Assignment.  It gets stored at http://website/files/4747/myfile.txt

    A classmate uploads theirs, and it gets stored at http://website/files/4748/theirfile.txt

    And as long as you are logged in, you can download any file you can throw an URL at.  So I just increase/decrease that incremental "id" subfolder name.  In most cases, an assignment will be uploaded using a common file name, ie "Upload your file as firstname_lastname_a3.zip".

    Admittedly that's a bit esoteric, and from 2004-- but there's also reports of HTML and SQL injection attacks as recently as 2007.  Any major release, "mature", in-production product these days that can be SQL injected--  wtf; drop database--



  •  Feel for me, I'm an admin for this crappy system.

     The reason that they aren't encrypting the password is that your College are using an LDAP server for authentication and the Blackboard system needs to pass the correct password back to the LDAP server.

    If your College were using Blackboards default authentication (with passwords stored in the Blackboard database), then the variable _userChallenge would be set to true (it gets set on the backend systems depending on the authentication type) then your "unreachable code" would be reached.  For the record, it looks like this:

      var passwd_enc = hex_md5(form.password.value);
    var encoded_pw_unicode = calcMD5(form.password.value);
    var final_to_encode = passwd_enc + form.one_time_token.value;
    form.encoded_pw.value = hex_md5(final_to_encode);
    final_to_encode = encoded_pw_unicode + form.one_time_token.value;
    form.encoded_pw_unicode.value = calcMD5(final_to_encode);
    form.password.value = "";
    return true;

     

    where they do indeed encrypt the password (twice if you count the unicode version.)  If you want to see the different md5 functions they are available at http://bbservername/javascript/md5.js and http://bbservername/javascript/md5-legacy.js

     

    Now for the WTF though, if you use TamperData you can change the uni_enc_password field to any string you like (just don't leave it blank) and as long as the password for enc_password is correct it will happily let you login.  The backend authentication seems to completely ignore the unicode password as long as it contains something!

     

    And don't get me started on actually using Blackboard.



  • @smallpygmy said:

     The reason that they aren't encrypting the password is that your College are using an LDAP server for authentication and the Blackboard system needs to pass the correct password back to the LDAP server.
     

    If you're using https, why should that be a problem? If you aren't using https: is your data "valuable" enough to make up for a ssl investment? e.g. can nothing impact your study (like in our BB system) or can students e.g. (un)enroll into test which is neccesairy to take them?



  • The whole system needs javascript to work, it utterly breaks the second you disable it. The university I go to also uses that system, and Community Server is honestly light years ahead compared to Blackboard. I think you could have a decently long research paper explaining everything that is wrong with it. It merits a front page post at least though. You wouldn't even need to dramatize, it's bad enough as it is.



  • @halcyon1234 said:

    @DaveK said:
    nd secondly, the only WTF here comes from your misinterpretation of what they're doing.  They're not base64 encoding it in order to protect it in any way at all; base64 is an encoding, not an encryption.  I think they're encoding it simply to canonicalise it nicely and not have to bother about escaping or quoting.
     

     Okay, point conceded.  But that just raises a further wtf:  If the two pieces of data are identical, what the heck is the point of having a second one?  Just in case the first one gets lost?

    Who can truely claim they know the ways of the WTF?  But the moral is this: when someone doesn't seem to know what they're doing, they probably don't know what they're doing in multiple ways... 

    @halcyon1234 said:

    [quote user="DaveK"]Do you have TamperData installed?  See what happens if you insert an apostrophe in the middle of the base64 encoded password string! 

    Oh jeeze, it gets worse.  Okay, I just installed TamperData (neat tool, thanks).

    [/quote]Oh yes!  Oh yes indeed! ;-) muahahaahahaha!

    @halcyon1234 said:

    I was going to check things out, just to see what the outbound data looks like.  And get this-- that chunk of javascript doesn't actually work. It still submits password=hunter2&enc_password=&uni_enc_password=

    So they need Javascript enabled to submit the login form, so that a chunk of javascript can run-- that does nothing.

    Well, I did wonder one thing: was the difference between "_userChallenge" and "_useChallenge" there in the original source, or was it a typo in transcription/anonymisation when you posted the story?


  • @smallpygmy said:

     Feel for me, I'm an admin for this crappy system.

     @smallpygmy said:

    Now for the WTF though, if you use TamperData you can change the uni_enc_password field to any string you like (just don't leave it blank) and as long as the password for enc_password is correct it will happily let you login.  The backend authentication seems to completely ignore the unicode password as long as it contains something!

     

    And don't get me started on actually using Blackboard.

    LOL.  This "Blackboard" software seems to account for about 30% of articles in 2600 magazine these days!(*)

    (*) - Statistics falsified for purposes of satire, but pretty good for a first approximation...


  • @smallpygmy said:

     The reason that they aren't encrypting the password is that your College are using an LDAP server for authentication and the Blackboard system needs to pass the correct password back to the LDAP server.

    If your College were using Blackboards default authentication (with passwords stored in the Blackboard database), then the variable _userChallenge would be set to true (it gets set on the backend systems depending on the authentication type) then your "unreachable code" would be reached.  For the record, it looks like this:

     

    Yup, that's the snipped code, line for line.  I was going to write about it, but my cerebral cortex broke.  They're hashing the password-- twice-- on the client side-- and creating a MD5 hash-- to verify the integrity of the hash.

     Except I have a better way of verifying the integrity of the hash:  if (client_hash = stored_hash) then login = yes;

     



  • @DaveK said:

    Well, I did wonder one thing: was the difference between "_userChallenge" and "_useChallenge" there in the original source, or was it a typo in transcription/anonymisation when you posted the story?
     

    Oops, yup.  Both instances should be _useChallenge.  I had to double check, because I wouldn't put it past them to muck up a variable name. =)



  • @Heron said:

     We use Blackboard too.  I feel your pain.  At least our Math department got so fed up that they rebelled and set up a Moodle server.

    Oh, and just to add to the WTFness of Blackboard, it turns out that when a teacher needs to make a correction to anything posted on his or her Blackboard class page, the corrections are not pushed to the students until sometime around 2am the next morning.  One of my professors last semester was angered by this quite a bit.

    Really? We use Blackboard as well, and I've always noticed changes updating instantly. Unless I've misread the problem. Personally I love Blackboard (from an end user perspective) but then going from WebCT that's possibly a relative thing



  • @halcyon1234 said:

     Except I have a better way of verifying the integrity of the hash:  if (client_hash = stored_hash) then login = yes;

     

    No, you missed the 'one time token' thingy. That is important to stop a replay attack. It's essentially a challenge response mechanism, and is pretty much the best you can do in Javascript without writing a full PKI system in Javascript.

    Yes, you may have HTTPS, so you don't need the hashing, but maybe Blackboard will work without https, in which case a challenge response hash mechanism is better than a plain text password, or a normal hashed password.

    As for clearing the password after 'encoding' it. That becomes much more obviously necessary when you start doing the hash rather than just base64 encoding the password. There's no point sending a hashed password if you send the raw password as well. (again, not necessary with https, but with http it is necessary).

    The base64 encoding is there because the client end needs to get the original password since it is being passed to a third party authentication mechanism. (No it doesn't NEED to be base64 encoded, but I don't see that as a big issue)

    The 'unreachable' code is simply so that 99% of the javascript on the webpage is constant, and only a few bits (such as a flag saying whether to do client side hashing) are set by server side code.

    I'm not sure I can come up with an excuse for the unicode encoded password, but the rest of this particular instance seems reasonable once you accept the possibility of it being used over an unencrypted session.

     

     



  • @Flatline said:

    Really? We use Blackboard as well, and I've always noticed changes updating instantly.
     

    I guess I'm just taking that professor's word for it, I don't know from personal experience.


Log in to reply