[OT] Jerry's in a good mood today (Multiplicity of accounts.)
On Sun, Oct 6, 2013 at 10:01 AM, Jerry Stuckle <jstuckle@attglobal.net> wrote:
> On 10/5/2013 12:43 AM, Joel Rees wrote:
>>
>> On Sat, Oct 5, 2013 at 10:56 AM, Jerry Stuckle <jstuckle@attglobal.net>
>> wrote:
>>>
>>> On 10/4/2013 9:25 PM, Joel Rees wrote:
>>>>
>>>>
>>>> Not top posting, just prefacing my comments:
>>>>
>>>> Are we trying to educate the list in cracking techniques or in ways to
>>>> manage and mitigate the vulnerabilities?
>>>>
>>>> On Fri, Oct 4, 2013 at 10:36 PM, Jerry Stuckle <jstuckle@attglobal.net>
>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 10/4/2013 5:10 AM, Joel Rees wrote:
>>>>>>
>>>>>>
>>>>>> Should I add to the confusion?
>>>>>>
>>>>>> On Thu, Oct 3, 2013 at 10:27 PM, Jerry Stuckle
>>>>>> <jstuckle@attglobal.net>
>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 10/3/2013 8:45 AM, Joel Rees wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Oct 3, 2013 at 1:53 AM, Jerry Stuckle
>>>>>>>> <jstuckle@attglobal.net>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 10/2/2013 12:24 PM, peasthope@shaw.ca wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> From: Joel Rees <joel.rees@gmail.com>
>>>>>>>>>> Date: Wed, 2 Oct 2013 15:30:26 +0900
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> [...]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> And accessing your bank logged in as the same user that you use
>>>>>>>>>>> to
>>>>>>>>>>> surf random sites is one of the primary causes of leaked bank
>>>>>>>>>>> account
>>>>>>>>>>> numbers and passwords.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The banking information is stored in a cookie. Subsequently a
>>>>>>>>>> site
>>>>>>>>>> other
>>>>>>>>>> than the bank is allowed to read the cookie? A failure of the
>>>>>>>>>> browser.
>>>>>>>>>> Correct? Prior to studying this thoroughly, I might stick to
>>>>>>>>>> personal
>>>>>>>>>> banking.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Not if your browser is working properly. Cookies can only be sent
>>>>>>>>> to
>>>>>>>>> the
>>>>>>>>> domain which originated them (and, depending on the cookie options,
>>>>>>>>> subdomains of the main domain).
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> subdomains.
>>>>>>>>
>>>>>>>> And too many places, bank sites included, outsource parts of their
>>>>>>>> sites. Particularly ad-related stuff.
>>>>>>>>
>>>>>>>
>>>>>>> It doesn't matter if they outsource parts of their sites. Those
>>>>>>> outsourced
>>>>>>> sites will have different domains, and the cookies cannot be sent to
>>>>>>> them.
>>>>>>
>>>>>>
>>>>>>
>>>>>> You must be looking at the page source code of different banks than I
>>>>>> am.
>>>>>>
>>>>> What banks do you know outsource subdomains to someone else?
>>>>
>>>>
>>>>
>>>> Exposure here would only motivate the banks if they were reading this
>>>> mailing list.
>>>>
>>>> Exposure here would only warn their customers if their customers, or
>>>> even their customers' friends, were reading this mailing list.
>>>>
>>>> I don't think it would be responsible to name names here, do you?
>>>>
>>>> However, for users of this list, trying to manage the vulnerabilities
>>>> they expose themselves to, the odds that your bank is using known
>>>> vulnerable techniques are high enough that you need to take some
>>>> effort to limit your own exposure.
>>>>
>>>
>>> If there were ANY bank which had to read this list to find out they were
>>> exposed, they need a new IT department.
>>>
>>> I don't know about where you are - but here in the United States, they
>>> wouldn't get very far. There are many layers of regulations and
>>> protections
>>> regarding banking security. And any bank which had such security
>>> exposures
>>> as you claim would not be allowed to continue operations.
>>>
>>> And no, I am VERY confident ANY bank I have dealt with knows how to
>>> manage
>>> vulnerabilities. What makes you think otherwise?
>>
>>
>> Hmm. How does one answer such a riff?
>>
>> https://www.google.co.jp/#q=us+bank+vulnerability
>>
>
> Which has absolutely nothing to do with potential security vulnerabilities
> on their website. But you can't understand the difference.
>
>> and
>>
>> https://www.google.co.jp/#q=bank+information+technology+incompetent
>>
>
> Once again, absolutely nothing to do with any vulnerabilities. A bunch of
> people bitching about not getting their money as fast as they want, though.
>
>
>> The results of that second search would be quite amusing in some sort
>> of slapstick comedy, although some do include language that would not
>> be approved here. And I am sure the individuals blogging their
>> experiences were not amused.
>>
>
> Yes, it is quite amusing to see you making such a fool of yourself by
> quoting "supporting material" which has absolutely nothing to do with the
> subject (and in many cases is of questionable origin).
>
>
>> And then I had a "flash" of insight:
>>
>>>>> [...]
>>
>>
>>> HTML is a scripting language. Nothing more, nothing less. [...]
>>>>>
>>>>> [...]
>>
>>
>> I've had managers who couldn't tell the difference between a markup
>> language and a scripting language, but I'm sure you can.
>>
>
> But they're still a lot smarter than you are.
>
>
>> You're just playing with me. Thanks anyway, Jerry, but I really do
>> have homework to do today.
>>
>
> Let me help you.
>
> The order is - A-B-C-D-E-F-G-H-I-J-K-L-M-N-O-P-Q-R-S-T-U-V-W-X-Y-Z.
The funny thing is, if you weren't trolling, there are lots of people
who are so confused as to say the kinds of things you have been saying
in this thread. And it would be worth, perhaps, talking about whether
you can trust a bank to handle your login data and other private
information when they've forgotten how to handle their primary
business. (Looking back, for instance, to the Lehman brothers.)
And do you want to be the low-hanging fruit when Adobe has another
0day like they did last February.
And so forth. Fundamental stuff.
But you're just trolling.
--
Joel Rees
Be careful where you see conspiracy.
Look first in your own heart.
Reply to: