Awesome questions, dude/t. Keep 'em coming!
ok, so despite all ork servers, etc, ultimately the security comes down to strength of user's password, correct? Because with that, the private key becomes assembled (somehow).
I would hope so, yes. Proving this claim would be an outstanding success of this exercise because we want to make sure we aren't introducing additional weaknesses with all ork servers, etc.
Assuming it's a given (although yet to be proven), the specifics of the protocol takes the standard security levels of user's password and increases it by several magnitudes of scale - meaning, even your weakest password will pose a tremendous challenge for a hacker using this authentication scheme. We're about to publish a research we did on the exact levels of improvement our scheme introduces to the conventional username/password authentication methods - so you will be able to see the details there. It would be great to get some public scrutiny on that too.
So in a real world scenario, phishing attacks, keylogging, etc would apply. yes?
Unfortunately and ultimately, yes. That is a common impediment to any human authentication technology (biometric, MFA, crypto, etc). There's still no cure for the infinite extent of human fallibility.
We definitely not attempting to solve that problem - rather significantly improve on the security and convenience of existing crypto usability.
I'll just leave this here for reference:
https://www.reddit.com/r/CryptoCurrency/comments/bokm1t/electrum/re brute force attack: do you limit the number of failed login attempts and/or notify user of such?
Yes. We have an exponentially-increasing-delay-throttling on failed login attempts on every ORK. We also plan to introduce user notifications at a certain point. We're still contemplating what the best point for that.
I just meant that if you were to simulate user logins/actions in order to make the contest more "real" and dynamic then each time a user creates or updates a record, it could contain the same 1BTC private key (as opposed to my previous suggestion of splitting the 1BTC into lots of pieces, ie divided between users). no big deal.
Your suggestion invited many long internal debates on the best approach to do that. Again, thanks for that! We're trying to think on the optimal way to implement it in a verifiable way - meaning, in a way we can prove to you (or a hacker) that those simulated logins actually happened/happening. This is posing quite a challenge without exposing the private key. One thing worth noting is, the simulated user will verify the javascript code hasn't changed using the SRI (
https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity) signature - so a hacker will have to circumvent that.
Again, this is for when we'll be testing the data-in-transit scenario, still will be happy to discuss more ideas on the best way to run this.