I was changing my password on Vaya mobile when I must have mistyped and an alert box popped up a little too quickly for a server-side validation to have occurred.
Turns out I was right: Screenshot
Edit: Looks like they're not escaping the password string, either: Screenshot 2
Is that the password you had set at the time, or a hash of it?
can confirm its plain text
Lol 'enterd'. Seeing how incompetent these guys are make me want to cancel my LiveConnected subscription. They even screwed up the billing multiple times after taking over LC.
I missed that bit.
So they have retrieved your password from their DB, decrypted it, and embedded it dynamically in some of the form JavaScript. Is that what you are suggesting?
Worse than that, the fact that they even can do this means that it was never hashed in the first place.
Yep. They emailed me the initial password in plaintext, which is not necessarily a no-no because they could still store a salted and hashed version. But then this happened…
Actually it is. Even if the email was sent at the time of password setting it is sus. On top on that email is completely insecure, so the second you send that email it is all over anyway.
None of this is even slightly acceptable.
I was thinking they might do it because of a security vs. convenience balance in the signup process.
Then I realised it's probably more inconvenient to ask people to change their password later, rather than have them choose it in the first place.
And the fact is that by this point they do already have and are securing your personal information, so I agree that none of this is acceptable.
That's ridiculous: the only person they're inconveniencing is the legitimate owner of the password.
Does anyone know if there is a good organisation to report this kind of thing to? Would EFA or a consumer group care?
There are regulations about data security, but I'm not sure who enforces them and how much they care.
The Office of the Australian Information commissioner. While a password isn't personal information, it can be used to access your personal information and under the NPPs they have a duty to ensure they have reasonable safeguards to protect against the unauthorised access to your personal information.
Have you posted this on Whirlpool? Vaya CEO often posts there. It's important he sees this!
Might not do that
don't we want this fixed?
Yeah, but I'm not a regular Whirlpooler and don't really know what flies over there. You're welcome to post it, though.
Please elaborate for those of us unfamiliar with code..
Are they storing your password locally when you log in?
They are storing the password on their servers. It is either unencrypted or encrypted with a system that can also automatically decrypt (passwords are normally hashed, which can never be unencrypted).
Then, presumably when you log in it is storing your id/password in session data on the server(easily hijacked by someone taking over your browser session). Once you 'log out' but don't clear your cookies this session data is still kept.
Next time you go to the log in page, it uses the session data to send the (plain text) password to your browser, so your browser can decide if the password entered is correct.
They are also sending the password over email, which is like broadcasting it publically.
On top of all this they are not escaping the password. As it is inserted into code you can be clever and create a password which itself has code and do… who knows what? This is likely a huge security risk.
Lastly if the password check is done locally in your browser, you can just modify this and bypass it and log into any account without a password. Don't know if they double up this check to stop this, perhaps G5 can check this?
In summary there is almost no rule/model/best practice/common sense on security that they are not breaking in some way.
Thanks Bruce
Still a bit over my head, but I follow 80% of what you're saying..
Even more concerning than I originally deduced.
Can anyone confirm the same issues on Live Connected?
Another thing: Because the browser is sent the password before you even enter it, it makes the 'log out' function completely useless (to anyone who knows this).
Website done by n00b
The issue isn't currently present on liveconnected, but the code is very similar so it may have just been recently removed.
Their website is programmed by noobs. I'm the developer of https://play.google.com/store/apps/details?id=com.blogspot.v…. I've found multiple privacy breaches in their website just because I'm poking it with a programmed http client that occasionally has a bug in it. I've found a situation where I could get everyone's contact details out of their website and another where I could get everyone's current month's call history and your phone number/name. Ben on Whirlpool managed to get them fixed up in less than a day or two though. You should definitely report this to him.
It does make me want to move to another provider but I can't find anywhere else that is anywhere near competitive for low use calls with a reasonable data allowance.
Ben also assures me that Vaya don't keep your credit card details on file. Their payment portal allegedly keeps that information so hopefully that is secure.
Who stores non-hashed passwords?
Is there any point of escaping the password string client side?
Well apart from not breaking your site if someone has a strange password, if they aren't escaping it for javascript, what is the chance they are escaping it anywhere else?
I can see how escaping it 'for' javascript is a problem (as is shown with Vaya), but that's because server side escaping wasn't done.
I'm asking is there any need to escape client side?
I don't understand your question. JavaScript is client side. Perhaps explain your question in more detail?
Realised I left out a 'not'. "I can see how not escaping it 'for' javascript is a problem".
So to clarify:
The code the OP screenshot probably would have been generated by something like this:
if (…current_pw.value !== <? echo "'" . $_GET['current_pw'] . "'" ?>)
Here the server (doing the echo) wasn't sanitising the input coming from the user.
I'm asking is there ever the need to have the client (javascript) escape input?
If the javascript ever does anything with user input, yes. In most cases though, the input is sent directly to the server with get/post/xmlhttprequest. First example I can think of that would have this problem is a comments box that does some sort of local magic.
Can you expand on the comments box example, what sort of local magic? I'm finding this thread enlightening, thank you both yourself and G5.
OK, perhaps you want when the user types in "fred" to automatically replace that with "[fred] (http://fred.com)". This would be done in js in the browser. If your script doesn't escape the entered text the user could enter bad stuff and make bad stuff happen. Note that this is not actually a security exploit though, because you can only change the local code and you can run whatever you want locally anyway.
Does anyone have any contact details of someone I can talk to there which can deal with some concerning security vulnerabilities which I know about on the site. There's a particular, very dangerous sec vulnerability which has been there from the very start (before the redesign). Thanks all.
Contact Ben on whirlpool here (use the whirlpool instant message - whim):
http://forums.whirlpool.net.au/user/514575
Apply some public pressure in this thread here if you don't get a response:
http://forums.whirlpool.net.au/forum-replies.cfm?t=2135163&p…
O M G..