|
||||
|
I think that the idea itself pureh@te is good and your intentions with it are good as well. But I think that as cybrsnpr mentioned the Non-Disclosure Agreement may be a big hindrance of using this in an actual paid pentest.
The data would/could be considered proprietary. As such companies may not want their hashes being uploaded someplace outside of their control. As an example I am not allowed to store anything "government" on my company laptop but I can access it all I need/want to. The servers that hold the data are controlled by a third party (CSC in this case). Now the only reason for this is due to non-disclosure agreements. If I lose the laptop for some reason I don't have a lot of secret whatever that can get me in trouble ( the laptop itself is a different story). This keeps the company and the Government "clean" I am wondering how you could ensure that the data you have is not stored and can not be re-accessed.
__________________
The very existence of flame-throwers proves that some time, somewhere, someone said to themselves, You know, I want to set those people over there on fire, but I'm just not close enough to get the job done. George Carlin |
|
||||
|
Quote:
|
|
||||
|
Quote:
Speaking only from a "how would professional pentesters be able to use this" aspect: The only way I think you could do this would be to incorporate, get bonded and insured and then enter into NDA's with each entity that wanted to use your services. Even then, I'm not sure that it would be enough in some cases (always dependent on how the client services contract is written). You would still need to take into account seperation of data, data at rest, security in transit and many more things. For the scenario I gave in my first post to you in this thread, if all of the above was covered, then I as a business, could potentially use your services as you would be a "trusted partner". But I know of some organizations that for many reasons, could never use such an arrangement. I'm afraid you would be left with, as others have mentioned, skiddies trying to hack their neighbors wireless. |
|
||||
|
While getting bonded and insured may be of help, here is another problem that I was looking at before. I wanted to do a little more research before posting. Basically I believe that you would be in violation of U.S. Federal law in that, a party can obtain a communication ( in this case the password hash) they can also know the start and endpoints for said communication but they are not allowed to know the data in the communication. So I can capture the hash but I am not allowed to decode it. Or even if it is plain text view it.
On the other hand the Computer Fraud and Abuse Act, 18 U.S.C.§ 1030 (the "CFAA") states that, Quote:
As such a service like yours would be ok to use. But this leads us to another problem, How can you verify that the submitted data is legal? You would need a way to verify what you receive is legally obtained, otherwise you would be in violation of the law. So as long as a pen-tester is able to do such things it would only be a matter of writing into the contract that your service/s may be used in order to decode a password hash. If a company chooses to have a pen-tester audit it's passwords then it should be ok for them to use your service/s to do so. It would be the same case as using "hydra" or "Jtr". The company will in most cases automatically assume full ownership of the data in both the coded and decoded forms. So this means you would have to have a means of proving (if needed) that you store none of that data. But then you may run into another problem with passing email/s since each server in the chain could/would have a copy of it. This could be mitigated using gpg/md5 or whatever to ensure that if the data where not deleted from the servers along the chain that at least it could not be easily read. This would also assure all parties involved that the data if stored along the route is not really usable since it is the property of a company. On another note as you well know once a password been decoded it really is no good anymore. So this brings us to having rules in place to prevent simple dictionary based passwords. For instance we use RSA SecurID's however we have a need for them. As such my company probably does not worry too much about passwords themselves. BTW a great read on the above law/s can be had here I am sure that when Thorn comes back around he can/will provide some good info on the aspect of the law as well.
__________________
The very existence of flame-throwers proves that some time, somewhere, someone said to themselves, You know, I want to set those people over there on fire, but I'm just not close enough to get the job done. George Carlin |
|
||||
|
Probably the best way to get around questions of legal use, and who might be a legitimate user, would be to offer this as a subscription service. You could vet the subscribers before issuing user credentials. A big advantage to offering it as a subscription as oppose to a low-cost 'pay per incident' would be that you'll almost guarantee that you would not get script kiddies even considering using the service.
__________________
Thorn “Never try to teach a pig to sing; it wastes your time and it annoys the pig.” - Robert Heinlein |
|
||||
|
Quote:
__________________
A 3rd Party Security Audit is the IT equivalent of a Colonoscopy, it's long, intrusive, and when it's done you'll have seen a lot of things you really didn't want to see, and you'd definitely remember that you had it done. I ♣ baby harp seals. |
|
||||
|
It would probably be better if you could configure the webserver to actually upload the files to a RAM disk and not to the actual harddrive. That way, when the server is rebooted, there is no evidence whatsoever of the files existing.
__________________
A 3rd Party Security Audit is the IT equivalent of a Colonoscopy, it's long, intrusive, and when it's done you'll have seen a lot of things you really didn't want to see, and you'd definitely remember that you had it done. I ♣ baby harp seals. |
![]() |
| Bookmarks |
| Thread Tools | |
| Display Modes | |
|
|