Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.misc > #2983 > unrolled thread

Ebay hacked

Back to article view | Back to comp.misc

Contents

  Ebay hacked Sylvia Else <sylvia@not.at.this.address> - 2014-05-22 17:38 +1000
    Re: Ebay hacked RS Wood <rsw@therandymon.com> - 2014-05-22 13:35 +0000
      Re: Ebay hacked Andy Burns <usenet.feb2014@adslpipe.co.uk> - 2014-05-24 14:32 +0100
    Re: Ebay hacked Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-05-22 15:59 +0000
      Re: Ebay hacked Anssi Saari <as@sci.fi> - 2014-05-23 17:06 +0300
        Re: Ebay hacked Rich <rich@example.com> - 2014-05-24 16:13 +0000
          Re: Ebay hacked Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-05-24 20:45 +0100
            Re: Ebay hacked Sylvia Else <sylvia@not.at.this.address> - 2014-05-25 19:33 +1000
              Re: Ebay hacked Jerry Peters <jerry@example.invalid> - 2014-05-25 20:19 +0000
                Re: Ebay hacked Rich <rich@example.invalid> - 2014-05-25 21:50 +0000
        Re: Ebay hacked Rich <rich@example.com> - 2014-05-24 16:53 +0000
          Re: Ebay hacked Anssi Saari <as@sci.fi> - 2014-05-24 21:12 +0300
            Re: Ebay hacked Rich <rich@example.com> - 2014-05-24 18:33 +0000
              Re: Ebay hacked Sylvia Else <sylvia@not.at.this.address> - 2014-05-25 19:37 +1000
                Re: Ebay hacked Rich <rich@example.invalid> - 2014-05-25 13:46 +0000
                  Re: Ebay hacked Sylvia Else <sylvia@not.at.this.address> - 2014-05-26 16:55 +1000
                    Re: Ebay hacked Paul Sture <nospam@sture.ch> - 2014-05-26 18:42 +0200
            Re: Ebay hacked Paul Sture <nospam@sture.ch> - 2014-05-27 13:38 +0200
          Re: Ebay hacked Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-05-24 22:32 +0000
          Re: Ebay hacked Sylvia Else <sylvia@not.at.this.address> - 2014-05-25 19:36 +1000
            Re: Ebay hacked Rich <rich@example.invalid> - 2014-05-25 14:00 +0000
              Re: Ebay hacked Paul Sture <nospam@sture.ch> - 2014-05-25 17:18 +0200
            Re: Ebay hacked Paul Sture <nospam@sture.ch> - 2014-05-25 22:53 +0200
              Re: Ebay hacked Sylvia Else <sylvia@not.at.this.address> - 2014-05-26 17:03 +1000
                Re: Ebay hacked Rich <rich@example.invalid> - 2014-05-26 13:17 +0000
                  Re: Ebay hacked Sylvia Else <sylvia@not.at.this.address> - 2014-05-27 15:18 +1000
            Re: Ebay hacked Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-05-26 06:57 +0000
              Re: Ebay hacked Sylvia Else <sylvia@not.at.this.address> - 2014-05-26 17:07 +1000
                Re: Ebay hacked Rich <rich@example.invalid> - 2014-05-26 13:21 +0000
                Re: Ebay hacked Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-05-27 05:53 +0000
              Re: Ebay hacked Rich <rich@example.invalid> - 2014-05-26 13:19 +0000
              Re: Ebay hacked Paul Sture <nospam@sture.ch> - 2014-05-26 18:46 +0200
        Re: Ebay hacked "BartC" <bc@freeuk.com> - 2014-05-24 20:54 +0100
          Re: Ebay hacked Rich <rich@example.com> - 2014-05-24 20:24 +0000
          Re: Ebay hacked Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-05-24 22:35 +0000
    Re: Ebay hacked "James Harris" <james.harris.1@gmail.com> - 2014-05-23 00:28 +0100
      Re: Ebay hacked simple@machines.gopher - 2014-05-23 14:30 +0000
        Re: Ebay hacked Sylvia Else <sylvia@not.at.this.address> - 2014-05-24 00:36 +1000
          Re: Ebay hacked Paul Sture <nospam@sture.ch> - 2014-05-24 13:34 +0200
      Re: Ebay hacked mm0fmf <none@mailinator.com> - 2014-05-23 18:21 +0100
        Re: Ebay hacked Tim Streater <timstreater@greenbee.net> - 2014-05-23 18:39 +0100
          Re: Ebay hacked Sylvia Else <sylvia@not.at.this.address> - 2014-05-24 16:29 +1000
        Re: Ebay hacked RS Wood <rsw@therandymon.com> - 2014-05-23 21:57 +0000
        Re: Ebay hacked Sylvia Else <sylvia@not.at.this.address> - 2014-05-24 16:28 +1000
      Re: Ebay hacked "James Harris" <james.harris.1@gmail.com> - 2014-05-26 15:27 +0100
        Re: Ebay hacked Rich <rich@example.invalid> - 2014-05-26 14:32 +0000

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#3148

Sylvia Else <sylvia@not.at.this.address> wrote:
> On 25/05/2014 2:53 AM, Rich wrote:

> >
> >    "Spaces and certain symbols (< >[ ]//) are not allowed in password."
> >
> > A properly designed password storage (using a hashing function such as
> > bcrypt or scrypt) does not care what symbols are in the password.
> >
> > Caring about specific symbols in the password implies they are not
> > following proper password storage models.
> >

> I wonder where the restriction is enforced - both on the client and at 
> the server, or just in the client? How many here would be surprised if 
> it were the latter?

Before I looked, I was going to predict it was enforced client side.

But, what they have in the javascript of the change page is a client
side test for at least one of each of the different character classes
they want someone to use, and adjustment of their silly "strength"
meter.  But the actual "these characters are not allowed" appears to be
happening server side.

Their password strength meter is also silly.  As long as you have one
upper case, one lower case, one numeral, and one symbol (from their
list of "allowed" symbols), and are over five characters, they show the
password as strong.

So their strength meeter shows this as "strong"

aaa!1A

Note, not a real password....

[toc] | [prev] | [next] | [standalone]

#3177

On 2014-05-25, Rich <rich@example.invalid> wrote:
> Sylvia Else <sylvia@not.at.this.address> wrote:
>> On 25/05/2014 2:53 AM, Rich wrote:
>
>> >
>> >    "Spaces and certain symbols (< >[ ]//) are not allowed in password."
>> >
>> > A properly designed password storage (using a hashing function such as
>> > bcrypt or scrypt) does not care what symbols are in the password.
>> >
>> > Caring about specific symbols in the password implies they are not
>> > following proper password storage models.
>> >
>
>> I wonder where the restriction is enforced - both on the client and at 
>> the server, or just in the client? How many here would be surprised if 
>> it were the latter?
>
> Before I looked, I was going to predict it was enforced client side.
>
> But, what they have in the javascript of the change page is a client
> side test for at least one of each of the different character classes
> they want someone to use, and adjustment of their silly "strength"
> meter.  But the actual "these characters are not allowed" appears to be
> happening server side.

Oh yuk.

> Their password strength meter is also silly.  As long as you have one
> upper case, one lower case, one numeral, and one symbol (from their
> list of "allowed" symbols), and are over five characters, they show the
> password as strong.
>
> So their strength meeter shows this as "strong"
>
> aaa!1A

There's a precedent for this in Windows Active Directory (aka AD).  The out
of the box default is IIRC 3 out of 4 constraints: lowercase, uppercase,
punctuation and digits, and subject to a minimum length of 8 (I may have
misremembered the details, but that's the essence of it).

Passw0rd! gets you there.

> Note, not a real password....

But "good enough" to lure a non-technical user into thinking they have
created a strong password due to that silly meter.


-- 
Paul Sture

The final step of #heartbleed recovery is to call your mother, and advise
her to change her maiden name                                  -- @gojomo

[toc] | [prev] | [next] | [standalone]

#3187

On 2014-05-25, Sylvia Else <sylvia@not.at.this.address> wrote:
> On 25/05/2014 2:53 AM, Rich wrote:
>
>>
>>    "Spaces and certain symbols (< >[ ]//) are not allowed in password."
>>
>> A properly designed password storage (using a hashing function such as
>> bcrypt or scrypt) does not care what symbols are in the password.
>>
>> Caring about specific symbols in the password implies they are not
>> following proper password storage models.
>>
>
> I wonder where the restriction is enforced - both on the client and at 
> the server, or just in the client? How many here would be surprised if 
> it were the latter?

It would not surprise me to find that there was a server side restriction
at some time in the past, and they implemented client side validation for
that.

Roll on a few years to the point where that server side restriction no
longer exists, but because folks have lost track of all the services
involved nobody can say for sure that nothing still has it.

Thus the validation code lives on, and nobody has the guts to rip it out.

-- 
Paul Sture

The final step of #heartbleed recovery is to call your mother, and advise
her to change her maiden name                                  -- @gojomo

[toc] | [prev] | [next] | [standalone]

#3196

On 26/05/2014 6:53 AM, Paul Sture wrote:
> On 2014-05-25, Sylvia Else <sylvia@not.at.this.address> wrote:
>> On 25/05/2014 2:53 AM, Rich wrote:
>>
>>>
>>>     "Spaces and certain symbols (< >[ ]//) are not allowed in password."
>>>
>>> A properly designed password storage (using a hashing function such as
>>> bcrypt or scrypt) does not care what symbols are in the password.
>>>
>>> Caring about specific symbols in the password implies they are not
>>> following proper password storage models.
>>>
>>
>> I wonder where the restriction is enforced - both on the client and at
>> the server, or just in the client? How many here would be surprised if
>> it were the latter?
>
> It would not surprise me to find that there was a server side restriction
> at some time in the past, and they implemented client side validation for
> that.
>
> Roll on a few years to the point where that server side restriction no
> longer exists, but because folks have lost track of all the services
> involved nobody can say for sure that nothing still has it.
>
> Thus the validation code lives on, and nobody has the guts to rip it out.
>

The concern is that the restriction exists to prevent some kind of 
injection vulnerability. If the restriction either never exists on the 
server, or is removed therefrom, then the vulnerability is exposed.

Some while ago, I had to go to some considerable lengths to convince a 
senior system architect that a server could not trust client-side Java 
code. He was sure that doing so was how the banks had been implementing 
the Internet banking services.

I dare say there are plenty of people who think that since you've just 
downloaded the code (Java, Javascript, or whatever) to the client, that 
the code can be trusted to do what you intend.

It's hard to see how we'll ever get security when such fundamental 
misunderstandings persist.

Sylvia.

[toc] | [prev] | [next] | [standalone]

#3213

Sylvia Else <sylvia@not.at.this.address> wrote:
> On 26/05/2014 6:53 AM, Paul Sture wrote:
> > On 2014-05-25, Sylvia Else <sylvia@not.at.this.address> wrote:
> >> On 25/05/2014 2:53 AM, Rich wrote:
> >>
> >>>
> >>>     "Spaces and certain symbols (< >[ ]//) are not allowed in password."
> >>>
> >>> A properly designed password storage (using a hashing function such as
> >>> bcrypt or scrypt) does not care what symbols are in the password.
> >>>
> >>> Caring about specific symbols in the password implies they are not
> >>> following proper password storage models.
> >>>
> >>
> >> I wonder where the restriction is enforced - both on the client and at
> >> the server, or just in the client? How many here would be surprised if
> >> it were the latter?
> >
> > It would not surprise me to find that there was a server side restriction
> > at some time in the past, and they implemented client side validation for
> > that.
> >
> > Roll on a few years to the point where that server side restriction no
> > longer exists, but because folks have lost track of all the services
> > involved nobody can say for sure that nothing still has it.
> >
> > Thus the validation code lives on, and nobody has the guts to rip it out.
> >

> The concern is that the restriction exists to prevent some kind of 
> injection vulnerability. If the restriction either never exists on the 
> server, or is removed therefrom, then the vulnerability is exposed.

This is possible, or at least this might be why the fools think they
need the restriction.  But given their set of characters I'm not seeing
anything consistently that indicates attempting to block an injection
attack.

Square brackets [] are meta-chars for at least Unix shell's and regular
expressions, but they omitted at least $ (shell variable substitution)
and . (regular expression "any char").  Implying that Unix shell's or
regular expressions are not what they are filtering against.

Angle brackets <> are redirect characters in Unix shells, but again
without $ they left out a meta-character.

None of the set of six are meta-characters for SQL (there single quote
' is the big one).  So this does not look to be driven by SQL injection
prevention.

Forward slashes / are directory separators in Unix, but if they are
literally storing passwords as names in a directory tree, then they
really are incompetent.

The list seems rather arbitrary (although I suppose to the incompetent
who first picked the set, there was a very good reason known only to
him/her).

> Some while ago, I had to go to some considerable lengths to convince
> a senior system architect that a server could not trust client-side
> Java code. He was sure that doing so was how the banks had been
> implementing the Internet banking services.

Ouch.  And this was a "senior" system architect?  Wow, that is both
frightening and sad both at the same time.

> I dare say there are plenty of people who think that since you've
> just downloaded the code (Java, Javascript, or whatever) to the
> client, that the code can be trusted to do what you intend.

Ah, yes, the old DRM ruse.  Too many still fall for this one.

> It's hard to see how we'll ever get security when such fundamental 
> misunderstandings persist.

Very true.  If that "senior"'s opinion is more widespread than just
that one individual (I suspect the answer here is yet) then it is no
wonder none of these companies can get security right.

[toc] | [prev] | [next] | [standalone]

#3275

On 26/05/2014 11:17 PM, Rich wrote:

> Ouch.  And this was a "senior" system architect?

Yes, and I was later privy to formal documentation that showed that he 
was being paid a good deal more than I was.

He talked the talk, and walked the walk. Apparently actually knowing 
what you're doing is not so important when it comes to salary.

Sylvia.

[toc] | [prev] | [next] | [standalone]

#3194

In message <budrskFf0vtU2@mid.individual.net> 
  Sylvia Else <sylvia@not.at.this.address> wrote:
> On 25/05/2014 2:53 AM, Rich wrote:

>>
>>    "Spaces and certain symbols (< >[ ]//) are not allowed in password."
>>
>> A properly designed password storage (using a hashing function such as
>> bcrypt or scrypt) does not care what symbols are in the password.
>>
>> Caring about specific symbols in the password implies they are not
>> following proper password storage models.
>>

> I wonder where the restriction is enforced - both on the client and at 
> the server, or just in the client? How many here would be surprised if 
> it were the latter?

Are you suggesting that web browsers don't allow certain characters in
text input fields? I've never encountered that in any browser.

-- 
"Queen Isabella and King Ferdinand kicked 200,000 Jews out of Spain, one
of the first acts of the Spanish Inquisition, which no one ever expects
" -- John Carroll's 21st Annual Xmas Quiz answers

[toc] | [prev] | [next] | [standalone]

#3197

On 26/05/2014 4:57 PM, Lewis wrote:
> In message <budrskFf0vtU2@mid.individual.net>
>    Sylvia Else <sylvia@not.at.this.address> wrote:
>> On 25/05/2014 2:53 AM, Rich wrote:
>
>>>
>>>     "Spaces and certain symbols (< >[ ]//) are not allowed in password."
>>>
>>> A properly designed password storage (using a hashing function such as
>>> bcrypt or scrypt) does not care what symbols are in the password.
>>>
>>> Caring about specific symbols in the password implies they are not
>>> following proper password storage models.
>>>
>
>> I wonder where the restriction is enforced - both on the client and at
>> the server, or just in the client? How many here would be surprised if
>> it were the latter?
>
> Are you suggesting that web browsers don't allow certain characters in
> text input fields? I've never encountered that in any browser.
>

No. But Javascript can be used to impose such a restriction, though it 
obviously doesn't prevent the user from modifying the script so as to 
send a supposedly prohibited character to the server.

I'd like to think that no developer would be so naive as to rely on 
client side validation, but if I did think so, the evidence would show 
me to be wrong.

Sylvia

[toc] | [prev] | [next] | [standalone]

#3215

Sylvia Else <sylvia@not.at.this.address> wrote:
> On 26/05/2014 4:57 PM, Lewis wrote:
> > In message <budrskFf0vtU2@mid.individual.net>
> >    Sylvia Else <sylvia@not.at.this.address> wrote:
> >> On 25/05/2014 2:53 AM, Rich wrote:
> >
> >>>
> >>>     "Spaces and certain symbols (< >[ ]//) are not allowed in password."
> >>>
> >>> A properly designed password storage (using a hashing function such as
> >>> bcrypt or scrypt) does not care what symbols are in the password.
> >>>
> >>> Caring about specific symbols in the password implies they are not
> >>> following proper password storage models.
> >>>
> >
> >> I wonder where the restriction is enforced - both on the client and at
> >> the server, or just in the client? How many here would be surprised if
> >> it were the latter?
> >
> > Are you suggesting that web browsers don't allow certain characters in
> > text input fields? I've never encountered that in any browser.
> >

> No. But Javascript can be used to impose such a restriction, though it 
> obviously doesn't prevent the user from modifying the script so as to 
> send a supposedly prohibited character to the server.

> I'd like to think that no developer would be so naive as to rely on 
> client side validation, but if I did think so, the evidence would show 
> me to be wrong.

Sadly, some have been so naive:

http://cwe.mitre.org/data/definitions/602.html

Note part way down under "observed examples".

[toc] | [prev] | [next] | [standalone]

#3276

In message <bug7grFua32U1@mid.individual.net> 
  Sylvia Else <sylvia@not.at.this.address> wrote:
> On 26/05/2014 4:57 PM, Lewis wrote:
>> In message <budrskFf0vtU2@mid.individual.net>
>>    Sylvia Else <sylvia@not.at.this.address> wrote:
>>> On 25/05/2014 2:53 AM, Rich wrote:
>>
>>>>
>>>>     "Spaces and certain symbols (< >[ ]//) are not allowed in password."
>>>>
>>>> A properly designed password storage (using a hashing function such as
>>>> bcrypt or scrypt) does not care what symbols are in the password.
>>>>
>>>> Caring about specific symbols in the password implies they are not
>>>> following proper password storage models.
>>>>
>>
>>> I wonder where the restriction is enforced - both on the client and at
>>> the server, or just in the client? How many here would be surprised if
>>> it were the latter?
>>
>> Are you suggesting that web browsers don't allow certain characters in
>> text input fields? I've never encountered that in any browser.
>>

> No. But Javascript can be used to impose such a restriction, though it 
> obviously doesn't prevent the user from modifying the script so as to 
> send a supposedly prohibited character to the server.

Ah, I see.

> I'd like to think that no developer would be so naive as to rely on 
> client side validation, but if I did think so, the evidence would show 
> me to be wrong.

Yah, I'm pretty sure you're wrong.

Maybe next time I run into one of those stupid forms I'll see about
injecting little Bobby Tables.

<https://xkcd.com/327/>

-- 
The Force can have a strong influence on a weak mind.

[toc] | [prev] | [next] | [standalone]

#3214

Lewis <g.kreme@gmail.com.dontsendmecopies> wrote:
> In message <budrskFf0vtU2@mid.individual.net> 
>   Sylvia Else <sylvia@not.at.this.address> wrote:
> > On 25/05/2014 2:53 AM, Rich wrote:

> >>
> >>    "Spaces and certain symbols (< >[ ]//) are not allowed in password."
> >>
> >> A properly designed password storage (using a hashing function such as
> >> bcrypt or scrypt) does not care what symbols are in the password.
> >>
> >> Caring about specific symbols in the password implies they are not
> >> following proper password storage models.
> >>

> > I wonder where the restriction is enforced - both on the client and at 
> > the server, or just in the client? How many here would be surprised if 
> > it were the latter?

> Are you suggesting that web browsers don't allow certain characters in
> text input fields? I've never encountered that in any browser.

Sylvia was suggesting that the ebay programmers had implimented the
allowed character check, and subsequent warning, only in clientside
javascript.

It turns out they do character checking in their client side
javascript, but it appears they do only enough to drive their silly
strength meter, not to actually say "you can't use these characters:
()".  The actual refusal of certian characters appears to be handled
server side.

[toc] | [prev] | [next] | [standalone]

#3236

On 2014-05-26, Lewis <g.kreme@gmail.com.dontsendmecopies> wrote:
> In message <budrskFf0vtU2@mid.individual.net> 
>   Sylvia Else <sylvia@not.at.this.address> wrote:
>> On 25/05/2014 2:53 AM, Rich wrote:
>
>>>
>>>    "Spaces and certain symbols (< >[ ]//) are not allowed in password."
>>>
>>> A properly designed password storage (using a hashing function such as
>>> bcrypt or scrypt) does not care what symbols are in the password.
>>>
>>> Caring about specific symbols in the password implies they are not
>>> following proper password storage models.
>>>
>
>> I wonder where the restriction is enforced - both on the client and at 
>> the server, or just in the client? How many here would be surprised if 
>> it were the latter?
>
> Are you suggesting that web browsers don't allow certain characters in
> text input fields? I've never encountered that in any browser.

cough tab cough

There was a DuckDuckGo plugin which assigned Alt-G to some other function,
and on Swiss keyboard that's how you get @ in OS X.  Until I realised which
plugin it was I had to copy and paste email addresses into web forms.

-- 
Paul Sture

The final step of #heartbleed recovery is to call your mother, and advise
her to change her maiden name                                  -- @gojomo

[toc] | [prev] | [next] | [standalone]

#3102

"Anssi Saari" <as@sci.fi> wrote in message
news:vg3oayn5gh3.fsf@coffee.modeemi.fi...
> Lewis <g.kreme@gmail.com.dontsendmecopies> writes:
>
>> Hard to say, but Fleabay has *always* been incompetent.
>
> Now ebay apparently botched the password reset page too by not allowing
> pasting from the clipboard. Ars writes about it at
> http://arstechnica.com/security/2014/05/after-the-breach-ebays-flawed-password-reset-leaves-much-to-be-desired/

It seems to have problems anyway. A new password has stricter rules than
before, so has to meet two of three or four new conditions. I met two of
those (upper and lower case), but it kept rejecting it.

So I added an upper case letter and a digit. Now it says, the page has timed
out, and I need to apply for a password change again! So I click the button
to get it to send me an email (from which a link gets you to the
password-change page).

I get that email, but also another just before confirming my password was
successfully changed! The problem was, which one of those attempts it
rejected was actually successful? Otherwise I could now be locked out. (I
did manage to find which one it was.)

But it's not just ebay's password page making things impossible; everyone's
at it. The BBC, for example, where if you forget a password, also sends you
an email link to a password-change page, but which immediately says has
timed out (and it has many other issues too).

While Hostelworld only accepts a password that has at least one lower-case
letter, an upper-case letter, a digit, and a symbol! It was impossible to
create one I could remember, so I left it.

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#3110

BartC <bc@freeuk.com> wrote:


> "Anssi Saari" <as@sci.fi> wrote in message
> news:vg3oayn5gh3.fsf@coffee.modeemi.fi...
> > Lewis <g.kreme@gmail.com.dontsendmecopies> writes:
> >
> >> Hard to say, but Fleabay has *always* been incompetent.
> >
> > Now ebay apparently botched the password reset page too by not allowing
> > pasting from the clipboard. Ars writes about it at
> > http://arstechnica.com/security/2014/05/after-the-breach-ebays-flawed-password-reset-leaves-much-to-be-desired/

> ...

> It was impossible to create one I could remember, so I left it.

This: https://github.com/zdia/gorilla/wiki, can solve the need to
remember problem.

[toc] | [prev] | [next] | [standalone]

#3116

In message <UN6gv.90834$jf3.39025@fx31.am4> 
  BartC <bc@freeuk.com> wrote:
> But it's not just ebay's password page making things impossible; everyone's
> at it. The BBC, for example, where if you forget a password, also sends you
> an email link to a password-change page, but which immediately says has
> timed out (and it has many other issues too).

Are you sure your system clock is correct?

I've never had a timeout issue with the BBC site.

> While Hostelworld only accepts a password that has at least one lower-case
> letter, an upper-case letter, a digit, and a symbol! It was impossible to
> create one I could remember, so I left it.

Don't remember passwords, get a password manager like LastPass (free) or
1Password (not free, but I find it worth the cost).


-- 
If you must choose between two evils, pick the one you've never tried
before.

[toc] | [prev] | [next] | [standalone]

#3007

"Sylvia Else" <sylvia@not.at.this.address> wrote in message 
news:bu5nskFnom7U1@mid.individual.net...
> http://www.smh.com.au/it-pro/security-it/ebay-hit-by-cyber-attack-urges-users-to-change-passwords-20140521-zrkiu.html

This appears to be worse than I thought. From the Telegraph: "It admitted 
that the name, address, date of birth, telephone number, email address and 
password of every eBay account holder - 233 million people worldwide - was 
in the hands of the hackers."

http://www.telegraph.co.uk/technology/news/10848080/More-than-15-million-Britons-at-risk-of-identity-theft-after-eBay-hacked.html

There are also claims that Ebay has told its customers that they have to 
change their passwords. I haven't received any email from them. Nor is there 
a message against my Ebay account.

Various points about this - at least as it is reported - are dreadful:

* one employee's account had access to copy all this info
* passwords were stored in a reversible form
* c. 2 months between the issue and letting customers know
* even now, no communication from Ebay
* no info on advice from law enforcement
* info on web site not clear as to what may have been compromised. Ebay 
accounts have various addresses associated with them. Which were hacked?

As the article says, "The danger goes beyond the internet, because some 
telephone banking services accept a date of birth and address to verify the 
identity of a customer."

James

[toc] | [prev] | [next] | [standalone]

#3023

>"Sylvia Else" <sylvia@not.at.this.address> wrote in message
> ...
>This appears to be worse than I thought. From the Telegraph: "It admitted
>that the name, address, date of birth, telephone number, email address and
>password of every eBay account holder - 233 million people worldwide - was
>in the hands of the hackers."

Good reason to just make up identities when you sign up for these services.
Also a good idea to freeze your credit until you decide to apply for a loan.

Regarding ebay specifically, given the nature of their service they really
ought to move to bank-grade authentication, at least add 2-factor authentication
as an option.

[toc] | [prev] | [next] | [standalone]

#3025

On 24/05/2014 12:30 AM, simple@machines.gopher wrote:
>> "Sylvia Else" <sylvia@not.at.this.address> wrote in message
>> ...
>> This appears to be worse than I thought. From the Telegraph: "It admitted
>> that the name, address, date of birth, telephone number, email address and
>> password of every eBay account holder - 233 million people worldwide - was
>> in the hands of the hackers."
>
> Good reason to just make up identities when you sign up for these services.
> Also a good idea to freeze your credit until you decide to apply for a loan.
>
> Regarding ebay specifically, given the nature of their service they really
> ought to move to bank-grade authentication, at least add 2-factor authentication
> as an option.
>

What they need to do is what they should have done in the first place, 
which is to employ someone with a clue for the important stuff. Of 
course, that would require managers with a clue as well, which can be a 
problem.

Sylvia.

[toc] | [prev] | [next] | [standalone]

#3074

On 2014-05-23, Sylvia Else <sylvia@not.at.this.address> wrote:
> On 24/05/2014 12:30 AM, simple@machines.gopher wrote:
>>> "Sylvia Else" <sylvia@not.at.this.address> wrote in message
>>> ...
>>> This appears to be worse than I thought. From the Telegraph: "It admitted
>>> that the name, address, date of birth, telephone number, email address and
>>> password of every eBay account holder - 233 million people worldwide - was
>>> in the hands of the hackers."
>>
>> Good reason to just make up identities when you sign up for these services.
>> Also a good idea to freeze your credit until you decide to apply for a loan.
>>
>> Regarding ebay specifically, given the nature of their service they really
>> ought to move to bank-grade authentication, at least add 2-factor
>> authentication as an option.
>>
>
> What they need to do is what they should have done in the first place, 
> which is to employ someone with a clue for the important stuff. Of 
> course, that would require managers with a clue as well, which can be a 
> problem.

A few months ago BBC Radio business programme put forward the idea that
the ideal manager isn't too bright because someone more intelligent would
soon get bored with dealing with timesheets and Excel graphs that mean  so
little.

I am pretty sure this was one of Peter Day's World of Business series,
though unfortunately I cannot remember which episode.

<http://downloads.bbc.co.uk/podcasts/radio/worldbiz/rss.xml>


-- 
Paul Sture

The final step of #heartbleed recovery is to call your mother, and advise
her to change her maiden name                                  -- @gojomo

[toc] | [prev] | [next] | [standalone]

#3032

On 23/05/2014 00:28, James Harris wrote:
>
> This appears to be worse than I thought. From the Telegraph: "It admitted
> that the name, address, date of birth, telephone number, email address and
> password of every eBay account holder

You mean to say you don't have
1) a specific ebay only email address
2) an ebay only phone number (and old mobile phone with a prepay SIM)
3) a false birthdate but one you can remember (25th December 1970?)

The only thing they have found out about me is my name & address which 
is already publicly available. The other info is not correct if they try 
to use it to confirm my identity to other companies/banks etc.

>
> There are also claims that Ebay has told its customers that they have to
> change their passwords. I haven't received any email from them. Nor is there
> a message against my Ebay account.

There's a damn great area of the page when I log in telling me to change 
my password.

>
> Various points about this - at least as it is reported - are dreadful:
>
> * one employee's account had access to copy all this info

These people are called system administrators, they normally have access 
to everything because they are the people who grant access to lesser beings.

> As the article says, "The danger goes beyond the internet, because some
> telephone banking services accept a date of birth and address to verify the
> identity of a customer."
>

Well anyone who uses the same identity info for bank account access and 
*ANY OTHER WEBSITE* must be particularly fucking stupid.

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.misc

csiph-web