Welcome Guest ( Log In | Register )

Outline · [ Standard ] · Linear+

Chat CIMB kena hack?

views
     
silverhawk
post Dec 18 2018, 06:18 PM

Eyes on Target
Group Icon
Elite
4,956 posts

Joined: Jan 2003


QUOTE(brkli @ Dec 18 2018, 02:29 PM)
no, the code snippet does not prove anything on how they store the password. it only shows thier 'lazy' development to do not want to change backend API, so they convert/translate those inputs (for this case password) as front end.
*
This is not necessarily the case. What the Javascript is doing is encrypting the password for transmission. If you read the code, it also does the same thing for username. You might ask.. why? Its to protect against sniffing or mitm attacks. This way even if an attacker sniffs out your traffic, its not obvious what your actual plaintext username/password is. They can still replay the request to get in, but at least they don't know what your actual username/pass is.. which you might be using for other sites as well.

The backend could then just decrypt the value, then run it through a different hash/encryption algorithm to check against the DB.

The stupid thing about CIMB was having a max limit on password length. Even now it doesn't make sense that its limited to 20 chars, if you're encrypting/hashing passwords the max length shouldn't really matter.
silverhawk
post Dec 19 2018, 03:41 PM

Eyes on Target
Group Icon
Elite
4,956 posts

Joined: Jan 2003


QUOTE(okuribito @ Dec 19 2018, 12:10 PM)
BUT I asked here and some people said that their old passwords were longer than 8 chars. In which case, logic says that CIMB must have the passwords stored As Is somewhere in their system
From what I understand, there were 3 steps to this

1. Passwords were allowed to be 8 or more characters
2. Rules changed, passwords allowed MAX 8 characters
3. Rules changed again, passwords allowed 8-20 characters

So if you had a password in (1) that was longer than 8 chars, it was truncated. Maybe the passwords were stored encrypted instead of hashed, so was possible to work out the original password and truncate it for (2).

QUOTE(okuribito @ Dec 19 2018, 12:10 PM)
With the benefit of the nasilemakTech rebuttal, they say the truncation to 8 chars is not an issue at all because ALL old passwords are 8chars long anyway.

IF that's true, yeah it's a non issue. But why need slice with substring(0, 8) ??


So which is it? Were old passwords pre 18Nov exactly 8 chars OR minimum 8 chars (ie longer also got) ??

PS: those who kena unauthorised transactions should flood nasilemak tech with proof / police reports etc (where's the batu api smiley  tongue.gif )

PPS: just saw the latest version of se7en's article ...  rclxms.gif  everything I talked about  is there  icon_idea.gif
*
They likely need to slice it because the backend does not know if this is a new/old password format. By right, backend should not care about such things. The fact that they slice says nothing about whether the passwords were stored as hashes or not.

Lets say your very old password was:

"lowyatisthebest"

Then CIMB stupidly changed their rules that passwords must only be 8 characters long, so your password now is:

"lowyatis"

They can hash this value, and since they hash it they will always need the 8 character version of your password to compare with the DB. They don't have to store it as plaintext. Its very unlikely that they are storing passwords in plaintext, wouldn't be able to pass any form of certification/audit if that were the case.


 

Change to:
| Lo-Fi Version
0.0522sec    1.64    7 queries    GZIP Disabled
Time is now: 17th December 2025 - 09:29 PM