1. #1
    Sencha User
    Join Date
    Mar 2009
    Posts
    9
    Vote Rating
    0
    resTive is on a distinguished road

      0  

    Default Ext.ux.EncryptionLoginForm

    Ext.ux.EncryptionLoginForm


    Hi there,

    i have build a simple Loginform including some simple MD5 encoding within another Ext.ux.

    Implements a simple Ext.form.FormPanel as a Loginform with encryption
    capabilities. This is the form only, so it can be embedded into a window or
    static panel, or whatever (i hope ;-)).
    Can be configured as any other FormPanel, with some exceptions:
    - fixed anchor layout (anchor 100%)
    - fixed items (logo-container, login/password-field)
    - fixed buttons

    Some new config options added:
    - Simple Encryption support:
    a type-string or function which performs the encrpytion. This type
    has to be defined in Ext.util.Format or it has to be a function.
    Currently supported types (in Ext.ux.Encryption) are 'md5' and
    sha256'. The type 'md5' is the general fallback if type could not be
    determined.
    Example:
    PHP Code:
    [...]
    encryption: {
        
    active:true,
        
    type:'md5'

    One parameter will be passed to the specified function, expecting the
    value to be encoded. If encryption is activated but no function could
    be found, encryption will be deactivated.

    - Submit configuration
    Since you want to perform some actions after pressing the login button you
    have to specify at least the success and failure callbacks. You are
    allowed to specify any other config avaible in Ext.form.Basic#doAction
    Example:
    PHP Code:
                 submitConfig: {
                   
    waitMsg:'Performing login...'//optional
                   
    waitMsgTargettrue// show msg direct in form.
                   
    success: function(formaction) {
                     
    alert('success')
                   },
                   
    failure: function(formaction) {
                     
    alert('falure')
                   }
                 } 
    - loginLabel
    Labeltext for the login field. Defaults to 'Login'.

    - passwordLabel
    Labeltext for the password field. Defaults to 'Password'.

    - loginButtonText
    Text for the login button. Defaults to 'Login'.

    - resetButtonText
    Text for the reset button. Defaults to 'Reset'.

    - hideResetButton
    True to hide the reset button, false to show. Defaults to false.


    Within the form is a logo-container specified. This Ext.container.Container
    has a 60px height and an additional CSS-class called encryptedloginform-logo.

    Complete example:
    PHP Code:
    Ext.onReady( function() {
         
    Ext.QuickTips.init();
         var 
    loginWindow Ext.create('Ext.Window', {
             
    title:'Login',
             
    modal:true,
             
    closable:false,
             
    resizable:false,
             
    items: [{
                 
    xtype:'encryptionloginform',
                 
    preventHeader:true,
                 
    border:false,
                 
    width500,
                 
    url:'login.php',
                 
    defaults: {
                 
    labelWidth:100
             
    },
     
             
    hideResetButton:false,
             
    resetButtonText:'My Reset Text',
             
    loginButtonText:'My Login Text',
             
    loginLabel:'Custom Login',
             
    passwordLabel:'Custom Password',
     
             
    encryption: {
                 
    type:'md5',
                 
    activetrue
             
    },
     
             
    submitConfig: {
                 
    waitMsg:'Performing login...',
                 
    waitMsgTargettrue,
                 
    success: function(formaction) {
                     
    alert('success')
                 },
                 
    failure: function(formaction) {
                     
    alert('falure')
                 }
             }
         }]
    });
    loginWindow.show();
    }); 
    Finished the wall of text. A working example is attached.
    Any criticism would be appreciated.

    Update #1
    Changed the way encryption works as mitchell supposed.
    The Encryption class got divided into two seperate scripts (no more classes) and extend the Ext.util.Format class to its corresponding hashing algorithm.
    Encryption.MD5.js
    Encryption.SHA256.js

    the encryption config now takes following parameters:
    PHP Code:
    [...]
    encryption: {
        
    active:true,
        
    type:'sha256' // or 'md5' or 'whatever' or Ext.util.Format.md5 or My.namespace.Class.function
    },
    [...] 
    greetings
    resTive
    Attached Files
    Last edited by resTive; 24 Apr 2011 at 9:30 AM. Reason: first update

  2. #2
    Sencha - Senior Forum Manager mitchellsimoens's Avatar
    Join Date
    Mar 2007
    Location
    Gainesville, FL
    Posts
    37,345
    Vote Rating
    847
    mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute

      0  

    Default


    MD5 is good but not everyone wants to use MD5. To further your idea, you could make separate classes for each encryption or add the encryption methods to the Ext.util.Format singelton. This way you could have a config object to use MD5 or SHA or whatever.

    Just an idea
    Mitchell Simoens @SenchaMitch
    Sencha Inc, Senior Forum Manager
    ________________
    Check out my GitHub, lots of nice things for Ext JS 4 and Sencha Touch 2
    https://github.com/mitchellsimoens

    Think my support is good? Get more personalized support via a support subscription. https://www.sencha.com/store/

    Need more help with your app? Hire Sencha Services services@sencha.com

    Want to learn Sencha Touch 2? Check out Sencha Touch in Action that is in print!

    When posting code, please use BBCode's CODE tags.

  3. #3
    Sencha User steffenk's Avatar
    Join Date
    Jul 2007
    Location
    Haan, Germany
    Posts
    2,664
    Vote Rating
    7
    steffenk has a spectacular aura about steffenk has a spectacular aura about steffenk has a spectacular aura about

      0  

    Default


    good idea

    I mostly use the BE for encryption, and with salted passwords it's no problem to submit a plaintext password.

    In general the important part (at least for me) is the submit useing ssl
    vg Steffen
    --------------------------------------
    Release Manager of TYPO3 4.5

  4. #4
    Sencha User
    Join Date
    Mar 2009
    Posts
    9
    Vote Rating
    0
    resTive is on a distinguished road

      0  

    Default


    thx mitchell for your suggestion.

    i have updated. the first post.

    since i am not able to change the attachement, because of the following error

    PHP Code:
    PATHS is not defined
    http
    ://www.sencha.com/forum/clientscript/vbulletin_quick_edit.js?v=411
    Line 11 
    i attach a working example to this post.
    Attached Files

  5. #5
    Sencha User
    Join Date
    Mar 2009
    Posts
    9
    Vote Rating
    0
    resTive is on a distinguished road

      0  

    Default


    Quote Originally Posted by steffenk View Post
    good idea

    I mostly use the BE for encryption, and with salted passwords it's no problem to submit a plaintext password.

    In general the important part (at least for me) is the submit useing ssl
    thx

    first what is the BE? google gives me thousands of links, no idea what could be meant.

    i am not really familar with password security within 'open' systems. i usually work within heavily secured intranet environments where the security requirements are handled wide before my application needs a login

    nevertheless, its time to do so. i never heard about salting passwords, so i asked google and think you mean something like:
    PHP Code:
     sendHash hash(password salt) + salt 
    not hard to implement. but why should it be more secure since my 'salt-string' has to be placed anywhere on the page, so an possible intruder gets this 'salt-string' too.

    i think i miss something. can u point me on some web-links to this. perhaps this would lead us too far away from the scope of this, so feel free to pm me.

    and, of course, SSL should be used on server-side.

    greetings
    resTive

  6. #6
    Sencha User aw1zard2's Avatar
    Join Date
    Sep 2009
    Location
    Dallas, Texas
    Posts
    577
    Vote Rating
    32
    aw1zard2 has a spectacular aura about aw1zard2 has a spectacular aura about

      0  

    Default


    You can get creative on where you hide the salt.

  7. #7
    Ext JS Premium Member dj's Avatar
    Join Date
    Mar 2007
    Location
    Germany
    Posts
    573
    Vote Rating
    2
    dj has a spectacular aura about dj has a spectacular aura about dj has a spectacular aura about

      0  

    Default


    Hi resTive,

    BE = Backend -> you server-side code

    Salted passwords are used to combat rainbow tables: http://en.wikipedia.org/wiki/Rainbow_table - so you do have a benefit of using a random salt that you save in addition to the hashed password.

    But your system – where the hash is generated on the client side and only the hash is presented to the backend – is hard to do with salted passwords. If you would want to use salted passwords, the backend would have to send the salt for the given user over the wire so that the client side could generate the hash. Something like this:
    1. User types in his username
    2. client side makes an AJAX request to the server to ask for the salt for this specific username (*)
    3. user types in his password
    4. client side calculates hash = md5(salt + password)
    5. client side makes request with username and hash
    6. backend compares the stored hash with the presented hash


    ... you could of course use a single static salt all the time. That would be not that good as using a different, random salt for each user, but nevertheless would prevent a normal rainbow table attack.


    (*) = the backend sould respond to EVERY request with an answer. If the username does not exists, just send back a random salt. So an attack could not harvest valid usernames.


    PS: To further improve security you could have a look at http://en.wikipedia.org/wiki/Replay_attack and implement the outlined countermeasures.
    Daniel Jagszent
    dɐɳiel@ʝɐgszeɳt.de <- convert to plain ASCII to get my email address

  8. #8
    Sencha User
    Join Date
    Mar 2009
    Posts
    9
    Vote Rating
    0
    resTive is on a distinguished road

      0  

    Default


    Quote Originally Posted by dj View Post
    Hi resTive,

    BE = Backend -> you server-side code

    Salted passwords are used to combat rainbow tables: http://en.wikipedia.org/wiki/Rainbow_table - so you do have a benefit of using a random salt that you save in addition to the hashed password.

    But your system – where the hash is generated on the client side and only the hash is presented to the backend – is hard to do with salted passwords. If you would want to use salted passwords, the backend would have to send the salt for the given user over the wire so that the client side could generate the hash. Something like this:
    1. User types in his username
    2. client side makes an AJAX request to the server to ask for the salt for this specific username (*)
    3. user types in his password
    4. client side calculates hash = md5(salt + password)
    5. client side makes request with username and hash
    6. backend compares the stored hash with the presented hash


    ... you could of course use a single static salt all the time. That would be not that good as using a different, random salt for each user, but nevertheless would prevent a normal rainbow table attack.


    (*) = the backend sould respond to EVERY request with an answer. If the username does not exists, just send back a random salt. So an attack could not harvest valid usernames.


    PS: To further improve security you could have a look at http://en.wikipedia.org/wiki/Replay_attack and implement the outlined countermeasures.
    thank you daniel,

    great answer, ill see what i can do with this information.

  9. #9
    Sencha User atian25's Avatar
    Join Date
    Oct 2008
    Location
    china
    Posts
    114
    Vote Rating
    2
    atian25 is on a distinguished road

      0  

    Default


    it sounds great, could u plz put up a snapshot?
    @from: china
    @web: http://atian25.iteye.com
    @extensions: (extjs 4.x)
    * Ext.ux.grid.plugin.RowEditing - add some usefull features (v1.4 updated 2011-09-11)
    * Ext.ux.button.AutoRefresher
    * Ext.ux.form.field.DateTime

  10. #10
    Sencha User
    Join Date
    Apr 2007
    Posts
    172
    Vote Rating
    1
    medusadelft is on a distinguished road

      0  

    Default


    Hi,

    In the update you mentioned that the encryption has been updated and now also sha256 supports.
    Is it correct that it is not supported in the zip-file?

    Any progress on the other suggestions?

    Thanks for this script/example!
    Maurice.