Unable to log into Bank of Melbourne internet banking: javascript obfuscation routine?

michaeltyson

I've recently discovered that my bank's Internet Banking system (https://ibanking.bankofmelbourne.com.au/ibank/loginPage.action) isn't letting me log in anymore; it took me a long time to figure it out, but it appears to be 1Password as logging in manually, copying and pasting the fields from 1Password, works fine.

If I then inspect the form submission, after a manual login, the actual transmitted password value is different each time. That suggests to me that they've got a javascript routine running on the text field's keypress/change event which obfuscates/encrypts the value (this seems to be the javascript that does the job: https://ibanking.bankofmelbourne.com.au/InternetBankingResources/ibank2/javascript/screen/logonCrypto/logonCrypto.js). That seems to be being bypassed when 1Password enters the values, even with automatic form submission disabled.

Is it possible to have the 1Password extension fire off keypress/change events immediately after filling in a value, so that sites that use this method can continue working with 1Password?

Cheers!

---

1Password Version: 6.2.1
Extension Version: 4.5.6.90
OS Version: 10.11.4
Sync Type: iCloud
Referrer: forum-search:internet banking

khad

Hi @michaeltyson,

Thanks for taking the time to contact us. I'm sorry that you are having some trouble.

They are definitely doing something wonky there. I just converted the password fields to text field and entered sequential digits into them. You can see what happens:

I'm not sure how we can account for their client-side obfuscation of those fields. The way 1Password works is actually not by simulating keypresses. This is more secure since it can't be intercepted by a keylogger.

It may be something we add in the future, but it would likely be part of a bigger feature that would work in other apps as well. I can't promise anything, but I'll add your vote for this. :)

michaeltyson

Indeed - however, I just looked into a bit more, and it looks like the obfuscation routines are indeed still being performed, so we're already 99% of the way there. If I put a breakpoint in the handler, it gets triggered when 1Password activates, and correctly replaces the value. Only, it appears that 1Password is resetting the value straight after, because if I continue execution, then use the console to query the field's value, it's gone back to the unobfuscated one. Might be an easy fix?

Cheers for the quick reply, by the way! Magnificent =)

littlebobbytables

Hi @michaeltyson,

That snippet of information may be of great interest to @jxpx777 who has been looking into this issue with these sites. I shall make sure he sees this post.

michaeltyson

Cheers @littlebobbytables =) I shall keep my fingers crossed. I honestly doubt the bank have the wherewithal to address the issue themselves (last time I called tech support, they asked me if I was using "a computer or a Mac", and whether I could try it in Internet Explorer. Not promising).

jxpx777

@michaeltyson Thanks so much for your analysis! I was neglecting this aspect of how 1Password does things. 1Password performs a few events automatically when filling pages: we focus the field, fire some events, set the value, fire some more events, and then check that the value is the same as it was. If not, we set it back.

This was a trick we discovered a long time ago to cope with some other sites' antics. It seems what you're seeing now is that 1Password setting this back is incorrect. In other situations we've seen that do anything like this, the transformed value is set in a hidden field or something like that.

In this case, the transformed value is set directly on the field. We do have a way to tell 1Password not to do this, but it would not trigger the events that presumably are triggering the obfuscation routines when 1Password fills as well. So, for the moment, it feels like we're a bit stuck.

--
Jamie Phelps
Code Wrangler @ AgileBits

michaeltyson

No worries! Ah, okay...probably shouldn't come as a great surprise; so many nonsense implementations out there, it stands to reason that there'll be no one-size-fits-all solution. If it's necessary to do that value-reset thing for some sites and not others, then all I could propose would be to put in a list of exceptions, but I guess I understand if that's a bit onerous. Would make my life a lot easier though =) For now, I guess it's back to copy-and-paste for me!

AGAlumB

@michaeltyson: I have no doubt that jxpx777 is contemplating a recipe for this site. I'm sorry that you're left to your own copy/paste devices here, but perhaps we (or the bank) will be able to come up with something better in the future (though I'm not holding my breath waiting for them). Thanks for you patience and willingness to work with us on this issue!

michaeltyson

No problem! It'll teach me for using a Mac instead of a computer anyway ;-)

AGAlumB

Wow. :lol:

jxpx777

I would honestly love to make a special exception for these sites, but given the parameters of our current code, this falls somewhere between the options we currently have. I could make a recipe that would simply set the value without triggering all the events and field value restoration, but I'm not sure it would trigger the obfuscation routines. We'll have to think on this one some more.

michaeltyson

Ah, okay, fair enough =) Well, thanks for the great support & communication, all the same. Much kudos.

AGAlumB

Any time! Thanks so much for your patience and willingness to worth with us on this issue. :)

rogermosborne

Hi there, I use (an Australian bank) StGeorge's internet banking website - https://ibanking.stgeorge.com.au/ibank/ - where the website appears to be changing the password data that is entered by the chrome extension and I was wondering if there was anything I could do within the app or extension which would allow me/1password to enter the information correctly.

Specifically, I think what is happening is the website is changing the entered data, when tabbing or on mouse click to the next field.
So as an example, if I were to type my password data in to the password field manually, upon tab or click to the next field, the website is changing the entered data. This then also results in 1Password offering to save my new password information every time I manually log in to the website.

No hurry, I have been putting up with this for more than 12 months. :-)

Thanks in advance.

---

1Password Version: 1Password 6 Version 6.3 (630032) AgileBits Store
Extension Version: Chrome 4.5.6.90
OS Version: OS X 10.11.5
Sync Type: 1Password for Families
Referrer: forum-search:stgeorge website changes password

littlebobbytables

Hi @rogermosborne,

I hope you don't mind but I've merged your post with an ongoing thread that we have regarding another Australian bank that is using the exact same library as yours is. Would I be correct in saying that you can't successfully create a working Login item for this site?

I fear the best we can do here right now would be to instruct 1Password to not ask to save new passwords for this site. The next time 1Password asks if you want to save a Login here click the cog icon in the bottom left hand corner of the 1Password - Save Login window. You will find an option in there that will instruct 1Password to Never Autosave for this Site so you won't be bugged in the future for just this one.

Would this help at all here?

rogermosborne

Thanks for flagging this post. Michaeltyson's issue is the exact same issue. Bank of Melbourne and StGeorge are owned by the same bank, Westpac, so makes sense that both sites are doing the same thing.

Will wait to see what comes next.

Thanks again

AGAlumB

Indeed. I really wish we had a good solution here, but we'll keep plugging away so that perhaps we will in the future. Thanks for your patience! :blush:

ref: BRAIN-123

michaeltyson

@brenty, @littlebobbytables - I've discovered something interesting with this problem; if I turn off the auto-submit feature, and then fill twice, then submit, the system logs in correctly.

AGAlumB

@michaeltyson: Wow. While I'm glad that workaround helps a bit, you really shouldn't have to do that...and I can't imagine many people would think to try that — I certainly wouldn't! We'll see what we can do to improve this.

michaeltyson

@brenty Yeah, it was a total fluke! Great, cheers for that

AGAlumB

:lol: :+1: