I guess this code snippet was lifted off the net today? ie current code, right?

Haven't read all posts here, but remember reading something about a recent change by CIMB to allow longer pw & with special characters?

And because some incompetent coder wrote the above snippet, hence the exploit was created?

Help me understand the logic...

if PW is at least 8char long, and includes special chars, then the entire pw string is passed to encryption function

if PW is at least 8char long, and dun include special chars, then the long pw is truncated & the front 8char string is passed to encryption function

if PW is < 8char long eg 7char or less, irrespective got special characters or not, then what happens? Won't password = password.substring(0, 8) evaluate to #error? Previously, wasn't there a minimum # of characters for passwords ie 8?

PS: i dunno coding. only trying to make sense of the if-then-else which is also used in excel

hahaha TQ


Thanks bro, but can pls help explain the IF statement ....

Doesn't the && operator mean that BOTH conditions must be met in order to use the entire string entered by user?

And if "checking for the password length <8 chars is already done before calling this function" then why include the password.length >= 8 condition in this IF statement? Redundant or not?

In se7en's article, he also say "IF password CONTAINS SPECIAL CHARCTERS, ACCEPT WHOLE password," implying length already check b4hand.....

LOL the coder that dumb ka???

PS: once again, hor, me dunno coding

just like they dun actually store our passwords but the hash of our passwords, right?? LOL or do they

adoi, have I been online for too long? what's with the funky timestamps? billysteel quoted a post from the future ka?

because they dunno who to ban? the offending user's identity not established, right?

or do they ban based on your device id? any more tries from ur device will be disallowed to proceed for next x periods?

I just read on FB someone complain his hp contact # for his cimb acct was changed without his knowledge. Come to think of it last time my Ambank account also experience the same thing. so lesson learnt is to go do some transaction regularly to test if still get OTA/TAC on own phone

This post has been edited by okuribito: Dec 17 2018, 09:19 PM

lidat i think cannot ler. If i know your username (eg I have a keylogger planted in your system) & i wanna sabo u, i login & give silly pw few times. u'll get locked out oso dunno why

The matrix say passwords pre 18Nov must be exactly 8 character long & special character is not a requirement - that means cannot be less or more than 8 character BUT special characters are allowed but not mandatory, right?





so how did JohnLai do it? so what if he's overseas? How it work? damn curious

This post has been edited by okuribito: Dec 18 2018, 12:33 AM

Something doesn't seem right to me. Everywhere I look, I'm told that passwords are stored after (one-way) hashing (& even salting), never in its original form.

When you originally set up your password as 12345678H%&*GGhklp, it would have been stored as a certain hash. Any slight diff would result in a totally diff hash. (That's why they say they do not know what your password is)

So what boggles me is how someone can get in when he submits 12345678 - the hash for that would definitely be diff from the hash for 12345678H%&*GGhklp ...No?

The only possibility this can happen is IF at the point you originally set up your password as 12345678H%&*GGhklp, it was truncated to 12345678... damn FUBAR, right? Telling ppl to set up long complex pw & truncating to short

The password that you set was longer than 8character right? Were you ever able to use your password in full before?

hahaha not surprised- gomen dept CIMB is a bank ler. If true they store password in original form then BNM should withdraw their licence IMHO. For that matter doesn't BNM do IT system audit on licensed FI's ?

so let's say your old pw was 12345678H%&*GGhklp ...

1. before 18 nov, were you able to get in with just 12345678? with 12345678H? or only with 12345678H%&*GGhklp?

2. After 18 nov, were you able to get in with just 12345678? with 12345678H? or only with 12345678H%&*GGhklp?

curious to figure out what cimb is doing

hahaha let's not go down that road ler. anything that happen to one bank can reverberate throughout the entire system. I'm sure bnm folks realise and understand that

Thx bro, saw that & thinking thru the implications. How does CIMB store passwords? As Is? or after hashing?

If after hashing, old passwords longer than 8char should not be able to get in if just key in first 8 chars. Why? becos the hash would be diff. No? Only way can get in is IF the old password was stored As Is. Wonder if that makes sense

silverhawk the encryptedPass = MFPInit.encrypteMY(password) is the encryption u mentioned, right? Curious, isn't that encryption done by the user's browser based on the bank's ssl cert for security during transmission? Based on the fact that pre-18Nov passwords can be used when truncated to 1st 8 characters, I strongly believe they store raw passwords somewhere in their system. If they ONLY store hashes, there's nothing to compare when shortened old passwords are submitted! Did I misunderstand anything?

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) ??

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

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 )

PPS: just saw the latest version of se7en's article ... everything I talked about is there

This post has been edited by okuribito: Dec 19 2018, 12:20 PM

omg look like a shitstorm out there! what a mess ler

Adoi, we have the author himself here LOL I read your 2 articles

So in both articles, you imply that old passwords cannot be longer than 8 chars? That means less than 8 chars also can? That's pretty extreme ler ... no minimum length ka? And confirm nobody ever could create passwords > than 8 chars in the past?

In the first article you said "old passwords do not support or contain special characters" Then in your 2nd article you said "old password consists of letters, numbers and symbols(just not a requirement)" Got or not?

TIA

That makes sense! And I did not even think about storing in encrypted form. But then again, encrypted form is only slightly better than AsIs / plaintext, isn't it? The argument for 1way hash is so that even if server/DB is broken into OR backup media is lost/stolen as rumored, you can still sleep at night. Encrypted means reversible ler. No?

At the end of the day, I think it all hangs on whether passwords were allowed to be > 8 characters in the past (your step1) AND if yes, how they dealt with those when they changed to MAX 8char (your step 2)

IF passwords were never allowed to be >8 char, then this substring slicing code is plain stupid because anything without special char & > 8 char MUST be invalid & rejected off the bat!

IF passwords were allowed to be > 8 chars, AND if not mandatory changed to 8 char, then the substring slicing is indicative of some downright scary approach to password management

Anecdotal evidence I found:

This thread in 2014 discussed CIMB's 8 char limit. But could it be that this represents your step 2? Maybe before 2014, > 8 char passwords were allowed? PS: See 2010 T&C below

sevenegg said he had password > 8 char before

boonhan also said he had longer password before

PS: 2010 CIMB Clicks T&C - says minimum 8 chars



This post has been edited by okuribito: Dec 21 2018, 12:54 PM

Nov 2017 oredi in the news. Google cimb backup tape lost stolen missing for news article

Really fubar d

This post has been edited by okuribito: Dec 21 2018, 05:25 PM