 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 24/12/2013 08:18 AM, scott wrote:
> Do you want GFLOPS or FPS?
As well as that, I'm going to try to get CUDA to work again. I've got a
few bits of software which *claim* to use your GPU to do compute-heavy
work much faster. If only any of them actually *worked*...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 24/12/2013 09:41 AM, scott wrote:
>> Ultimately, I'm probably going to wait for my next bank statement before
>> I decide. It's only a few days away, after all...
>
> Oooh, is that 1995 I hear calling again :-)
What, you think I should be using Internet banking? I prefer it if bad
people *can't* steal all my money merely by guessing a password...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Oooh, is that 1995 I hear calling again :-)
>
> What, you think I should be using Internet banking? I prefer it if bad
> people *can't* steal all my money merely by guessing a password...
Oh it's 2005 calling now...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid Win7 v1 <voi### [at] dev null> wrote:
> What, you think I should be using Internet banking? I prefer it if bad
> people *can't* steal all my money merely by guessing a password...
What bank uses fixed passwords (rather than a sheet of single-use codes)
and thinks that it's safe?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 23/12/13 20:41, Warp wrote:
> Orchid Win7 v1 <voi### [at] devnull> wrote:
>> yet, it produces 2,200 GFLOPS (and has twice the RAM).
>
> It's not the size that matters. It's how you use it.
>
:-)
John
--
Protect the Earth
It was not given to you by your parents
You hold it in trust for your children
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 24.12.2013 16:26, schrieb Warp:
> Orchid Win7 v1 <voi### [at] devnull> wrote:
>> What, you think I should be using Internet banking? I prefer it if bad
>> people *can't* steal all my money merely by guessing a password...
>
> What bank uses fixed passwords (rather than a sheet of single-use codes)
> and thinks that it's safe?
What bank uses a sheet of single-use codes and thinks that it's safe?
Over here in Germany we're past that age. Codes dynamically generated
from transaction details it is for us.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> What bank uses a sheet of single-use codes and thinks that it's safe?
Well, much safer than a fixed password.
You can't do anything with the sheet alone if you don't have the user's ID.
Granted, it's not impossible to acquire both, but if you don't store your
ID anywhere and instead have it memorized, it becomes difficult. (Basically
they would need to install some spyware in the computer you are using in
order to get the ID, and then physically steal the passcode sheet. Not
impossible, but not likely to happen.)
> Over here in Germany we're past that age. Codes dynamically generated
> from transaction details it is for us.
How does that even work?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 25.12.2013 13:39, schrieb Warp:
> clipka <ano### [at] anonymousorg> wrote:
>> What bank uses a sheet of single-use codes and thinks that it's safe?
>
> Well, much safer than a fixed password.
>
> You can't do anything with the sheet alone if you don't have the user's ID.
> Granted, it's not impossible to acquire both, but if you don't store your
> ID anywhere and instead have it memorized, it becomes difficult. (Basically
> they would need to install some spyware in the computer you are using in
> order to get the ID, and then physically steal the passcode sheet. Not
> impossible, but not likely to happen.)
Just two words:
(1) Phising.
(2) Man-in-the-middle attack.
>> Over here in Germany we're past that age. Codes dynamically generated
>> from transaction details it is for us.
>
> How does that even work?
There are two variants in use:
(A) Each time you submit a transaction via browser, you get a
transaction-specific authorization code via SMS to your mobile phone,
including some essentials of the transaction (like the amount of money
transferred, and the target bank account) to make sure that you and the
bank are talking about the same deal.
(B) You get a code generator from your bank. Typically this would be a
combination of a bank card with a built-in chip, plus a card reader with
a built-in display to make sure that the code is generated from the
transaction details you desire.
(As certified card readers are expensive, have never really taken off,
and would probably be difficult to integrate into web-based online
banking, the common solution is an inexpensive battery-powered
stand-alone device using optical transmission from web interface to card
reader.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> Am 25.12.2013 13:39, schrieb Warp:
> > clipka <ano### [at] anonymousorg> wrote:
> >> What bank uses a sheet of single-use codes and thinks that it's safe?
> >
> > Well, much safer than a fixed password.
> >
> > You can't do anything with the sheet alone if you don't have the user's ID.
> > Granted, it's not impossible to acquire both, but if you don't store your
> > ID anywhere and instead have it memorized, it becomes difficult. (Basically
> > they would need to install some spyware in the computer you are using in
> > order to get the ID, and then physically steal the passcode sheet. Not
> > impossible, but not likely to happen.)
> Just two words:
> (1) Phising.
> (2) Man-in-the-middle attack.
Does not help to get the physical code sheet.
> (A) Each time you submit a transaction via browser, you get a
> transaction-specific authorization code via SMS to your mobile phone,
> including some essentials of the transaction (like the amount of money
> transferred, and the target bank account) to make sure that you and the
> bank are talking about the same deal.
I suppose SMS verification would add an additional layer of security.
> (B) You get a code generator from your bank. Typically this would be a
> combination of a bank card with a built-in chip, plus a card reader with
> a built-in display to make sure that the code is generated from the
> transaction details you desire.
How exactly is this different from a sheet of one-use codes?
(Except, you know, the obvious: That method requires you to connect
a special device and software to your computer and configure it
appropriately.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 26.12.2013 01:23, schrieb Warp:
> clipka <ano### [at] anonymousorg> wrote:
>> Am 25.12.2013 13:39, schrieb Warp:
>>> clipka <ano### [at] anonymousorg> wrote:
>>>> What bank uses a sheet of single-use codes and thinks that it's safe?
>>>
>>> Well, much safer than a fixed password.
>>>
>>> You can't do anything with the sheet alone if you don't have the user's ID.
>>> Granted, it's not impossible to acquire both, but if you don't store your
>>> ID anywhere and instead have it memorized, it becomes difficult. (Basically
>>> they would need to install some spyware in the computer you are using in
>>> order to get the ID, and then physically steal the passcode sheet. Not
>>> impossible, but not likely to happen.)
>
>> Just two words:
>
>> (1) Phising.
>
>> (2) Man-in-the-middle attack.
>
> Does not help to get the physical code sheet.
Does not /need/ to get the physical code sheet. If someone can get in
between your screen and the online banking portal, they can tamper with
the transaction details to transfer an entirely different amount of
money to an entirely different target bank account.
Note that HTTPS only protects the network transmissions, not your
browser output.
>> (B) You get a code generator from your bank. Typically this would be a
>> combination of a bank card with a built-in chip, plus a card reader with
>> a built-in display to make sure that the code is generated from the
>> transaction details you desire.
>
> How exactly is this different from a sheet of one-use codes?
> (Except, you know, the obvious: That method requires you to connect
> a special device and software to your computer and configure it
> appropriately.)
As the code is now generated from the transaction details, tampering
with them is much less attractive for an attacker: If they hide any
changes from the code generator, the code won't be valid for the
modified transaction. If they pass the changes to the code generator, a
cautious user will notice that the details have been tampered with
(provided of course that the code generator has an inbuilt display on
which it shows the transaction details before spitting out the code, and
it provides no attack vector between that display and the actual
cryptographic engine).
As for "the obvious", that's actually a no-issue: The stand-alone device
I mentioned does not need any software on your PC, and the only
"configuration" required is a one-time calibration for your display
size; from then on, use is as simple as holding the device's light
sensor array against a flickering animation displayed in your browser.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
