Ext.ux.EncryptionLoginForm

[resTive]

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:

[...]
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:

             submitConfig: {
               waitMsg:'Performing login...', //optional
               waitMsgTarget: true, // show msg direct in form.
               success: function(form, action) {
                 alert('success')
               },
               failure: function(form, action) {
                 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:

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,
             width: 500,
             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',
             active: true
         },
 
         submitConfig: {
             waitMsg:'Performing login...',
             waitMsgTarget: true,
             success: function(form, action) {
                 alert('success')
             },
             failure: function(form, action) {
                 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:

[...]
encryption: {
    active:true,
    type:'sha256' // or 'md5' or 'whatever' or Ext.util.Format.md5 or My.namespace.Class.function
},
[...] 

greetings
resTive

[mitchellsimoens]

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

[steffenk]

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

[resTive]

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

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.

[resTive]

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:

 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

[aw1zard2]

You can get creative on where you hide the salt.

[dj]

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.

[resTive]

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.

[atian25]

it sounds great, could u plz put up a snapshot?

[medusadelft]

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.