PDA

View Full Version : Ext.ux.EncryptionLoginForm



resTive
23 Apr 2011, 2:29 PM
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
24 Apr 2011, 6:02 AM
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
24 Apr 2011, 9:36 AM
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
24 Apr 2011, 9:37 AM
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
24 Apr 2011, 10:05 AM
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
25 Apr 2011, 2:31 PM
You can get creative on where you hide the salt. :)

dj
26 Apr 2011, 9:56 AM
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:

User types in his username
client side makes an AJAX request to the server to ask for the salt for this specific username (*)
user types in his password
client side calculates hash = md5(salt + password)
client side makes request with username and hash
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
27 Apr 2011, 2:12 AM
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:

User types in his username
client side makes an AJAX request to the server to ask for the salt for this specific username (*)
user types in his password
client side calculates hash = md5(salt + password)
client side makes request with username and hash
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
24 May 2011, 7:45 PM
it sounds great, could u plz put up a snapshot?

medusadelft
3 Jun 2011, 8:42 AM
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.

jmariani
23 Jun 2011, 12:57 PM
Are you sure your sha256 function behaves ok? Because it gives me very different values from sha256sum (a Linux command)

For the string "123"

Your function: a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3

echo 123 | sha256sum: 181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b

Regards.

ZeusTheTrueGod
24 Jun 2011, 7:52 AM
I see no reasons to send a hash of a password instead of the password itself. When your packets are intercepted the attacker will receive the hash instead of password. But that means the attacker will generate the same ajax request from him computer and send it to the server, because instead of comparing passwords your server compares hashes.

Just use https and don't simulate the security.

dj
26 Jun 2011, 11:58 PM
Are you sure your sha256 function behaves ok? Because it gives me very different values from sha256sum (a Linux command)

For the string "123"

Your function: a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3

echo 123 | sha256sum: 181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b

Regards.

You should use

echo -n 123 | sha256sum

echo adds a newline, so you did not generate the SHA256 sum of "123" but of "123\n".


I see no reasons to send a hash of a password instead of the password itself. When your packets are intercepted the attacker will receive the hash instead of password. But that means the attacker will generate the same ajax request from him computer and send it to the server, because instead of comparing passwords your server compares hashes.

Just use https and don't simulate the security.

Yes, it is a relative moderate security improvement to only send the hash of a password over the wire instead of the clear text password. The attacker doesn't know the password but nontheless can log into the account by just capturing the login request. But toss in some means to prevent replay attacks (like a timestamp and a nonce) and this solution becomes quite secure*. Even when you cannot switch your application over to SSL (e.g. because your hoster doesn't support it or you don't have the money for a certificate).

* = Only "quite secure" because sophisticated man-in-the-middle attacks are still possible.

urmilsetia
27 Jan 2013, 12:54 AM
Hi guys,

How can this be implemented in sencha touch 2.1