2degrees change password page sends password in embedded JS in the clear!

Forums › 2degrees (including Slingshot, Orcon, Flip, Stuff Fibre, MyRepublic, 2talk and Vocus) › 2degrees change password page sends password in embedded JS in the clear!

1 | 2

jbard

1377 posts

Uber Geek

#623629 11-May-2012 17:58

jree: Hi,

I'm one of the security guys at 2deg. We've been looking at this since Phillip got in touch.

The issue is on the fix list. couple of weeks hopefully

Generally the issue occurs on forgotten password, account reset from CS, or first time login.
In most cases the user should receive a OTP (24hr expiry) via sms.
Once logged in the new password is hashed etc in the backend.

Some of the other things mentioned were:
External audit.... We do engaged a third party #notanaccountingfirm to review the security of these servers and other elements across the 2deg infrastructure regularly.

PCI... I'll leave it to a QSA to decide what is in/out of scope however no customer CC data traverses or passes through these web servers. I'm not a web guru but the standard iframe setup is used with a backend validation system based off token.

We use equipment made be large asian vendors... I can neither confirm nor deny that both Nth american and asian vendors are involved in 2deg, nor can I confirm nor deny the level of trust we afford either :-)

Thanks
J

If you are hashing it on the backend how can you get it back to clear text in the js?
Unless you are using an algorithm that can be decrypted but that basically makes your hashing useless?

jree

13 posts

Geek

#623631 11-May-2012 18:04

jbard:

If you are hashing it on the backend how can you get it back to clear text in the js?
Unless you are using an algorithm that can be decrypted but that basically makes your hashing useless?

Hi,

The pwd should be an OTP sent and created by us.

Chrs J

jbard

1377 posts

Uber Geek

#623637 11-May-2012 18:10

jree:
jbard:

If you are hashing it on the backend how can you get it back to clear text in the js?
Unless you are using an algorithm that can be decrypted but that basically makes your hashing useless?

Hi,

The pwd should be an OTP sent and created by us.

Chrs J

So you are saying the OTP password is left in the clear but the users password is hashed+salted?

jree

13 posts

Geek

#623644 11-May-2012 18:22

jbard:

So you are saying the OTP password is left in the clear but the users password is hashed+salted?

Yes. The fact the OTP is in the clear is also bad even though it has a 24 hr expiry.
The clear OTP is the bit we are going to fix... but it will take a few weeks to get to production.

Chrs J

jbard

1377 posts

Uber Geek

#623646 11-May-2012 18:26

jree:
jbard:

So you are saying the OTP password is left in the clear but the users password is hashed+salted?

Yes. The fact the OTP is in the clear is also bad even though it has a 24 hr expiry.
The clear OTP is the bit we are going to fix... but it will take a few weeks to get to production.

Chrs J

Yeah it isn't as big a deal as the normal pwd being in plain text. Good on 2 degrees for getting it fixed.

SmileyChris

4 posts

Wannabe Geek

#623873 12-May-2012 07:10

jree:
jbard:

So you are saying the OTP password is left in the clear but the users password is hashed+salted?

Yes. The fact the OTP is in the clear is also bad even though it has a 24 hr expiry.
The clear OTP is the bit we are going to fix... but it will take a few weeks to get to production.

Chrs J

Thanks for the updates!

Speaking of hashing, in Django we recently increased the hashing algorithm to something more secure. Maybe something to look at as part of your process?

From the docs:

Django 1.3 uses the SHA1 algorithm, but increasing processor speeds and theoretical attacks have revealed that SHA1 isn't as secure as we’d like. Thus, Django 1.4 introduces a new password storage system: by default Django now uses the PBKDF2 algorithm (as recommended by NIST).

jnawk

176 posts

Master Geek

#630256 25-May-2012 11:24

jbard:
SmileyChris: The much bigger problem than the password being rendered in the js / page, is that they had the password to begin with.

Any reasonable developer should know that you salt and hash (with a strong?algorithm) your passwords.

I think that was what the OP was pointing out, not sure he explained it as simply as you though.

I've been out of touch for a while.. Sorry if this has been addressed.

They might have had the password simply in the session due to the fact I just (successfully) logged in. That would be bad too, (swap, etc), but itself, doesn't prove they don't salt & hash.

1 | 2