9 ms·

Can't you use Javascript to implement challenge-response authentication, which meaningfully improves security by: 1. Preventing interception of passwords on th

Can't you use Javascript to implement challenge-response authentication, which meaningfully improves security by: 1. Preventing interception of passwords on the wire 2. Allowing a tunable "difficulty" parameter which makes brute-force attacks cost ineffective 3. Requiring that brute-force attackers either run a Javascript interpreter (dangerous, because the web site chooses what they do and could make them mine Bitcoins) or rewrite their brute-forcer each time the JS-driven network communication channel is altered It seems to me that having a client-and-server protocol beyond just "POST this data here" can be more secure than sending a password to the server for verification...

dorgo 8y ago
>1. Preventing interception of passwords on the wire Isn't this solved by https? I have no idea, but I hope at least that https protects my passwords. >2. Allowing a tunable "difficulty" parameter which makes brute-force attacks cost ineffective I don't want to wait for a login more than a second. Actually, I don't want to wait at all. >3. ... or rewrite their brute-forcer each time the JS-driven network communication channel is altered How is this different from altered HTML/CSS? An attacker has to adapt to the altered login page. It is not an argument for javascript. >It seems to me that having a client-and-server protocol beyond just "POST this data here" can be more secure than sending a password to the server for verification... You say it: a protocol! not a piece of javascript.
- zbentley 8y ago
  > Actually, I don't want to wait at all. Neither do I. But I also accept that, given the sheer volume of stolen creds and bots out there, sites that damage their bang/buck performance, even at the cost of very minor inconvenience to users, are likely to be targeted less frequently and in lower volume. Even if I wasn't begrudgingly willing to pay that price, I'd at least admit to the logic of making the process more time-consuming as a deterrent.
- floatboth 8y ago
  > I don't want to wait for a login more than a second. Do you log in that often?
therealx 8y ago
I believe some US banks have been doing this for a while.
jhabdas 8y ago
PoW ought to make a better defense. It also require JS. oh wait...
mathw 8y ago
I find the idea of detecting someone's trying to bust your login page with some kind of automated system and deciding to serve them a ridiculously aggressive Bitcoin miner rather amusing.
- dspillett 8y ago
  You risk setting up a little cold war that you probably don't have time for though... "Think you are clever, eh, try this for size..." -- some attackers in response to being affected by your counter measures.
  - aequitas 8y ago
    Whats stopping that war from happening at any other time? If a attacker has the resources and carelessness to mount such an attack at a whim you should be prepared for it?
    - dspillett 8y ago
      Nothing, but trying to hack them back seems like a way to invite more personal attention than your services might otherwise get.
dspillett 8y ago
> Can't you use Javascript to implement challenge-response authentication > 1. Preventing interception of passwords on the wire It can, but challenge-response that isn't PKI based requires the remote side to have the secret stored or the local side to know how to generate the value that is stored instead, which goes against other recommended practise (with PKI the remote side can store the public key and ask for something to be signed with the private key). Protecting passwords on the wire is better done with good encryption and key exchange protocols - in the case of web-based systems that is provided by HTTPS assuming it is well configured. > 2. Allowing a tunable "difficulty" parameter which makes brute-force attacks cost ineffective Could you give an example of that? If you are tuning difficulty based on the computation power of the other side, surely the other side could lie about being low powered and get an easier challenge? > 3. Requiring that brute-force attackers either run a Javascript interpreter (dangerous, because...) A knowledgable attacker doing this would be safe: they'd make sure the interpreter was properly sandboxed (to avoid reverse hacking) and given execution resource limits (to avoid resource waste). Then if the site/app is important enough that they really want in, they modify their approach if the resource limits are hit. > or rewrite their brute-forcer each time the JS-driven network communication channel is altered If your method is only used by you (and you aren't a Google or similar so you are big enough to be a juicy target on your own) and you enter into this arms race you might find it takes so much resource that it gets in the way of your other work. You are only you, the attackers are legion: put one off and another will come along later. Also there is the danger in rolling your own scheme that you make a naive mistake rendering it far less useful (potentially negatively useful: helpful to the attacker!) than your intention. If the method is more globally used then it is worth the attackers being more persistent. > It seems to me that having a client-and-server protocol beyond just "POST this data here" can be more secure than sending a password to the server for verification. It can, though often only against simple fully automated attacks. Cleverer automated attacks may still succeed, as may more manual ones, and targetted manual attacks will win by inspection & replication. Or they get in through an XSS, injection, or session hijacking bug elsewhere (bypassing the authentication mechanisms completely) that you missed because you spent so much time writing an evolving custom authentication mechanism.
- rocqua 8y ago

dorgo 8y ago

>1. Preventing interception of passwords on the wire Isn't this solved by https? I have no idea, but I hope at least that https protects my passwords. >2. Allowing a tunable "difficulty" parameter which makes brute-force attacks cost ineffective I don't want to wait for a login more than a second. Actually, I don't want to wait at all. >3. ... or rewrite their brute-forcer each time the JS-driven network communication channel is altered How is this different from altered HTML/CSS? An attacker has to adapt to the altered login page. It is not an argument for javascript. >It seems to me that having a client-and-server protocol beyond just "POST this data here" can be more secure than sending a password to the server for verification... You say it: a protocol! not a piece of javascript.

zbentley 8y ago
> Actually, I don't want to wait at all. Neither do I. But I also accept that, given the sheer volume of stolen creds and bots out there, sites that damage their bang/buck performance, even at the cost of very minor inconvenience to users, are likely to be targeted less frequently and in lower volume. Even if I wasn't begrudgingly willing to pay that price, I'd at least admit to the logic of making the process more time-consuming as a deterrent.
floatboth 8y ago
> I don't want to wait for a login more than a second. Do you log in that often?

therealx 8y ago

I believe some US banks have been doing this for a while.

jhabdas 8y ago

PoW ought to make a better defense. It also require JS. oh wait...

mathw 8y ago

I find the idea of detecting someone's trying to bust your login page with some kind of automated system and deciding to serve them a ridiculously aggressive Bitcoin miner rather amusing.

dspillett 8y ago
You risk setting up a little cold war that you probably don't have time for though... "Think you are clever, eh, try this for size..." -- some attackers in response to being affected by your counter measures.
- aequitas 8y ago
  Whats stopping that war from happening at any other time? If a attacker has the resources and carelessness to mount such an attack at a whim you should be prepared for it?
  - dspillett 8y ago
    Nothing, but trying to hack them back seems like a way to invite more personal attention than your services might otherwise get.

dspillett 8y ago

> Can't you use Javascript to implement challenge-response authentication > 1. Preventing interception of passwords on the wire It can, but challenge-response that isn't PKI based requires the remote side to have the secret stored or the local side to know how to generate the value that is stored instead, which goes against other recommended practise (with PKI the remote side can store the public key and ask for something to be signed with the private key). Protecting passwords on the wire is better done with good encryption and key exchange protocols - in the case of web-based systems that is provided by HTTPS assuming it is well configured. > 2. Allowing a tunable "difficulty" parameter which makes brute-force attacks cost ineffective Could you give an example of that? If you are tuning difficulty based on the computation power of the other side, surely the other side could lie about being low powered and get an easier challenge? > 3. Requiring that brute-force attackers either run a Javascript interpreter (dangerous, because...) A knowledgable attacker doing this would be safe: they'd make sure the interpreter was properly sandboxed (to avoid reverse hacking) and given execution resource limits (to avoid resource waste). Then if the site/app is important enough that they really want in, they modify their approach if the resource limits are hit. > or rewrite their brute-forcer each time the JS-driven network communication channel is altered If your method is only used by you (and you aren't a Google or similar so you are big enough to be a juicy target on your own) and you enter into this arms race you might find it takes so much resource that it gets in the way of your other work. You are only you, the attackers are legion: put one off and another will come along later. Also there is the danger in rolling your own scheme that you make a naive mistake rendering it far less useful (potentially negatively useful: helpful to the attacker!) than your intention. If the method is more globally used then it is worth the attackers being more persistent. > It seems to me that having a client-and-server protocol beyond just "POST this data here" can be more secure than sending a password to the server for verification. It can, though often only against simple fully automated attacks. Cleverer automated attacks may still succeed, as may more manual ones, and targetted manual attacks will win by inspection & replication. Or they get in through an XSS, injection, or session hijacking bug elsewhere (bypassing the authentication mechanisms completely) that you missed because you spent so much time writing an evolving custom authentication mechanism.

rocqua 8y ago