ISP: Your login detail is insecure. (Clientzone)

[wamatt]

Now I'm not being a dick, I'm highlighting a concern here. Would be interesting to get ISPA's take on this. I think I'm going to pass this by them on Monday for WebAfrica, Cybersmart and Axxess.

Think it's worth point out the major sites exhibit the same behaviour, and by the same argument, 'insecure'.

Wikipedia (https://img.skitch.com/20120803-xbiyciqmiefjiwranqs5mis474.jpg)
Reddit
etc

Even Facebook until recently (with 900m+ users) also used plain text http logins, before they decided to force HTTPS across the board.

Also I believe for those that specifically want SSL, going to www.webafrica.co.za/client directly forces SSL.

That said, I'm also a bit uneasy in general of plaintext passwords, even if the practical risks are low. Especially considering things like Firesheep and public unsecured wifi.

PS speaking in my personal capacity. I am not the CEO.

 

[Centaur]

Ahm, your post is completely illogical. Show me a major banking site, or shopping portal, that gives you an insecure login page. Since, an ISP is a service that is offered, which contains all the user's info, you can't compare it to Wikipedia or Reddit, etc.

 

[wamatt]

Ahm, your post is completely illogical. Show me a major banking site, or shopping portal, that gives you an insecure login page. Since, an ISP is a service that is offered, which contains all the user's info, you can't compare it to Wikipedia or Reddit, etc.

Fair enough. Banks I should hope are using full HTTPS across their sites. I'm not sure about all shopping sites.

What is interesting is IINet for example, much larger than our ISP's here in SA, also uses a http login page on their homepage. So it seems it's a well established practice.

But @Kev, if you take a look at IInet and Internode, while the homepage is HTTP, but it appears like it may be passing the info securely still using HTTPS.

I'm not 100% on how that works and if it is in fact secure. But check this out:

Internode https://img.skitch.com/20120804-ct41apipebyta8bewwgegxm1fh.jpg

There is also an "https" everywhere movement, that seems to be gaining some momentum.

https://www.eff.org/https-everywhere/

Wonder if we will see any ISP's going full SSL in the future.

 

[wamatt]

FWIW, this is rather a fun and complex issue in general

More on StackOverflow:

http://stackoverflow.com/questions/274274/is-it-secure-to-submit-from-a-http-form-to-https

If what some of those answers are saying is true, then even HTTP->HTTPS suffers from MITM attacks and is insecure.

http://en.wikipedia.org/wiki/Man-in-the-middle_attack

 

[koeksGHT]

We've pushed a change live earlier, can you guys please double check?

I have noticed that when you get redirected from your account to your control panel it logs in using GET and the in the URL are the username and password in clear text.. Doesn't seem too safe, maybe a bruteforce attack.

On that note, will make a small script tomoz to try crack the control panel login

 

[wamatt]

It's worth noting that mint.com (an extremely popular personal finance site, with full access to your bank accounts), used to allow http, but have since forced the entire site to https.

While I've yet to see any ISP's website do this, maybe this the way to go...

 

[HavocXphere]

Frankly I find the responses in this thread more alarming than anything else.

The only reasons why the other guys are secure is because they don have a global login.

Unfortunately most of our website (except the customer zone) runs on normal http (for performance reasons).

it’s a fairly low-risk

None of those responses are giving me that warm fuzzy feeling - especially not the part about plain text passwords being low-risk.

Even if it is low risk - simple business sense would suggest that plastering the entire website full of ssl is a winning move: The only thing most customers know is that they're supposed to look for that small lock thing.

Now in this particular case I'm not particularly concerned in practice (DSL Secure, accessed from secure PC etc) - but as a matter of principle the above does not fly.

 

[Centaur]

Forcing the entire site over a secure protocol is definitely the way to go. Especially a site that works with money and people's info.
It will give that extra trust. Since a lot of people look for that lock when they want to buy something. Also, the speed decrease these days with modern browsers and fast internet, is fairly negligible.

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.

 

[wamatt]

Disclaimer: Views are personal and I'm not part of management at WA though do try to be naturally as impartial as possible. This particular topic is of greater general interest to me as well.

None of those responses are giving me that warm fuzzy feeling - especially not the part about plain text passwords being low-risk.

Yeah, I can see how you'd feel like that. I personally used to want a strong "Confident Sounding Message[SUP]TM[/SUP]" from the top brass of any company I was doing business with. But over time observed that positive messaging seemed to hardly ever correlate, with actual security or competence, and was more to do with people's feelings of security. The reality always is nearly always more shaded and complex, than simple assurances.

So few companies actually come out and say, "Hey guys, yeah are systems are a ****". Many would be surprised how much really sloppy stuff goes on behind the scenes and across the board. Humans are simply not infallible, no matter how big or important sounding the company is.

If anyone is interested, I highly recommend anything by the legendary security demigod, Bruce Schneier. His recent TED talk on the feeling of security vs the actual state of security is particularly good:

http://www.youtube.com/watch?v=wQJC2MMB8nA

The economics are very also interesting. Like in terms of encryption software, often it's actually cheaper to make people feel secure, than be secure, which unfortunately creates a rather big market incentive, to be evil.

I'm wondering how you store these passwords and info on your db. Especially credit card info.

It's encrypted within the DB, and the keys I believe are stored seperately with a pretty strict access protocol and audit. I'm not sure of the exact details though, I'm just remember from a security overview meeting a few years back, so my mem is probably a little hazy

 

[coralsea]

I'm not sure if anything has changed, there are some pretty funny holes in the smaller ISP's stuff last I looked - but the one that made me smile was mweb.

I know that internally they don't store passwords as hashes (anyone in the call center can view any account password in plaintext), but it was quite funny to notice that their mailserver had been specifically modified to only check the first 6 characters of a password (if you put more, they are discarded silently - almost certainly they are not using hashes here either) - some sections of their pages also choke on punctuation. Pretty sure the mailserver still only checks the first 6

Then again, when you look at how Standard**** deal with security - you'll understand just how small ISP problems are.

 

[waroop]

especially not the part about plain text passwords being low-risk.

I agree with you, and we're going to see how we can tighten this up - like Kev said wherever we can improve security in a practical way we'll absolutely do it, but heres another one; 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?

 

[Necuno]

Not much to add after HavocXphere and Centaur already said what I would have said.

 

[waroop]

Not much to add after HavocXphere and Centaur already said what I would have said.

Noted. Thx for the help guys, leave it with us and we'll get it patched up first thing next week.

This has actually sparked some interesting internal discussions around potentially making the entire site https - what are your thoughts on that?

 

[HavocXphere]

I personally used to want a strong "Confident Sounding Message[SUP]TM[/SUP]" from the top brass

As I see it there are two things that companies must get right. 1) Security 2) Perceived security.

So perhaps security isn't majorly threatened in this case...but a bit more grace in handling it would be good. Meaning either "We're going to fix it by doing X" or "It is not possible because Y". The responses above fall right between those two - the worst of both worlds.

And yes, I'm quite aware of the fact that in the real world security is always going to fall short of 100% & solutions often contain a fair amount of duct-tape.

mweb.

I know that internally they don't store passwords as hashes (anyone in the call center can view any account password in plaintext)

OMG I hope you're joking. The issues mentioned in this thread so far are largely cosmetic, but passwords stored in plaintext is totally not cool. Has to be hashed & salted - no exceptions. LinkedIn just found that out the hard way (they skipped the salted part).

 

[Centaur]

Noted. Thx for the help guys, leave it with us and we'll get it patched up first thing next week.

This has actually sparked some interesting internal discussions around potentially making the entire site https - what are your thoughts on that?

Ahm, I don't understand why you are actually asking this. From the previous posts on this thread, and my previous post. I think you should already have gathered that making everything connect via https is probably the best way to go. Also one of the easiest.

I wonder if this is your main reason for lack of innovation. You always look at what other companies are doing, but then you look if there are still some companies that do the same as you and then you decide upon that. Like how you tried to cover your lack of "security", by stating things like other sites aren't secure, so we don't have to be secure. Even though this solution isn't perfect, it is at least much more secure than it is currently.

I really hope you store your db info encrypted with a hash and salt. And hopefully not just md5.

edit: I just had a look at your Customer Logs page when you log into the WA client area. And I noticed something interesting. You state all the logins with the username, and then you give a part of the login password ending characters. This means, it is highly likely that you don't one-way encrypt (hash) your passwords, and that all the passwords can be decrypted by using the same key.

 

[Necuno]

Noted. Thx for the help guys, leave it with us and we'll get it patched up first thing next week.
This has actually sparked some interesting internal discussions around potentially making the entire site https - what are your thoughts on that?

Ahm, I don't understand why you are actually asking this. From the previous posts on this thread, and my previous post. I think you should already have gathered that making everything connect via https is probably the best way to go. Also one of the easiest.

I agree with Centaur, HTTPS is a start but there is a few things you need to do additionally. Waroop were you asking my opinion on it or how to do it?

 

[zamrg]

Noted. Thx for the help guys, leave it with us and we'll get it patched up first thing next week.

This has actually sparked some interesting internal discussions around potentially making the entire site https - what are your thoughts on that?

IMO, SSL across the entire WA site is overkill - performance vs security.

Why not stick the login form inside an embedded iframe with the target page hosted on SSL?

 

[Necuno]

Are we backtracking?

 

[ranger]

I know that internally they don't store passwords as hashes (anyone in the call center can view any account password in plaintext), but it was quite funny to notice that their mailserver had been specifically modified to only check the first 6 characters of a password (if you put more, they are discarded silently - almost certainly they are not using hashes here either) - some sections of their pages also choke on punctuation. Pretty sure the mailserver still only checks the first 6

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.

Unfortunately, upgrading hashes is difficult, especially if the clear-text isn't stored anywhere (as in our case). So, while we don't use crypt anywhere, and don't store clear-text anywhere, we will be working on hash upgrades at some point in the future (after some other projects are completed).

 

[ranger]

BTW., here is an article I thought might be interesting, regarding the weak account practices of respected companies, that, even though they may have SSL etc. in place, still allow accounts to be compromised with devastating effects.

This is why my primary backup is in my house, under my, and only my, control, and secondary backups are optical media with family.

Cloud is for people who don't care about the security of their data ...