Damn, lots of Text, thanks to anyone who has enough time to read it
Also, some says that this will not help as if someone would find a vulnerability he would just use it sometime instead of sharing it. I would be recommending to run BarsWF software with very restricted access (r/w access to current folder only).
By vulnerabilities i didn't mean exploits to gain access to clients (which actually should not be possible if we use client-TO-server requests only (not server-TO-client)), but exploits which could be used to fake real hashes, or gain extra points etc.
i.e. attacks against the whole idea or system of distributed cracking.
Of course it won't be a bad idea to run BarsWF with restricted access.
Would be nice if it only worked when im not on the pc, like if it could detect mouse/keystrokes and go idle. That way i could leave it running 24/7 and forget about it... and not have to open/close it constantly when i get on/get off the pc.
I already "talked" to BarsMonster about this idea.
The clientsoftware should/will definitely have an intelligent resource manager.
5) There is a cheat prevention scheme. All distributed projects suffer from fake packets (when someone just answers that "nothing found"). We will inject some extra hashes with guaranted result to each packet, as well as some non-resultative hashes. DB packups every 6 hours for easier cheat investigation and rollback.
In addition there will be private and public fake hashes. The reason is simple:
If we add private fake hashes only, an "attacker" could run the client two times and get two packages of the same "cracking task".
The "attacker" would be able to see which hash is the same in both packages: -> This one is in most cases the real hash.
Therefore the "attacker" could return "not found" for this hash without even trying to crack it and ruining the whole concept of distributed cracking at the same time.
If public hashes are added, two packages will have more than one identical hash.
For those who don't understand this concept, i will make a diagram later this day, containing the whole cheat prevention scheme.
Corrections and ideas are always welcome.
8) Most likely non-computing code would be open-source to be more trusted.
I don't believe that this will prevent people from stealing your code.
Personally i take no stock in packing or encrypting software. Those who like to steal your code will in most cases be able to, independent if you use "open-" or "close source".
You would do far better by choosing a good license.
Last point i would like to propose (without a quote) is a simple and clean client. All organization etc. should be done on the website.
There is one simple reason: I believe no one is really interested which packages the client is currently cracking (i am talking about the distributed client, the usual BarsWF should "stay" as it is), but likes to see the current progress of the hashes he or she inserted.
Therefore the website should be the major "tool" to manage your "stuff".
My idea of a client would be simple:
Start the program, insert Username and Password, see some information about cracking speed and todays earned points.
But i also like you idea, hashkiller. (own client)
And i totally agree to:
After this experience i might say that a system with too much limitations against the user might keep them of using your system.
So an interface for writing your own client would be the best idea.
. Protocol still going to be open.
