3 ms·

I know these guys have good intentions, but they seem confused about the guarantees that SRP provides. It does allow the server to verify the user's password wi

I know these guys have good intentions, but they seem confused about the guarantees that SRP provides. It does allow the server to verify the user's password without receiving it, but it doesn't help in any was against offline attacks. If the "password" (in this case verifier) database is compromised, the attackers will still be able to brute force the passwords. If they implemented it correctly, they will be salted, but this only makes the attack slower. Furthermore, nothing can protect you if your password is password. Also, I hope that they don't think this removes the need for SSL. It does not. In a web application the server sends the client the javascript to run. A man in the middle can modify it and defeat the whole point of SRP.

saym 14y ago
> Furthermore, nothing can protect you if your password is password. I'm not sure why you threw this line in with the rest of your response. I don't see what point you're making.
- vikstrous4 14y ago
  What I meant by that is that a brute force offline attack will always succeed if your password is easily guessable regardless of what hashing or password verification protocols are used.
kzahel 14y ago
I have an exercise: is it possible to create a javascript file (served over https) that, when included in a non-https HTML page, is able to determine whether any other scripts were included on the page or will be included on the page by a man-in-the-middle? If this were possible (I suspect it is not), then it might be possible to have secure javascript code running over a non-HTTPS url. (the motivation for this is to have some form of security and still be able to load websockets and make CORS xmlhttprequests to other (non-secure) hosts - with the assumption that these hosts may also be man-in-the-middled). For now, the only alternative is to use something like a packaged app, if you want to make sure your code is actually your code, and still be able to load insecure resources.
- vikstrous4 14y ago
  It's not possible. What's possible is using a browser extension to verify some of the essential javascript and use that javascript to do further verification.
- judofyr 14y ago
  An attacker can just remove the <script>-tag that points to the HTTS-served verifier. In general: If the site the user visits is plain HTTP then there's no way to trust the site.

saym 14y ago

> Furthermore, nothing can protect you if your password is password. I'm not sure why you threw this line in with the rest of your response. I don't see what point you're making.

vikstrous4 14y ago
What I meant by that is that a brute force offline attack will always succeed if your password is easily guessable regardless of what hashing or password verification protocols are used.

kzahel 14y ago

I have an exercise: is it possible to create a javascript file (served over https) that, when included in a non-https HTML page, is able to determine whether any other scripts were included on the page or will be included on the page by a man-in-the-middle? If this were possible (I suspect it is not), then it might be possible to have secure javascript code running over a non-HTTPS url. (the motivation for this is to have some form of security and still be able to load websockets and make CORS xmlhttprequests to other (non-secure) hosts - with the assumption that these hosts may also be man-in-the-middled). For now, the only alternative is to use something like a packaged app, if you want to make sure your code is actually your code, and still be able to load insecure resources.

vikstrous4 14y ago
It's not possible. What's possible is using a browser extension to verify some of the essential javascript and use that javascript to do further verification.
judofyr 14y ago
An attacker can just remove the <script>-tag that points to the HTTS-served verifier. In general: If the site the user visits is plain HTTP then there's no way to trust the site.