lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]



On Jan 16, 2014, at 5:13 PM, Rena <hyperhacker@gmail.com> wrote:

On Thu, Jan 16, 2014 at 8:11 PM, Tim Hill <drtimhill@gmail.com> wrote:

On Jan 16, 2014, at 4:18 PM, Coda Highland <chighland@gmail.com> wrote:

> On Thu, Jan 16, 2014 at 4:02 PM, Tim Hill <drtimhill@gmail.com> wrote:
>> First, I would not rely on language behaviors such as string compare time for security .. as others have explained here this varies from version to version (and even different build options) within Lua. Second, the normal approach here is to ALWAYS inject a significant (and pseudo-random) delay when responding to invalid credentials. This not only prevents time analysis attacks, it also protects against brute-force and dictionary attacks since it makes them take impractically long times. Don’t rely on the network being slow for this either.
>
> It's less a question of RELYING on it for security as it is making
> sure it's not a source of INsecurity. As has been described elsewhere
> in the thread, a pseudorandom delay doesn't actually help (it just
> makes a time analysis attack a little bit noisier) -- however a delay
> that increases based on the number of failed attempts DOES help.
>
> /s/ Adam
>

Hmm .. careful. If the delay increases by a known algorithm then it’s useless, as the attacker can know the inserted delay (assuming he/she has access to the source code), and can simply subtract it out, thus getting back to being able to deduce the string compare time. The pseudo-delay is valid as long as care is taken with how the delay is computed (and, has been noted, the random “span” of the delay should increase as the number of failed attempts increases).

—Tim



It's not useless if it increases substantially with each failure. It'll limit how quickly they can perform attacks.

--
Sent from my Game Boy.

Agreed .. but would you be ok with a hacker taking two months to quietly break into your bank account? There are two distinct issues here:

— Time taken to crack credentials, which can be mitigated by introducing successively longer delays at each failure.
— Password deduction based on timing of algorithms, which can be mitigated by introducing time delay jitter that swamps algorithm time with jitter “noise”.

—Tim