[plug] Iinet security

[ıuoʎ]

Bernd what your saying is disturbing.
First, it completely contradicts what IINET rep wrote here
about needing to enter the full password for verification and not having
access to plain text at all. so what you did with the rep on the phone is
not suppose to be possible.
Second, users shouldn't give their passwords to anyone not even part of it.
There were enough scams by people calling customers claiming they are
company rep and asking the passwords of users. we don't need legitimate
customer reps doing the same.
We can achieve much more better solution with single use tokens like Google
Auth if you really want to take it to the next level.
But never do it with users passwords since you open yourself to a new
vector of attack.

I'm buying the rest of IINET claims which are very noob level and I'm not
their customer so I don't really care, but it seems like their doing
something horribly wrong.

* And just for a jibs I don't  keep my passwords under a silo under
mountain in fact here is one of my password stored hash that I already
published to an online forum 3 months ago -

$2y$10$Fs9R3YBV3w4ShisoXIWVUOZG.tZ9iW59bK6NFUylZOg0A.NegF66e

If this is not secure you are welcome to publish this password here in the
clear once you get it


On Wed, Jul 30, 2014 at 1:11 PM, Bernd Felsche <bf_plug at felsche.org> wrote:

> On Wed, 30 Jul 2014 03:51:12 Krystin Dix wrote:
>
> > Passwords stored in the clear?
> >
> > Passwords are stored in a secure manner .. however yes they are
> > retrievable. This is so that we can setup DSL services on clients
> > modems or other devices that require the same username without having
> > to change both the device (mail client) and the modem. Having to
>
> Many moons ago, I had reason to call iiNet support and I was asked
> for the account password. Being an experienced security nerd I
> resolved the need to assure a shared secret by only supplying the
> first 3 characters of the password, then requiring that they supply
> the next 3, before I provided the rest.
>
> If a random person calls, the incorrect challenge doesn't
> necessarily invoke an overt denial; the response can be "invented",
> deceiving the unverified caller into having guessed the correct
> challenge and receiving a correct response.
>
> The process provided either party with the facility to bail out of
> the authentication process if either response failed and to
> (asynchronously) set the password to a true secret.  The first three
> characters were a challenge; the next 3 acted as a response and a
> counter-challenge with the remainder as the final response. Knowing
> only part of the secret doesn't result in an immediate compromise.
>
> Such challenge-response systems can be mechanised (obviously) so
> that the support desk people have to type in the challenge to see
> their response/challenge and then type in remainder of the shared
> secret; IFF the initial challenge was correct. An incorrect
> challenge can invoke automatic countermeasures (including phoney
> information) and extra logging.
>
> An advantage of such a system is that help desk personnel cannot
> "browse" passwords.
>
> A further extension (just mentioning this so that the obvious
> doesn't get Patented) is that the passwords don't actually have to
> be stored in their entirety to facilitate authentication via that
> shared secret. Hashes for parts of the password can be substituted
> in the help-desk fronting systems as sufficient. Only the response
> to the initial challenge need be in clear as the initial challenge
> (from the caller) can be hashed, as can their final response when
> typed in at the help desk.
>
> While that help desk person may be able to remember/note that
> particular account/password information in parallel with a call, the
> caller can immediately change their password if they feel
> particularly vulnerable.
>
> Forgotten passwords can be managed by escalation to e.g. reset the
> password or to view it to e.g. set up a new modem; upon receipt of
> additional identification and verification.
>
> Electronic invoices can make authentication of callers more
> difficult as the recipient doesn't necessarily download the invoice
> or print them. They may just leave them sitting on iiNet's servers
> (or delete them), so reference to account names, invoice numbers,
> etc becomes very difficult, even if the account holder is calling
> from home and their connection is down.
>
>
> P.S. The only place that I've heard of where passwords are stored in
> a secured manner is under a mountain in the USA; where there's a
> safe with 3 combination locks in a room without any lights, wires or
> pipes (just a door), an armed guard in the ante-room; another armed
> guard from a different arm of the defence forces in the ante-room to
> that corridor; electronic surveillance around the clock from two
> different locations around the clock (NONE in the safe room);
> automatic armoured doors along the and many checkpoints with armed
> guards all the way to the perimeter fence a couple of kilometres
> from the entrance to the mountain.
>
> One of the PINs written in a binder sitting in that safe is/was
> "7777777" (seven 7's). We all know that secret now.
>
> --
> Bernd Felsche - Innovative Reckoning, Western Australia
> http://innovative.ii.net
>
> _______________________________________________
> PLUG discussion list: plug at plug.org.au
> http://lists.plug.org.au/mailman/listinfo/plug
> Committee e-mail: committee at plug.org.au
> PLUG Membership: http://www.plug.org.au/membership
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.plug.org.au/pipermail/plug/attachments/20140730/75103767/attachment.html>