Welcome Guest ( Log In | Register )

Outline · [ Standard ] · Linear+

 Is CIMB Clicks' password requirement bad security?

views
     
TSProdigenous Zee
post Apr 19 2014, 10:50 AM, updated 10y ago

Enthusiast
*****
Senior Member
736 posts

Joined: Mar 2008


CIMB Clicks requires their users to use exactly 8 characters as their password. If I understand password security correctly, as long as a website salts and hashes the password there should be no limit as to what the user wants their password to be. Even if it's 4 characters or 24 characters, in the end the hashed password will be the same length. So is there any possible reason as to why Clicks has this requirement? Or this is truly bad password security?
frederic9
post Apr 22 2014, 10:58 PM

Casual
***
Junior Member
391 posts

Joined: Mar 2005


Exactly 8 characters in a password is bad security?
There are primarily 2 trade offs:

The longer the password, the harder for automated tools to guess & brute force it that's all. Being exactly 8 characters, I eliminate guess all password between 1-7 characters, thus saving me maybe 1-2% of the work.

The longer the password also means it's harder for the user to remember them. As you grow older, passwords begins to follow common patterns for each site LOLx.

So technically, for it to be BETTER, CIMBClicks should set between 8-16 or more characters for password.
petirbuas
post Apr 23 2014, 02:03 AM

( 。◕ ‿‿ ◕。)
*****
Senior Member
898 posts

Joined: Dec 2009
From: The Internet



I think the actual concern is, why they need to be limited by 8 character to begin with.
Gee I hope they don't store my password in plaintext or db table somewhere tongue.gif

But come to think of it from user facing web application perspective,
- Reduce bruteforce & DOS attempt by allowing only certain dataset type & size as input

But my guess would be that its a decision by 'slightly' knowledgeable management,
- All other precedent bank does that. They seems to be ok and compliance with <xxx>, so why not?



Lord Tiki Mick
post Apr 23 2014, 09:34 AM

Regular
******
Senior Member
1,018 posts

Joined: Jul 2012
Even if you managed to break in, you can only view the account balance, and the victims pass transactions. To perform transactions, you need to have the TAC number.
alexng2208
post Apr 23 2014, 09:37 AM

Why my warn is 0%? i miss my high warn
*******
Senior Member
4,789 posts

Joined: Jul 2007
8 characters too limited

should be :

1. 64 characters
2. not more than 2 repeating
3. must contain equal number of alphabets, special alphabets, numbers, symbols, uppercase and lowercase
4. must not be a word in any language
5. must be changed every 3 days

is that good enough for you?
yen223
post Apr 23 2014, 11:43 AM

Enthusiast
*****
Senior Member
777 posts

Joined: Jul 2005
From: mars


QUOTE(Prodigenous Zee @ Apr 19 2014, 10:50 AM)
CIMB Clicks requires their users to use exactly 8 characters as their password. If I understand password security correctly, as long as a website salts and hashes the password there should be no limit as to what the user wants their password to be. Even if it's 4 characters or 24 characters, in the end the hashed password will be the same length. So is there any possible reason as to why Clicks has this requirement? Or this is truly bad password security?
*
You are right. Most of the secure hashing algorithms will return a fixed-length hash, which means that there's no need for an upper limit to password lengths. It is an indication of bad security practice - ie they are not hashing our passwords before storing it in the database, which means that our passwords are probably stored in plaintext in their database, which is bad.

Airasia is even worse. I don't know if they've changed this, but last time I clicked 'Forgot my password', they actually sent my exact password to my email - meaning they are definitely storing my password in plaintext somewhere!
dkk
post Apr 24 2014, 06:46 AM

10k Club
Group Icon
Elite
11,400 posts

Joined: Jan 2003
QUOTE(frederic9 @ Apr 22 2014, 10:58 PM)
Exactly 8 characters in a password is bad security?
There are primarily 2 trade offs:

The longer the password, the harder for automated tools to guess & brute force it that's all. Being exactly 8 characters, I eliminate guess all password between 1-7 characters, thus saving me maybe 1-2% of the work.

The longer the password also means it's harder for the user to remember them. As you grow older, passwords begins to follow common patterns for each site LOLx.

So technically, for it to be BETTER, CIMBClicks should set between 8-16 or more characters for password.
*
But why only 16. Why not 200 or 1000? As long as they want. This allows people too use passphrases instead of passwords. Those are easy to remember, long and harder to crack.

"Jack ate 7 bananas on 23 April" is easier to remember than "jet%JU.3"

Nobody is going to remember the later, and they will probably need to write it down somewhere. Sticky notes stuck on the computer screen compromises security as well.
TSProdigenous Zee
post Apr 24 2014, 10:32 AM

Enthusiast
*****
Senior Member
736 posts

Joined: Mar 2008


I think some of you are missing the point here. I'm not talking about good password practices, I'm talking about whether there are any reasons for a system putting limits on users' passwords.

QUOTE(yen223 @ Apr 23 2014, 11:43 AM)
You are right. Most of the secure hashing algorithms will return a fixed-length hash, which means that there's no need for an upper limit to password lengths. It is an indication of bad security practice - ie they are not hashing our passwords before storing it in the database, which means that our passwords are probably stored in plaintext in their database, which is bad.

Airasia is even worse. I don't know if they've changed this, but last time I clicked 'Forgot my password', they actually sent my exact password to my email - meaning they are definitely storing my password in plaintext somewhere!
*
Thank you for your clear answer. If the passwords can be sent back to the user, it might also mean that the passwords are just encrypted right? As long as the websites stores the encryption key then it shouldn't be a problem decrypting the password to send back to the user.
lawsh
post Apr 24 2014, 10:47 AM

Cikurity
*******
Senior Member
6,785 posts

Joined: Jan 2003
From: KL
QUOTE(petirbuas @ Apr 23 2014, 02:03 AM)
I think the actual concern is, why they need to be limited by 8 character to begin with.
Gee I hope they don't store my password in plaintext or db table somewhere  tongue.gif

But come to think of it from user facing web application perspective,
- Reduce bruteforce & DOS attempt by allowing only certain dataset type & size as input

But my guess would be that its a decision by 'slightly' knowledgeable management,
- All other precedent bank does that. They seems to be ok and compliance with <xxx>, so why not?
*
plaintext not allowed by regulators. BUT they have relation to you-know-who so anything can happen whistling.gif
i don't have a CIMB account to test but brute force is generally disallowed. account will be locked after too many failed attempts
the general perception of bank security is fairly wrong IMHO, only applies to bigger banks though

QUOTE(alexng2208 @ Apr 23 2014, 09:37 AM)
8 characters too limited

should be :

1. 64 characters
2. not more than 2 repeating
3. must contain equal number of alphabets, special alphabets, numbers, symbols, uppercase and lowercase
4. must not be a word in any language
5. must be changed every 3 days

is that good enough for you?
*
before answering, think of performance issues that comes with stronger encryption. safer vs slower, very delicate balance

3) dumbest suggestion
4) impossible:
a) where will you find such a dictionary for all languages?
b) if the checking is done on the browser, you will need to load the dictionary as well?
c) if not b, then you will have to send the clear password to the server --> bigger fail
5) good luck with that. customers will leave faster than you can read this

QUOTE(dkk @ Apr 24 2014, 06:46 AM)
But why only 16. Why not 200 or 1000? As long as they want. This allows people too use passphrases instead of passwords. Those are easy to remember, long and harder to crack.

"Jack ate 7 bananas on 23 April" is easier to remember than "jet%JU.3"

Nobody is going to remember the later, and they will probably need to write it down somewhere. Sticky notes stuck on the computer screen compromises security as well.
*
passphrase is good concept but not yet caught on
again, performance issues to be considered

QUOTE(Prodigenous Zee @ Apr 24 2014, 10:32 AM)
I think some of you are missing the point here. I'm not talking about good password practices, I'm talking about whether there are any reasons for a system putting limits on users' passwords.
Thank you for your clear answer. If the passwords can be sent back to the user, it might also mean that the passwords are just encrypted right? As long as the websites stores the encryption key then it shouldn't be a problem decrypting the password to send back to the user.
*
let's say that the textbox allows unlimited character and the webpage designer is stupid enough NOT to filter characters, it is possible to inject codes to perform malicious activities

good practice of password storing is 1 way hash ie cannot retrieve the password even if you have the encryption key. if it is like how you suggested, ANYONE who has the encryption key will be able to retrieve ANY password
alexng2208
post Apr 24 2014, 10:58 AM

Why my warn is 0%? i miss my high warn
*******
Senior Member
4,789 posts

Joined: Jul 2007
QUOTE(lawsh @ Apr 24 2014, 10:47 AM)
plaintext not allowed by regulators. BUT they have relation to you-know-who so anything can happen whistling.gif
i don't have a CIMB account to test but brute force is generally disallowed. account will be locked after too many failed attempts
the general perception of bank security is fairly wrong IMHO, only applies to bigger banks though
before answering, think of performance issues that comes with stronger encryption. safer vs slower, very delicate balance

3) dumbest suggestion
4) impossible:
a) where will you find such a dictionary for all languages?
b) if the checking is done on the browser, you will need to load the dictionary as well?
c) if not b, then you will have to send the clear password to the server --> bigger fail
5) good luck with that. customers will leave faster than you can read this
passphrase is good concept but not yet caught on
again, performance issues to be considered
let's say that the textbox allows unlimited character and the webpage designer is stupid enough NOT to filter characters, it is possible to inject codes to perform malicious activities

good practice of password storing is 1 way hash ie cannot retrieve the password even if you have the encryption key. if it is like how you suggested, ANYONE who has the encryption key will be able to retrieve ANY password
*
u have a serious case of sacarsm impairment
TSProdigenous Zee
post Apr 24 2014, 11:08 AM

Enthusiast
*****
Senior Member
736 posts

Joined: Mar 2008


QUOTE(lawsh @ Apr 24 2014, 10:47 AM)
let's say that the textbox allows unlimited character and the webpage designer is stupid enough NOT to filter characters, it is possible to inject codes to perform malicious activities
*
Interesting, I've never heard about this before. What characters are usually filtered out to prevent such attacks?

Lord Tiki Mick
post Apr 24 2014, 11:15 AM

Regular
******
Senior Member
1,018 posts

Joined: Jul 2012
QUOTE(Prodigenous Zee @ Apr 24 2014, 11:08 AM)
Interesting, I've never heard about this before. What characters are usually filtered out to prevent such attacks?
*
Usually comments character for sql. There're other possible injections that needs to be filtered correctly.
lawsh
post Apr 24 2014, 11:19 AM

Cikurity
*******
Senior Member
6,785 posts

Joined: Jan 2003
From: KL
QUOTE(Prodigenous Zee @ Apr 24 2014, 11:08 AM)
Interesting, I've never heard about this before. What characters are usually filtered out to prevent such attacks?
*
not the full list, just some examples

CODE

"
'
\
\\
-
--
<
>


for your reading pleasure

http://en.wikipedia.org/wiki/Data_validation
https://www.owasp.org/index.php/Category:Injection
mikicun
post Apr 24 2014, 11:21 AM

Casual
***
Junior Member
444 posts

Joined: Nov 2006
From: somewhere i belong...
QUOTE(alexng2208 @ Apr 23 2014, 09:37 AM)
8 characters too limited

should be :

1. 64 characters
2. not more than 2 repeating
3. must contain equal number of alphabets, special alphabets, numbers, symbols, uppercase and lowercase
4. must not be a word in any language
5. must be changed every 3 days

is that good enough for you?
*
is this good enuf?
user posted image
alexng2208
post Apr 24 2014, 11:23 AM

Why my warn is 0%? i miss my high warn
*******
Senior Member
4,789 posts

Joined: Jul 2007
QUOTE(mikicun @ Apr 24 2014, 11:21 AM)
is this good enuf?
user posted image
*
ok seems legit

u pass rclxms.gif

*change cabbage to Spinach does the trick
yen223
post Apr 24 2014, 11:43 AM

Enthusiast
*****
Senior Member
777 posts

Joined: Jul 2005
From: mars


QUOTE(Prodigenous Zee @ Apr 24 2014, 10:32 AM)
I think some of you are missing the point here. I'm not talking about good password practices, I'm talking about whether there are any reasons for a system putting limits on users' passwords.
Thank you for your clear answer. If the passwords can be sent back to the user, it might also mean that the passwords are just encrypted right? As long as the websites stores the encryption key then it shouldn't be a problem decrypting the password to send back to the user.
*
The reason why network security folks recommend servers use password salt+hash, is so that they can do password validation without having to know what the original password is. This means that even if their database gets compromised, the users' passwords are still safe, because they never stored the original passwords in the first place.

For this reason, encryption is not a good solution, because it means that the original passwords are still being stored in the database. If the attacker has access to the database and to the encryption key (which usually isn't stored in a secure location), then he will have full access to the user's passwords.



malleus
post Apr 24 2014, 12:25 PM

Look at all my stars!!
*******
Senior Member
2,096 posts

Joined: Dec 2011
QUOTE(lawsh @ Apr 24 2014, 10:47 AM)
let's say that the textbox allows unlimited character and the webpage designer is stupid enough NOT to filter characters, it is possible to inject codes to perform malicious activities
aren't unlimited characters and injection characters 2 different things?

1) on the webpage designer issue, this ought to have been caught in the testing phase and the web designer shot in the head
2) the layer that accesses the DB ought to have filtered out such characters. this is also why its never a good idea never to build your SQL query strings by hand. use either an existing ORM library or at least Prepared Statements.
ragk
post Apr 25 2014, 10:48 AM

BooBoo~
*******
Senior Member
2,265 posts

Joined: Apr 2009


lol, remind me of KSWP account. None of my friends remember the password. Simply over complicated.
wKkaY
post Apr 25 2014, 02:43 PM

misutā supākoru
Group Icon
VIP
6,008 posts

Joined: Jan 2003
Mathematically, any limitation that is imposed will decrease security because the search space is smaller. Even minimum chars, maximum chars, must have special chars numbers etc.

But humans tend to be bad RNGs so developers need to save them rolleyes.gif

 

Change to:
| Lo-Fi Version
0.0213sec    0.27    6 queries    GZIP Disabled
Time is now: 29th March 2024 - 05:54 AM