things like this typically fall into either attempt crimes or conspiracy crimes.. wiki has a good explanation of both concepts... links below.
in this particular case, there's an identity theft charge for submitting the invalid subpoena to the bank with the judge's information and an attempted identity theft charge for trying (and not succeeding) to access the judge's banking information.
How else are they going to prove they don't owe the $16k charged for lawyer fees?
Sounds like a $16k "don't poke around where you're not wanted" punitive charge. The $1.6M lawsuit was pretty offensive, also. None of this smells good.
That indictment is some serious bullshit. Did you actually read it?
The first count is for identity fraud from requesting a subpoena. No evidence that they intended to present themselves fraudulently, just the fact they filed a request.
The second is "making a false statement" that "some of these checks appear to have not been deposited but cashed illegally". The burden of proof on this would be insane, there's no way to show the defendant knew this to be untrue.
Finally, just FYI, the notification statute applies to banks, not individuals. The bank has to notify you of a subpoena, and it just has to do it before the information is released. It doesn't make just requesting one flat out illegal.
The indictment accuses them of intending to steal money from the bank accounts, and seems to refer to the allegation the journalist is investigating as a "statement which he knows to be false."
I hope this is the end of Judge Weaver's career and that the Grand Jurors are found culpable.
The indictment does in fact present evidence. Not to a jury, but to us, the readers. It makes claims that things are true. Ridiculous, outlandish claims, like that filing a subpoena was done to try to get checking account information.
You're right, I didn't notice the first count was identity fraud and the second was attempt to commit identity fraud. In a false statement, I'm pretty sure lots of laws, including the first amendment, protect your right to make a statement that might not be true. What you know is definitely relevant.
Finally, your excess of concern for this seemingly trivial case really confuses me. Who are you? Why do you care? What do you know that we don't? On the face of it, that indictment looks ridiculous but you claim there's more to there story. Can you back that up with anything?
I have to agree with you. The OP said they clearly violated the notification statute for banking record. Except that statute clearly states a subpoena issued by a valid agency (here a lawyer involved in a case) was a valid reason.
They presented just as poor of an argument against the article as they claim the article itself did.
I actually hope this is true as a consequence of them storing salted hashes for passwords. That is, Github should not ever see my password, only validate that I know what I entered previously.
It's pretty easy to keep a list of old salted hashes, and copmare the new password's salted hash against the previous ones. It doesn't require saving the old passwords.
To compare your new password with your old password, you take the old salt, hash your new password together with it, and compare the result to the old hash. If they match, you're trying to reuse the same password. You do this on the server side, naturally.
If salted hashing were done on the client side, it means you're actually sending username + saltedhash, instead of username + password to the server to log in.
So an attacker could submit a precomputed or stolen salted hash to be compared against the stored one -- completely defeating the point of hashing passwords in the first place.
>So an attacker could submit a precomputed or stolen salted hash to be compared against the stored one -- completely defeating the point of hashing passwords in the first place.
You could hash once on the client and once on the server to get the best (?) of both worlds. Really only the server one needs to be salted.
Since the resulting hash must be deterministic, you can't use a salt, and since you may login from crappy smartphones without JIT engines, you can't use many rounds. So the resulting hash will be trivially cracked using rainbow tables. The problem of variable-length passwords is better solved by only allowing the use of block ciphers in your TLS configuration, which you should probably do anyway.
As for the disadvantages, it makes logins take longer, forces the use of JavaScript, increases the complexity of code and increases the site size.
>Since the resulting hash must be deterministic, you can't use a salt
You can as long as it stays the same over time. Either lookup salt by username (requires an extra call back and forth) or use a single salt for the whole site, or actually you could have the salt deterministically depend on the username. All of those defeat hash tables.
I agree that the password length problem is not a great benefit, but the benefit that the server never sees the plaintext is pretty good in my eyes.
Logins take longer: a single hash+salt won't make a big difference even on low end devices.
Javascript: fair point, although plenty of sites require it for signing in anyway. I suppose you could make it optional.
Complexity of code: if it's in a library and vetted this doesn't matter as much. Conceptually this is pretty simple, would probably be 3-5 lines of code (2 lines to hash, 2 lines to generate salt from username).
> You can as long as it stays the same over time. Either lookup salt by username (requires an extra call back and forth) or use a single salt for the whole site, or actually you could have the salt deterministically depend on the username. All of those defeat hash tables.
And here you just answered your initial point.
> If the salt changes, you'd need to compute the password using multiple salts, which might have crypto guarantee issues when sent to the server.
If you're using different salts for each password and sending them from the server each time (the first option above), then my point still applies: the client would need to send the same password hashed to different salts, which may weaken security guarantees. (I don't know if any hash algorithms could be exploited using this, though.)
You can store this hash on the server and use it as a password. If this hash gets stolen, the attacker will be able to log in on YOUR website, but not on other websites user may share passwords with.
After that you can ditch server-side hashing, and use authentication protocol like CRAM-MD5 (I don't remember what the modern alternatives are) to protect against network traffic interception. While still not technically storing your users' passwords in the database.
EDIT: Using asymmetric crypto with a private key derived from the password would probably be better. But still, client-side hashing DOES gain you something.
"In business, a takeover is the purchase of one company (the target) by another (the acquirer, or bidder). In the UK, the term refers to the acquisition of a public company whose shares are listed on a stock exchange, in contrast to the acquisition of a private company."
the 4th amendment has been incorporated to the states. states can't legislate/constitutionalize less protections than what federal law provides.. you know... because the supremacy clause
this should be killed by a federal court very fast
The supremacy clause is, however, the basis for why state statute can't brush aside the protections in the federal constitution, including those incorporated against the states by the Fourteenth Amendemnt.
in this particular case, there's an identity theft charge for submitting the invalid subpoena to the bank with the judge's information and an attempted identity theft charge for trying (and not succeeding) to access the judge's banking information.
https://en.wikipedia.org/wiki/Attempt
https://en.wikipedia.org/wiki/Conspiracy_(criminal)