ISP: Your login detail is insecure. (Clientzone)

[ranger]

Hi Prophet

The only way to secure that information would be to use SSL. Unfortunately most of our website (except the customer zone) runs on normal http (for performance reasons). This means that we're unable to post to a secure server and read the response due to cross domain scripting limitations.
http://en.wikipedia.org/wiki/Same_origin_policy

Don't run on separate domains.

Web Africa, Axxess and Cybersmart are "insecure" by that standard. The only reasons why the other guys are secure is because they don have a global login.

All of TIs apps are SSL. Yes, we don't have a "global login" at present, but that is because we have been prevented from building a portal because the fixed-line guys want *their* portal to be *the* portal (because they've thrown so much money at it), but haven't been able to support us integrating to them until now.

 

[ranger]

what about email or IM? Sensitive information is transmitted via those (and many other mediums) almost universally across the internet, and its by and large unencrypted, what can we do about those?

All decent mail applications and platforms support PGP/MIME and S/MIME, and all decent IM protocols (e.g. XMPP) support PGP and/or OTR, and you should use clients that support those if you intend passing any confidentail information over them.

Are you trying to change the subject here? Why?

 

[Necuno]

All of TIs apps are SSL. Yes, we don't have a "global login" at present, but that is because we have been prevented from building a portal because the fixed-line guys want *their* portal to be *the* portal (because they've thrown so much money at it), but haven't been able to support us integrating to them until now.

Stupid question... who is this we ?

 

[coralsea]

There are some old but common password hashes which only store sufficient information to validate the first 8 characters, such as DES (sometimes referred to as crypt). I am not aware of any that only support 6, but if if was 8 characters, then most likely MWEB's mail platform was using crypt.

Yeah, I'm pretty sure it was 6 characters — I don't have a mailbox to test anymore, but it could be 8, which would make sense with 'ol crypt. But given that they have capable mailservers and the ease of setting up things to use stronger hashes if applicable, it still stinks of bad security design and complete lack of proactive attention.

But it doesn't really help that 2 years ago I went to pick up a friend who was doing some work at a call-center and showed me that the main account passwords are just sitting around in plaintext. Things might have changed, but they have never called for old accounts to update their passwords.

One only has to remember their blunder in transferring business accounts a few years back.

Obviously it's tricky to upgrade hashes for infrequent users - but at the same time, it's something that should be promoted and made clear to people. I like knowing that companies which I use are taking logical steps to look after my data and are confident enough to be open about it.

But hey, standard bank don't offer optional SSL for their main pages because its 'bad for the environment' and as such 'irresponsible' and then link a study from 1996 about the additional cpu time required (They also require that you use the link on the non-https front page to access internet banking, failure to do this means they will accept no responsibility for anything going wrong.). Pentium Pro's sure are relevant today Also according to them, XML does not require ampersands within a node to be stored as an entity — it's merely unrelated that their portal chokes on them!

A bag more of those which sadly are too terrible to disclose publicly.

 

[Necuno]

I guess WA has gone on vacation for the week.

 

[w1z4rd]

ISP: Your login detail is insecure. (Clientzone)

Is your ISP sending your login detail as plain text or is it actually encrypted ?

Which leaves the question what are these ISPs doing:

Openweb: PASS?
Axxess: PASS, though not sure about second GET
Afrihost: PASS
CyberSmart: PASS
Mweb: PASS
Telkom: PASS, not exactly sure where you login

WebAfrica: FAIL



/starts putting them to the [-]text[/-] test


Obviously if I have made an err, then I'll correct it

Are you using https or http?

 

[Necuno]

Are you using https or http?

The pictures isn't clear enough?

 

[Necuno]

Thanks for the feedback, while it’s a fairly low-risk you are right in the sense that the login could be made even more secure, and anything that we can do to improve security is always a win.

We’re looking into it, and will feedback.

I do not think it is proper to offer me vouchers, I'd rather see the issue fixed.

 

[w1z4rd]

The pictures isn't clear enough?

Would have been useful info in your OP. Surprised people login to anywhere without https :/

 

[Necuno]

Would have been useful info in your OP. Surprised people login to anywhere without https :/

Is this better?

Is your ISP sending your client zone detail as plain text or is it actually encrypted ?

Which leaves the question what are these ISPs doing:

Pass:
Openweb: PASS ? - HTTPS
Afrihost: PASS - HTTPS
Mweb: PASS - HTTPS
Telkom: PASS - HTTPS

Fail:
CyberSmart: FAIL ? - HTTP ***
Axxess: FAIL ?, though not sure about second GET - HTTP ***
WebAfrica: FAIL - HTTP


:edit
Now one might ask why is this a bad thing?
Well for one if I casually intercepted your unencrypted detail, it would be very easy to log in and lie dormant. There is no need to abuse, just watch and collect info.

What if I made an err in the OP?
Obviously if I have made an err, then I'll correct it


::edit
*** Apparently Axxess and Cybersmart is also insecure according to Webarica:

Hi Prophet

The only way to secure that information would be to use SSL. Unfortunately most of our website (except the customer zone) runs on normal http (for performance reasons). This means that we're unable to post to a secure server and read the response due to cross domain scripting limitations.
http://en.wikipedia.org/wiki/Same_origin_policy

If you can show me a reliable cross-browser technique to get around this issue, then we'll implement it.

Web Africa, Axxess and Cybersmart are "insecure" by that standard. The only reasons why the other guys are secure is because they don have a global login.

Web Africa
http://i45.tinypic.com/ff2s1u.png

Axxess
http://i46.tinypic.com/9vkx3k.png

Cybersmart
http://i46.tinypic.com/333d11y.png

 

[Necuno]

Interesting.

ISPA:

Apologies for the delay in replying.

As a general rule, ISPA expects its members to follow appropriate security RFCs as per clause 28 of the ISPA Code of Conduct.

It is a little tricky for ISPA to have any specific opinion on the matter without a bit more context, but if you think any ISPA member is running an insecure system, you are welcome to lodge a Code of Conduct complaint against them - http://ispa.org.za/code-of-conduct/

In such a case, the relevant ISPA member will have an opportunity to resolve the matter informally, and if there is a genuine security concern, they may be happy to have the matter brought to their attention.

Code of conduct:

F. Cyber crime

16. ISPA members must take all reasonable measures to prevent unauthorised access to, interception of, or interference with any data on that members network and under its control.

J. Internet standards

28. ISPA members must operate with due regard for established Internet best practices, as set out in the various request for comment (RFC) documents and as mandated from time to time by established and respected Internet governance structures.

 

[Necuno]

Is it a bad thing to make use of cookies in this manner? Just curious, because AFAIK one should rather encrypt what is set.

left is chrome on the right is notepad using C:\Users\<current user>\AppData\Local\Google\Chrome\User Data\Default\cookies

Would be interesting to see if that is same behaviour on other isps.

:edit
wakevinr has kindly informed me that they are now hosting the login window in a iframe within ssl, will retry with fiddler tomorrow

::edit
SSL/HTTPS confirmed, OP amended

 

[Necuno]

However, if you have made this massive oversight. I'm wondering how you store these passwords and info on your db. Especially credit card info.

Usernames for one isn't case sensitive. This is confirmed when you look at how they handle the "stay-in" cookie****. If your username is aAbDC then you can log in with either AABDC or AAbdc since they always default to AABDC.

****I had to block out detail

:edit
These username as case insensitive seems to be a thing with various isps as mweb, axxess, afrihost and webafrica is accepting username as case insensitive.

 

[Centaur]

Storing the info as plain text in the cookie, shows that they don't really know what they are doing. To think, not even popular free forum scripts do that. I don't think they really know what hashing is. That is why they can display the last few characters of the password in the logs. Seeing that a good hash, is supposed to be one-way, but now they are accessing parts of it. This shows that they simply store the password as plaintext or they encrypt everything with the same key. So if their db got exploited and their servers, the key would be found and everyone's login details will be gone as well.

A lot of free open source scripts for forums and ecommerce use salted hashtags nowadays. It is shocking that an ISP (like WebAfrica) can't do the same.

For the webafrica representative that sees nothing wrong in the plaintext cookie. You are supposed to put in a unique code string, that identifies the user. There are various ways you can do it, but just putting in the username and password is pathetic. And you need to clean up these strings after some time. Since it is a cookie, so it is supposed to be temporary.

With WA, the usernames are really short, and they all follow the same format. So its super easy to guess a different user's username. Atleast some of the other ISPs only use the email for logins.

 

[Necuno]

Storing the info as plain text in the cookie, shows that they don't really know what they are doing. To think, not even popular free forum scripts do that. I don't think they really know what hashing is. That is why they can display the last few characters of the password in the logs. Seeing that a good hash, is supposed to be one-way, but now they are accessing parts of it. This shows that they simply store the password as plaintext or they encrypt everything with the same key. So if their db got exploited and their servers, the key would be found and everyone's login details will be gone as well.

A lot of free open source scripts for forums and ecommerce use salted hashtags nowadays. It is shocking that an ISP (like WebAfrica) can't do the same.

For the webafrica representative that sees nothing wrong in the plaintext cookie. You are supposed to put in a unique code string, that identifies the user. There are various ways you can do it, but just putting in the username and password is pathetic. And you need to clean up these strings after some time. Since it is a cookie, so it is supposed to be temporary.

With WA, the usernames are really short, and they all follow the same format. So its super easy to guess a different user's username. Atleast some of the other ISPs only use the email for logins.

It is first three letters of your surname with two numerics by default. Axxess is the same, AFAIK openweb also sports something short which you couldn't change.

 

[waroop]

Hi Guys,

Thanks again for all the feedback.

Regarding the plain-text cookies; I am fully in agreement with you that this is not good enough. I'll make sure that we get this fixed.

 

[Necuno]

Hi Guys,

Thanks again for all the feedback.

Regarding the plain-text cookies; I am fully in agreement with you that this is not good enough. I'll make sure that we get this fixed.

Thank you. That is good news.