Protecting firmware .bin from reverse engineering I would like to protect my .bin ( squash fs ) file after compiling process in order to avoid reverse engineering techniques ( i.e. binwalk could simply unsquash my .bin firmware and see all the file system )
Could you recommend any tools for crypting the .bin file or other techniques?
Hope my question is clear
Thanks

@Marcus is completely correct about using encryption, and how the key has to be stored somewhere safe and possibly used in conjunction with secure boot. As far as tools go, there are many symmetric and asymmetric encryption schemes that may be suitable for your use case.
However, you can't protect 100% from someone obtaining your firmware. You can only increase the difficulty of reverse engineering such that the effort required outweighs the potential reward of obtaining it. Of course, this will depend on the type of adversary; a casual user may give up immediately after seeing that it is encrypted, but a professional outfit may spend much more time and money until access is gained.
So, you can tailor your defenses to what level of threat you anticipate and balance that with what you are able/willing to spend. If you only want to protect against a casual user, it may be sufficient to only encrypt the firmware in transit, and have the firmware decrypted upon receipt using a key stored in firmware. This method requires very little investment on your part, but it also may fall over pretty quickly for someone who is more determined.
Of course, you can step up to using secure boot with a hardware security module, using the keys to decrypt firmware only on boot, but as mentioned, this is an architectural decision and will possibly incur more time/cost.
The problem is, even if you store the firmware encrypted in the best way possible and make the keys extremely hard to recover from the hardware, you also have to do everything else right. All it takes is one vulnerability in your software for a user to get a shell on your system, from where they could dump the firmware. Or, maybe there are debug ports (JTAG/SWD/UART) left on the board itself that could allow access with a little hardware hacking.
The point is, once your system is physically in someone else's hands, it's a losing battle from there. So maybe it's time to ask; what is it that you are really worried about being reverse engineered? If it's for security purposes, consider searching for and fixing vulnerabilities internally instead of hoping to hide them with security through obscurity. If you are trying to protect proprietary code, you could protect it through legal means instead of hoping nobody recovers it.


Potential collision with hash password Normally, the password size is fixed by the hash function in which the password is given right ?

Because otherwise, if the password size is bigger than the hash result size, there should be potential collision am I right ?

Ex : Consider the Hash function SHA-1, the size of result is 160 bits (or 20 bytes). If the password size is bigger than 20 bytes then there are at least two possible password for the same hash.

What you're talking about is known as the pigeonhole principle - if you have n possible passwords and a hash function with m possible outputs, where n > m, there will always be some input values which produce the same output hashes.

The question then becomes: does this matter? With a hash output space of 2160 possible values, an accidental collision has a probability of about 6.842×10-49. Not a whole lot. This gets more interesting when you look into birthday attacks, because the probabilities get much higher, but it's still generally considered infeasible to find 160-bit collisions using naive methods such as brute-force.

In reality, a smart attacker is more likely to focus upon vulnerabilities within the hash function which reduce the necessary computation in order to find a collision. But, in the arena of password storage, this should mostly be moot - passwords are easy to crack if you only hash them with SHA1, because GPUs can brute-force at a rate of billions of hashes per second due to their massively parallel nature.

If you want to store passwords safely, don't use a hash. Use a key-derivation algorithm designed for password storage, such as PBKDF2 or bcrypt. You should also take a look at a related answer I wrote about salted hashes, which goes into the history of how we progressed from hashes, to salted hashes, onto modern KDFs, and the rationales behind each defense and attack step.


Why is TLS for email not pushed aggressively to the users likes HTTPS? Major browsers like Chrome and Firefox are being more and more aggressive at displaying the security level of websites, for instance warning you when you try to enter passwords on a non-HTTPS website.

I just saw in GMail that emails from major websites are actually signed and use TLS (for instance an email from PayPal: "signed by mail.paypal.fr") but you have to click on a small arrow to reveal a menu to see this, and it's written in small without any colors.

OK, for the colors, GMail reserves the green for S/MIME;
But still, is there a reason for not displaying a big "SIGNED by mail.paypal.fr" or "NOT SIGNED" immediately visible? This would prevent a lot of phishing, right? Why such a difference with HTTPS?

EDIT

OK, I guess my question was not very clear.

The comment of @shroeder (here) partly answered it though: dumping non-signed emails is the kind of things I meant as "aggressive pushing". Again I guess I don't know enough about email security because I do have many emails in my GMail where there's not "signed by XXX" in the "more informations" bubble, so I guess it's another signature @shroeder is referring to?

I'm sorry if my question was not well formulated; it's just that I received yet another phishing email so I was wondering how come I still have to rely on myself to identify a spoofed email from a legitimate one in an era where all the important websites I have an account on have HTTPS (so they're already signing stuff all the time and my browser will freak out when something is wrong with the signature).

Turns out I didn't receive this phishing email on my GMail account but on my work one, on Thunderbird. So I guess my "true" question would be:

How come emails from my company are not signed even though they have an HTTPS website? Is it a lot more work? And how come I never saw any info in thunderbird about the "security level" of the emails I receive? Because I know thunderbird does show it when an email is signed with PGP for instance.

Instead of telling my personal story I tried to come up with a more "general" question, and... well apparently I didn't go that well.

There are a lot of questions embedded in your "question". I'll try to explain a few if I can. There is also a lot of confusion here between different aspects of security. Certainly there seems to be a fallacy that, because an organisation has a certificate that helps assure you that their website is actually theirs, that means you can somehow provide email security with it. That is simply not true. Web sites and email services are entirely different things, running on different servers and possibly different platforms. Quite probably run by entirely different 3rd parties.

There are two separate parts to Email encryption. The mail itself and the transport between mail systems. The former uses S/MIME or GPG and the latter uses TLS (similar to a website).

If you look at definitions for secure email services such as government ones. You will see that TLS encryption between mail services is a requirement. This is easy enough to achieve using, for example, transport rules in Exchange. Because you typically secure a limited number of end points, this is reasonably easy to manage. Ideally, mail servers would all talk to each other over TLS and mutually authenticate - to do that, the public certificates for the mail servers from each organisation have to be shared with each other. So you can see that even this can get out of hand very quickly without a complex Public Key Infrastructure in place.

On the other hand, to encrypt individual emails is an even more difficult job. The technology is easy enough. Again. it is managing the certificates and keys that is difficult. That is why this is rarely done anywhere as a blanket requirement. Even governments rarely encrypt emails except for the most sensitive information and even then, you are more likely to find an encrypted attachment than an encrypted email since attachments can be encrypted with a simple password which can then be distributed via another channel.

Very little actual innovation has happened on email clients for years. I was hitting my Microsoft contacts over the head about this the other day and encryption is one area that lacks innovation. Everyone seems to be focused on other forms of communication - maybe they think email is "done"? Likely, they think (perhaps rightly) that there is no money in it. So that is one reason you are not getting what you want.

Other reasons come from how you would calculate the security "level"? That is not an easy question and will be different for each person, organisation, mail system, content classification and more. Unless some parties come up with an agreed standard, it is unlikely this could ever just happen.

There is also a third area that impacts on your questions however and that is directly related to controlling at least some forms of phishing, namely emails that appear to come from a legitimate service but actually don't. For that, there are a number of standards that work together: SPF, DKIM and DMARC. All mail services should have definitions for these (they are stored in your DNS). They enable mail services to verify whether an incoming email actually came from an authorised mail server. This is gaining traction across mail services but is not always enforced as yet.

So the bottom line is that cryptographic signatures on emails is difficult because of the need to manage access to millions of certificates allowing verification of the signatures. However, a measure of security is provided at the server level by requiring validation of sending servers which at least gives assurance that the email came from the correct service - which I'm guessing is what GMail is actually doing. This is not generally exposed in mail clients since there is so little development and innovation happening in that area (Google are something of an exception). But on the other hand, if a mail service enforces SPF/DKIM/DMARC, you wouldn't need to see an indicator since only mail from verified servers would get through - though that could still allow spam through, just not from faked origins.


RSA vs ECC certificate for IoT device client side certificate authentication I am using client-side certificate authentication (mutual authentication) in my IoT prototype. we acquire client side certificates using embedded PKI through a CA.
There are the provisions of acquiring ECC or RSA certificates. I was wondering which one is more apt to use to ensure stronger security!
while I understand that RSA is a widely used algorithm, ECC claims to provide higher level of security and also faster also probably due to its shorter key length size. but ECC is a newer algorithm and likely to have undiscovered vulnerabilities.
Could you guide how do I make a right decision here, if ensuring security is prominant criteria. IoT device that is being used is MCU based and is not a low footprint device. (consider its a telematics gateway unit in an connected vehicle).

RSA and ECC are equally secure. They are both secure if implemented and used correctly, and both prone to similar amount and gravity of mistakes in implementation and use. The only reason why security would be a consideration is if you happen to have a poor implementation of one and a good implementation of the other.
ECC does not claim to have a higher level of security. (If you read that, it's misinformed.) ECC has a higher level of security divided by the key size, i.e. an N-bit ECC key is in some sense “more secure” than an N-bit RSA key against brute force, but that's irrelevant: RSA key sizes are larger than ECC keys for this reason, and in both cases, you would pick a key size that's large enough for brute force to be infeasible. The weakness in cryptography is not brute force attacks (except when passwords are involved), it's misuse and bad impementations.
RSA signature verification is faster than ECC (ECDSA or EdDSA) signature verification. RSA signature calculation is slower than ECC signature calculation. RSA signatures are larger than ECC signatures. (All of this is comparing things that it makes sense to compare, i.e. at equivalent levels of security, not at equal key sizes which would be meaningless.)
There are two common families of ECC signatures: ECDSA and EdDSA. To choose between them, security is slightly relevant, but it doesn't clearly point one way or the other. EdDSA is newer so implementations are less mature and may be buggier, but on the other hand EdDSA is a more mature design which is easier to implement correctly.
Both RSA and ECC will be broken by quantum cryptanalysis if it turns out to work the way many computer scientists hope. If your device needs to last for a long time, make sure that you can update your whole infrastructure to support post-quantum crypto (PQC) in a few years, once it has become more mature. Note that this is a difficult task, since it means much larger keys and signatures, and stateful signatures. You don't have to support PQC yet (and you should not use PQC in production yet as it hasn't received enough cryptanalysis), but now is a good time to start thinking about key storage and algorithm agility.


My website keeps getting infected I recently started getting this really weird problem where a virus seems to pop up as frequently as once a week in my site. It is running on BlogEngine and basically what happens is this:

A bunch of .PHP files start appearing in my site folders
It appends an iFrame in my page that links to a page countXX.php, where XX is a random number

Sucuri.net listed the virus as MW:EXPLOITKIT:BLACKHOLE1, and said it is one of the most common viruses circling the net as of lately. This has more information.

Please does anyone know how I can protect my website against this? It is wasting me a lot of time.

You need to blow away the site and start from scratch. They have gained access to your server and changed files. You have no idea how far they have gone, which means "it is not your computer any more". It is very possible that they have replaced various files, which will make it possible from them to maintain access even if you change passwords.

Take down the site, re-install whatever binaries you use, then re-upload your files from a known-good source. Anything less is no guarantee that you can keep them from using a backdoor.

Your code also needs to be reviewed for vulnerabilities by someone qualified to do so. Yes, the comment and email fields are a way for attackers to gain access to your server if those fields are not properly coded.


When I turn off request validation in asp.net, am I vulnerable? So I have request validation off in my web application. You can add /foo?=<script>and my web application won't catch it -it doesn't filter it-

Does this make me vulnerable to attacks; should I turn it on?

This depends if you are correctly encoding characters on output. For example, for HTML the < character should be encoded as &lt;.

If you are doing this everywhere, then you can safely turn off Request Validation.

This is a better method as some character sequences can bypass RV depending on the context in which the input is later used. For example, if the value makes it into an HTML attribute value, a sequence like

" onerror="alert('xss')

will bypass it when it is inserted into

<img src="/foo.jpg" alt="<user input>" />

as this becomes

Also, input from sources other than ASP.NET can mean that scripts can still be inserted into your application. This is why I recommend correct output encoding rather than attempting to validate input. Globally validating input is an even bigger problem as there will always be gaps when there is no option to validate context.


Does Centralisation Decrease the Probability but Increase the Damage of Exploits? This question is, perhaps, a tad too abstract for a Q&A site. But it's been playing on my mind for a while, so I'm throwing it out there.

Modern systems seem to be increasingly centralised. An average user in the '90s would buy a computer from one manufacturer, have an OS by Microsoft, and then have a range of other suppliers for basic functionality such as compression applications, web browsers, and even memory extenders for the OS itself in the days of DOS.

Even the process of getting applications was a pretty decentralised process: one may use a search engine to find a company's website and then download an executable from it.

Today is of course very different: the OS builds most of the basic functionality in and often ties it with their online services. The process of even finding applications by other suppliers is done via the same company's 'app store'.

Anyway, on to the question: does centralisation, as a rule of thumb for security, increase the damage but decrease the probability of exploits?

I wonder this for the following reasons:

Downloading exe files from a range of sites is malware-prone, as any of us fixing a friend's computer in the early 2000s would know...
However, if a centralised 'app store' were to be properly hacked, it could impact every single application it distributes.
Building in more functionality into the OS decreases the likelihood of third-parties injecting potential security holes into an average OEM package for consumers using the aforementioned OS.
But unifying all applications as built-in for the OS means that, say, if the compiling process for the OS development was breached, the entire thing would get compromised. (This is overly simplistic; I'm not genuinely suggesting, for example, that Windows Media Centre is compiled alongside the actual NT kernel.)

In short, centralised systems seem to safe-guard newbies against trivial security issues. But isn't the damage of a centralised supplier being hacked much greater than only a single small supplier being broken into?

The probability of exploits is a vague term.

What you've got in reality is the number of exploitable bugs in the code, the number of bad guys working to find them, and the number of good guys working to close them (it is useful to think of this stuff in terms of FTEs - full-time equivalents, even if many researchers (blackhats and whitehats) don't dedicate themselves 8/40 to the task at hand).

Centralization tends to increase the incentive to hack - the stakes are much higher. D3C4FF is right that this indeed puts all the eggs in one basket.

However, centralized organizations can afford spending money on hiring the good guys (ex-bad guys in some circumstances). Large firms have the brains and dedication and foresight to make some of the staff available for security research instead of toiling like monkeys for immediate monetary gratification of the shareholders. IBM and Microsoft are prime examples, IMHO.

Centralized organizations can be practically considered monopolies; it is often surmised that monopoly status makes companies lazy and overly arrogant (Oracle, I'm looking at you re: Java patching!).

The resulting interplay of psychological, organizational and sheer quantitative factors gives a very rich picture.

To sum it up, the risks are greater, the potential for losses is getting enormous, but there are some forces that mitigate the risks. It would be very rash to say that probability of exploits goes down.


How is the key obtained when I login via VPN? So, I configure my VPN (let say which uses PPTP protocol), enter the server name, username and password. Then, I visit a website. Before that, my request is encrypted using AES with some key. That request is sent to the VPN. How does that VPN decrypt data? How can it know what the key is? How is that key obtained between two parties? Or is the first request is sent with my username and password, VPN checks if user exists, generates the key, and sends it back to the user? But it would be insecure to do that. Also, a different key should be created when I login via mobile.

The precise details will depend upon the specific VPN software you use, but generally, the same cryptographic key will be pre-loaded into both ends of the VPN.  It may be specified in a configuration file, or derived from a passphrase, or in some other way made available to both endpoints.  That's how the VPN software on your machine encrypts data and how the VPN software on the end end can decrypt the encrypted data.


Similarity comparisons with hashed passwords possible? At a company I worked at, I had to change my password every 90 days and I could only reuse a password after 8 iterations. This no-reusal included passwords being too similar to the old one, e.g. when I only changed one letter, that new password was not accepted.

Does that mean they were storing this password in plaintext? This seems rather bad practice to me. Or is there some hash function that allows similarity comparisons?

No, it does not mean they are storing the passwords in plain text. The question doesn't completely describe the behavior. Are they matching patterns only from your current password, or patterns from all 8 of your previous passwords?

If it's the first case, the answer is dead simple, and this is that they have the hashes from the 8 previous passwords to compare against, and when you change your password, you enter your current password as well as your new password, and they now have both of these in plain text to compare for patterns. This is more likely what is happening.

If it is the second case, there are still several other ways this could be done, including storing the passwords in an encrypted (rather than hashed) format, so they can be decrypted and compared, or storing the pattern (or mask) of your passwords along with the hashes and then disallowing new passwords that match any of those old masks. Arguably these options are not as secure as just storing the hashes, but that shouldn't particularly concern you... It's risk to the business not to you, and if they feel it's acceptable risk, then that is their decision. Your only concern (and regardless of the password policy at your company, this should always be a concern for you) is to ensure that the passwords you use for work network are different than the passwords you use everywhere else, so a compromise of your work password doesn't endanger your personal accounts and vice versa.


Are these weird emails spam without content? Since this morning, I have received on my professional address myfirstname@mycompany.com (that usually receives very few emails, between 3 and 5 a days) three strange messages:

First message:

sender: ***@yahoo.com
subject: test
content: Sent from Yahoo Mail!

Second message:

sender: ***@yahoo.in
subject: None
content: Verifications 16316 6 16 1 11 1

Third message:

sender: ***@outlook.com
subject: Verification-2109GEds145
content: Verification Purpose only sdfsdf4
d

I am guessing that my professional address has somehow gotten in the cloud, but what is the purpose of these repeating emails that I receive?  Is it spaming stage 1, where senders are veryfying that my email address is not bouncing?

How can I:

know the purpose of these emails - are they just spam or is it something I should be more scared about?
try to prevent or correct my receiving of such emails?

PS : the X-Original-To  and  Delivered-To  addresses are myfirstname@mycompany.com,  but i see no address in the "To" field that displays in my email client

Empty emails could mean several things:

The sender is attempting to maintain or grow a database of
emails that are legitimate spammable addresses.  Any address that
doesn't respond with a no-such-user error is implicitly valid - even
with a margin of error for the volume of email addresses being
collected.
There is malicious content in the email, which is
stripped from the email by a spam filter - but this means that the
spam filter you use is OK with sending you an empty email.
Spammers make mistakes too - remember how terrible you feel after you forget to include attachments.


Is using a phrase from a book as a password such a bad idea I've been told/seen online that choosing a sentence or a phrase from a book and using it as a password is a bad idea. How is this true? Unless the potential attacker knew which book you used I don't see how this isn't basically a brute force problem. In which case an random sentence of at least 24 characters should be impossible to crack, no?

Yes, it is a bad idea. The number of books in the world is quite finite, and efficient password cracking software can make billions of guesses per second against an offline password hash. It is not at all difficult to try every single possible combination of phrases in every single digitized book in the world.

The length of the sentence itself doesn't matter either. This is because an attacker will be taking entire sentences and phrases at once and hashing them. They will not try to brute force it from scratch.


Is it safe to save a screenshot of my QR code? For MFA I now use Authy (owned by Twilio) instead of Google Authenticator. I find Authy more convenient because it syncs your accounts between several devices and several authy installations which Google Authenticator will not do. Authy also displays the remaining time before a token times out so that you can see if it is about to expire. I also take a screenshot of every QR code so that I can register it again with a new device or a new MFA app. I can confirm that a token from Authy works to authenticate with AWS. There is also another MFA app named FreeOTP which I did not try.

If someone "found" that image file from the QR screenshot, and they "guessed" my password, what would prevent them from impersonating me without me noticing it?

For example, someone has FreeOTP, has the QR code screenshot and knows my AWS password (highly unlikely but possible). I tested reading an screenshot of a QR code and register it with FreeOTP. FreeOTP did start generating a valid token (same as in authy).

What I really want to know is: Is it a security concern to save a screenshot of the QR code?

The QR code used on setting up MFA contain the seed that is used for the MFA process. That's what allows you, having that initial QR code, to set up another client with the same codes.

The drawback of this is that, just as you can set up a second client, a third party that got hold of those QR codes, could do that as well. Thus, if someone got that QR and password, it would have all needed information to log in as you.

I would say it is a security concern only depending on how it is being stored. You may store those QR, but I would recommend treating them as passwords, note they guard (half the) access to the relevant account. For instance, you may want to rather than syncing them with the cloud like other photos to save them in a password manager instead.

PS: It's equivalent here that you are using Google Authenticator, Authy, FreeOTP or other client. Most likely, the MFA is using a TOTP token, as defined on rfc 6238. which many clients support.


Repair Truecrypt NTFS-partition with undetectable filesystem Long story short:
Got 1 TB HDD. Created one fullsized (non-system-)partition on that. Encrypt via TC. One time, via boot, Win presumably formats that (and maybe writes some bytes on it).
I manage to restore TC-Header, now TC can mount the partition. But Windows says "Must format drive to use it." "Filesystem not detected." Anyways, I can recover nearly all data via GetDataBack from this mounted partition.

This is where I'm now. Now I just want to know: Is there a way how I can repair the partition and use it "normally" again? Or do I have to reformat, and copy back the backedup files?

TC repair said "... Filesystem is NTFS ... First NTFS startsector not readable ... Going on with second NTFS startsector ... version and status of volume cannot be detected. Aborting"

TrueCrypt provides a volume: a big sequence of bytes. TrueCrypt puts itself between these bytes and the physical storage medium, by applying encryption whenever the data is to be written to the disk, and decryption when it is read. TrueCrypt stops there. The meaning of these bytes is none of TrueCrypt business.

An operating system like Windows will take this bunch of bytes and organize it into an abstract set of directories and files. This requires dedicating some of the bytes to "administrative tasks", to encode the structures which tell where the file data physically is, and what are the file names, access rights, modification dates and so on. These structures are called a filesystem. NTFS is a filesystem.

In your case, Windows says: in these bytes, I see no filesystem. The TC repair tools comes to the same conclusion: there is no recognizable structure usable as a NTFS filesystem. GetDataBack can recognize shreds of a NTFS filesystem and scavenge some of the files, but GetDataBack does not pretend to repair the filesystem (in the same way that extracting reusable parts from a wrecked car is not the same as making the car functional again). All these tools work on the "big sequence of bytes" that TrueCrypt can show by decrypting that which is stored on the disk. In other words, TrueCrypt is not relevant to your situation (except maybe as the culprit).

For some reason, which is not yet elucidated, the filesystem structures are damaged, and are gone. Since TrueCrypt has no idea whatsoever about what a filesystem may be, it can be considered as a sort of extension of the hard disk, storing whole sectors, not files. It so happens that the OS, at some point, asked TrueCrypt to write down some bytes which appeared to be garbage, and to destroy the filesystem structure. TrueCrypt merely complied.

The best you can do, at that point, is salvage what you can with GetDataBack (as you say, "nearly all data") and/or exhume your last backup, then start over with a fresh format.

There are many possible reasons why this sort of problem may occur. A bug in TrueCrypt could explain it; but also a failure in the hard disk itself, including the electronic part of the disk. I also once (actually, three times) had a problem with a PCI network card which, under high load, would begin to put random noise on the PCI bus. This triggered an OS "panic" and the kernel would then do a quick unmount of the filesystems, thus writing a "clean" superblock (the top of the filesystem structure). Unfortunately, that write call would travel over the PCI bus, and the data reaching the hard disk would then be utterly mangled. This was leading to the same symptoms as what you presently observe.

A bug in the OS itself (Windows) could also be a plausible explanation. Even more probable, bad RAM: the OS works by following structures in RAM, which tell it what to do. A bad bit at the wrong value can wreck havoc to these structures and induce the kernel to write out garbage data on its disks.

The possibilities are endless. Therefore, make regular backups.


TOR makes multiple connections - why? When using TOR, I issued this in terminal sudo netstat -punta | grep 443. Output was

tcp        0      0 x.x.x.x:y      a.a.a.a:443        ESTABLISHED 5769/tor
tcp        0      0 x.x.x.x:y      b.b.b.b:443        ESTABLISHED 5769/tor
tcp        0      0 x.x.x.x:y      c.c.c.c:443        ESTABLISHED 5769/tor

This output is when I am almost an hour into the session. Why there are 3 encrypted connections ? I thought there is one entry node. TOR connects with at least 3 nodes, but it does serially. So, there should be only one connection at my end.

I'm assuming that you're not running a relay yourself, which would of course explain multiple connections.

According to the Tor FAQ, Tor will reuse a same entry node for TCP connections for a duration of 10 minutes, and will then switch to a new entry point. This avoids profiling all of your Internet traffic via a specific entry point (which could help fingerprinting attacks based on the sites you visit).

Previously open TCP connections will keep using the same entry node until the session expires, so if you browse multiple sites but keep the TCP connection active on the first websites, you could easily end up using three different entry nodes.


How to protect data on a thumb drive So I had a scare this past week (couldn't find my thumb drive) and figured I'd better put in some protection on my thumb drive.

What is the best way to encrypt the data on the thumb drive?  I am a Windows user, not concerned about having access to these files on any other system.  I would want access from Windows XP and up.

Truecrypt,  with an executable of the installer in the thumb drive (unencrypted ofc) so you can install it on any computer you plug your thumb drive. If it's possible encrypt with a pass in the form of HA&%^&G^ARELIBSFhahdjag62r&^^^5129380y. Drawback of this is that you'll have to carry another thumb drive with you to contain your password in .txt. Unless you can remember something like that :P.


Missing 'Key Usage' on a CA certificate: can sign certificates? In Windows certificate store, an intermediate CA certificate without Key Usage extension is considered eligible (as long as it has isCA flag from Basic Constraints of course) for singing end entity certificates (such chain is considered valid).
But, RFC 5280 states that

  4.2.1.3.  Key Usage

  Conforming CAs MUST include this extension in certificates that
     contain public keys that are used to validate digital signatures on
     other public key certificates or CRLs.  When present, conforming CAs
     SHOULD mark this extension as critical.

My understanding is that an absence of the Key Usage ext. is an inability of the intermediate CA certificate to sign other certificates.
Is this a bug in Windows' validation chain procedure or my misunderstanding of RFC?

You are not incorrect, and neither is Windows.  You're just using different sets of information.

RFC 3280 sec 4.2.1.3 (which was carried into the updates for RFC 5280) says that a CA must include the KU extension in any child CAs.  So any CA which doesn't do so is not following the guidance of RFC 3280.

ITU-T X.509 (2012-10) sec 11.3.2 describes when a certificate is a match against a set of constraints.  And it says:

  keyUsage matches if all of the bits set in the presented value are also set in the key usage extension in the stored
  attribute value, or if there is no key usage extension in the stored attribute value;

(Bold in the original, italic emphasis mine)

So, a CA, under RFC 3280 or RFC 5280, MUST include the extension.  But X.509 says that the chain builder/verifier should consider it valid to be missing.


Database compromised (SQL-injection): how to handle the situaton, after the fact? Situation

We found out that one of our (MySQL) databases has been compromised through SQL-injection. The injection vector was a query that was vulnerable to SQL-injection due to string-concatenation in its WHERE clause.

The MySQL-user for the web application in question ran with fairly limited privileges (SELECT, DELETE, UPDATE, INSERT) on a single database along with the information_schema database. The database-server is only accessible from whitelisted machines (no unrestricted internet access).

As far as we can see, the attacker performed all interaction with our database through HTTP GET requests to the vulnerable web application. We have secured the webserver's access and error logs which clearly show all attempted queries. The unfortunate thing is that the attacker had access to our database for approximately 3 days. As such, I think we must assume that our whole database has been mapped and most data of interest has been downloaded by the attacker.

At the time of discovery the attack was still ongoing; it has been stopped and the vulnerable WHERE clause has been replaced by a prepared statement placeholder (as it should have been all along). Given that the attack was still ongoing, I think I can assume they did not yet manage to get all data. After the vulnerability got fixed, we rotated the 'passwords'1 for all users that had access to this database server.

The data

The database in question is the datastore for a webshop. There is no payment information in the database (all payment transactions are handled by a (thirdpary) payment provider) and user passwords have been hashed with BCrypt with a quite decent workfactor.
The database does contain customer orders (along with address information), products, stock, etc.

Questions

The hole has been plugged, what technical2 steps should be taken now (other than rotating the MySQL user credentials, which we have already done)?
Since we have the log files with all query attempts, it should be possible to figure out exactly what tables have been dumped.
What is a viable tool for pulling this information from a combined 1 GB of webserver access and error log files?
What are the common malicious uses of stolen data such as this? Phishing attacks aimed at the webshop's customers?

1: 32 character long, printable ASCII, random strings.
2: There is definitely a judicial, communications and PR part to this issue, but this question focusses solely on the technical part of the incident.

1. The hole has been plugged, what technical steps should be taken now (other than rotating the MySQL user credentials, which we have already done)?

Audit the website. Preferably by someone outside the company if you have the budget. The search term you're looking for is "pentest". Furthermore, if your application displays any data stored in the database directly onto the website, check if the attacker opportunistically put some stored XSS in there. (Javascript to steal cleartext credentials for instance)

2. Since we have the log files with all query attempts, it should be possible to figure out exactly what tables have been dumped. What is a viable tool for pulling this information from a combined 1 GB of webserver access and error log files?

I'm not aware of such tool, sorry. You could always try and do it manually. Try and use any kind of scripting language (bash and command prompt will do for this) to recreate the executed queries from the log files. From there you can easily figure out what tables were accessed, it would be a lot of work to get more details in this matter though.

If you do this, look for insert and update statements, to see if he modified or added data as well.

3. What are the common malicious uses of stolen data such as this? Phishing attacks aimed at the webshop's customers?

It can be used for a few things. I'm assuming the list also contains email adresses? (webshops often do)

The attacker could try and use your data to compromise other accounts on other services. he could:

try and crack the passwords, and use these on other websites. Were the passwords salted? If not, he can try to use rainbow tables.
Use the information of your website to try and recover accounts on other websites without cracking the password. By using recovery questions.
Use the email addresses(if you stored them) for spam purposes. He can also just sell the email list.
phishing like you mentioned yourself


Can PKCS #11 object handles be used across sessions? The PKCS #11 2.40 spec is a little ambiguous in its description of whether an object handle retrieved using session A can be used in session B to the same token.

The main spec states (all emphasis below is mine):

  A particular object on a token does not necessarily have a handle which is fixed for the lifetime of the object; however, if a particular session can use a particular handle to access a particular object, then that session will continue to be able to use that handle to access that object as long as the session continues to exist, the object continues to exist, and the object continues to be accessible to the session.

While the usage guide states:

  Object handles are similar to session handles in the sense that visibility of a given object through an object handle is the same among all threads of a given application.

and also...

  Note that a Cryptoki implementation may or may not support separate spaces of handles for sessions and objects.

Finally, the usage guide includes a scenario, of which steps 16, 17 and 18 suggest you can use the same object handles. But the wording used is "the object associated with object handle 1", so it's not 100% clear that the handle was valid to use:

  A1 uses [A’s] session 4 to perform an object search operation to get a handle for O2.
  The search returns object handle 1....
  A1 attempts to use [A’s] session 4 to modify the object associated with [A’s] object
  handle 1. The attempt fails, because A’s session 4 is a R/O session, and is therefore
  incapable of modifying O2, which is a token object....
  A1 uses [A’s] session 7 to modify the object associated with [A’s] object handle 1.
  This time, since A’s session 7 is a R/W session, the attempt succeeds in modifying O2

Can anyone comment definitively on this topic? Or point to another part of the spec that unambiguously defines this?

Yes, object handles can be used across sessions.

Your first citation doesn't say anything about it. Its intention is to clarify that handles to the same (token) object can change between different invocations of an application, but as long as the application is running and a session exists it won't change.

The third citation clarifies that a handle casted to an int can appear both as session and object handle at the same time. Here in step 12, object handle 7 is returned but session handle 7 already exists. Kind of obvious.

Your second citation gets closer since the UG also says:

  Different threads of an application should never share sessions

But your fourth citation should make it clear since in step 16 handle 1 is returned for object O2 in session 4, and in step 18 this handle 1 is used in session 7 and in fact object O2 is modified!


Can a PDF embed a tracking image? I know that PDFs can contain embedded images and Javascript.

Can a PDF contain something that tracks you?  For instance, can it contain a remote image that, when the PDF is opened, will fetch that image (thus revealing the user's IP address)?  (Like a 1x1 image / web bug.)  Or, can the Javascript trigger a GET request to a server the PDF author controls, a fetch of a network resource, or a DNS lookup that would reveal anything about the identity of the user opening the PDF document?  Or maybe embedded Flash?

I can imagine this might exist if the user clicks through a warning, but can a PDF do this without triggering a warning to the user?

Can a PDF contain something that tracks you?

If you mean in the PDF file itself, and part of the PDF standard, and which does not require the user to click on something (like a link annotation), it would just be javascript. Which means in general, especially if javascript interpretation is off, then no a PDF can't track you.

Generally PDF DRM/tracking is done as combination of a PDF with proprietary data in it, combined with specific PDF reader to interpret that data.

  can it contain a remote image that, when the PDF is opened, will fetch that image

No, PDF does not support external images in the page content. You can have references to external resources, but these have nothing to do with displaying the PDF, and in general a PDF reader would not fetch that remote resource automatically, though a particular PDF reader application could do that.

  can the Javascript trigger a GET request to a server the PDF author controls, a fetch of a network resource, or a DNS lookup that would reveal anything about the identity of the user opening the PDF document?

The PDF itself would not do this, but a PDF reader with javascript enabled, might end up doing this automatically if such javascript existed in the PDF.

  Or maybe embedded Flash?
  Same as above, but I believe only Adobe products would do this. Would be a much smaller set of PDF readers that would have built-in flash support.

  I can imagine this might exist if the user clicks through a warning, but can a PDF do this without triggering a warning to the user?

The PDF file itself, no, but a PDF reader could certainly process the javascript in a PDF and may do this without warning the user. Would depend on how the PDF reader was written. PDF format supports javascript triggers on document opening and page opening actions for instance, so if a PDF reader was configured with javascript enabled, then potentially the PDF could trigger such a network request automatically without the user knowing.

So in the end it is possible, but completely depends on the application opening the PDF, what it's settings are, and what javascript API calls it supports.


Why crack WEP or WPA/WPA2 PSK when it can be sniffed through monitor mode capture? I am pretty new to the domain of wireless security and am trying to understand the various techniques used for compromising wireless networks. There are a few things that I am not able to correlate and need help understanding them.

(I understand that WEP is no longer recommended but I am just trying to understand some underlying concepts here.)

Why do I need to bother to BREAK the WEP or WPA keys (maybe using a tool like aircrack-ng)?

Can't I just de-authenticate a client (using aireplay-ng) and then present the client with a fake AP (impersonating a legitimate one) and then, when the client tries to reconnect to the AP, simply capture packets in monitor mode and sniff the key out from those?

In fact, is the fake AP even required here? I mean, even without hosting a fake AP, I could still sniff the PSK from a monitor mode capture (say using tools like Wireshark/Kismet/Cain etc.) - correct?

When we talk about PSK in case of WPA/WPA2, I understand that the PSK (the PMK and PTK finally) are used to encrypt all the data exchange. As per my understanding the PSK is not transmitted over the network by either the client or the AP during the connection/authentication process. It's just the initial nonce that is exchanged and thereafter it is the calculated PTK that is exchanged and it is the MIC that is used for verification. Is my understanding correct?
If my understanding of point 2 is correct, the 4-way handshake is not encrypted, correct? And this 4-way handshake can still be eavesdropped on (maybe through a monitor mode capture or using tools like Kismet/Wireshark/airodump-ng etc.) correct?

Please let me know if I am missing something and any pointers to references will also be helpful.

Your point 2 is a bit inaccurate. The PTK is never sent over the air in WPA; it is computed from the PMK, an AP nonce, a client nonce, the AP MAC address, and the client MAC address (this is "key exchange", but the PTK never gets transmitted). Without the PMK, an attacker who sniffs the data can't discover the PTK without doing a brute-force attack (essentially, the client sends a MAC with their nonce, using a key which is part of the PTK; the attacker tries various passphrases, computes PMK and PTK using those passphrases, and then verifies the MAC). So the attacker can sniff the handshake, but it doesn't really help them with things that aren't brute-force.

As to your point 1: The whole point of a PSK is that it authenticates both sides. If you don't know the PSK, then you can't know the PTK derived by the client. That means that your fake AP won't be able to impersonate the real one, because you can't decrypt the data the client sends you (and can't send a valid MAC on the GTK, so even initial association will fail). And, as mentioned, monitor mode doesn't help because the keys themselves are not transmitted over the air; all a handshake gives you is enough to try a brute-force, but it doesn't give you the keys directly.


SSL with GET and POST I'm pretty new to security, so forgive my basic question, but does SSL encrypt POST requests but not GET requests?

For instance, if I have two requests

GET:
www.mycoolsite.com/index?id=1&type=xyz

POST

site: www.mycoolsite.com/index
{
Params: id=1&type=xyz
}

Is it safe to assume that someone is able to intercept the whole GET request (reading id and type), but if they intercept the POST they will be able to see the site path, but because it is going over SSL, they cannot see the params of id and type?

Now, the question is, do you know what a HTTP request looks like?

Well, assuming not, here's an example of one:

GET /test?param1=hello&param2=world HTTP/1.1
Host: subdomain.test.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20100101 Firefox/10.0.1
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive

All of this information is enscapulated within the SSL transport - as the comment on your answer kindly says. This means:

Get parameters are encrypted.
HTTP Body (post parameters) are encrypted.

What's not necessarily secure:

The host you're asking for. Most web servers these days support Host: something parameters so multiple domains can be handled by one web server on one interface and IP address. Clearly, this header is encrypted, however, if you run non-https traffic to the site it should be clear which hosts you might connect to. Even if that's not the case, reverse DNS will certainly tell you what's hosted on that IP and you can probably make a reasonable guess from there.
Your browser/client information. Unfortunately each https client is different and its negotiation process might potentially give away what platform it runs on, or what browser it is. This is not the end of the world by any means, it's just a fact to understand.

POST requests look similar to get requests, except they contain a body. This may look like this:

POST /testpost HTTP/1.1
Host: subdomain.test.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20100101 Firefox/10.0.1
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive

param1=hello&param2=hello

There are some more complicated variants, of course, but essentially it is all encrypted anyway.


Physical security - responsible disclosure I recently discovered a way to bypass a commonly used security seal system, requiring no special equipment and taking only a matter of seconds. I feel obliged to disclose this, so as to avoid the possibility of users of that seal system harbouring a false sense of security.

I would use CERT's Vulnerability Reporting Form, but that is only intended for software vulnerabilities.

Is there an equivalent responsible disclosure system in place for the physical security industry?

First of all, set your expectations appropriately:

The physical security industry isn't quite like the information security industry. The probability that they don't already know everything you figured out is pretty slim. They may have even known about your technique before they went to market.

By assuming you have something novel, how do you realistically expect then to react? Would this mean simply retooling their process? Inventing a new sealing technique? Shutting down entire companies?

Physical security isn't perfect. It isn't even good. Not in comparison to what we have in IT. For example, lockpicking technique has been well understood for literally centuries, but most locks on the market today are still highly susceptible.

By going public you're guaranteed to make people mad on both sides. But the only way you can even hope to improve things is to present not just the problem, but also a commercially-viable solution. Then press the solution, not the problem.


Configure http honeypot on my ubuntu server I want to configure an http honeypot on my ubuntu server. I am using apache web server. I am thinking to set 80 port for the honeypot and some other unusual port like 8978 or 6723 for my site. I will redirect my domain on this port using proxypass so users who access my site using domain will still be able to access the site and attackers will end on honeypot.

I could not find a guide to install http honeypot on ubuntu just like they have ssh honeypot. Can you please help?

I will manage to redirect my site on other port internally using proxypass  without opening that port for outside world. Will this approach help? or should I use nginx reverse proxy server to manage this. If there are any loopholes in this process, please comment and suggest me better way.

Thank You.

EDITED
I have found this site to install ssh honeypot on ubuntu server
https://www.digitalocean.com/community/tutorials/how-to-install-kippo-an-ssh-honeypot-on-an-ubuntu-cloud-server

Similar way I was finding to install it for http.
Please help.

I think you're confused about what a honeypot is used for. The situation you described above isn't a honeypot at all, it's just a proxy that has non-standard configuration.
To set up an actual honeypot, you have a separate system (lacking some of your real defenses) that's supposed to be attacked and abused, thereby saving systems you care about from that treatment. So you can collect data on who/what/how is attacking you.


Check USB mouse for malicious code When I first used this mouse and keyboard, my PC died shortly after. Today I used it and it somehow corrupted my Linux.
I once put a clean Linux on a laptop and plugged this mouse in and left it, several times the laptop came out of sleep without being touched.
I have suspicions that it's effectively a "rubberducky" and delivering a payload.
Is there a way to determine the risk? Can I install hard or soft USB monitoring?
Here's a link to the mouse.

It is technically possible for a USB mouse to do something bad. But unlike a keyboard, a mouse can't easily control things on your computer since it can't see the screen to know where to click. To do something bad, it would have to turn in to a device such as a keyboard or other device with a driver that could be exploited.
Next time you'll have to capture your kernel message log and see if new USB devices were plugged in. For example, if your mouse changes in to a flash drive, you'll see the new device being recognized by the kernel in the logs.


What does a court need to successfully prosecute a hacker?  Please cite previous cases if possible Once a business decides it is worthwhile to persue legal action against the attacker, what information and processes should be followed so that:

Integrity of the investigation is maintained
The undesired behaviour will cease
The damage is properly assessed
The value of the damages will be reimbursed

What types of cases succeed?  What types of cases likely never see the light of day?

Is there a Law (or other) journal that covers these cases in any significant depth?

As I recall cyberlaw is pretty up in the air as it is a newer issue.  The biggest issue, at least in the US, is proving that it actually was that person behind the keyboard.  IPs can be spoofed, pseudonyms are just that pseudonyms, and intellectual property law is fairly unrefined as well.  Also the hacker needs to be an adult or have committed a crime on a large scale, this of course is up to court discretion.  Additionally one needs to consider is the user of the script to blame or the original developer?  You can look at cases against Limewire and other P2P networks.  I believe it really comes down to did the business take all necessary precautions to prevent this in addition to the attacker's intention.  The RIAA has looked foolish in the past by trying to prosecute 12 year olds on music theft.


What to review for server decommission? I’ve read that the information security teams should be involved in the decommission process for servers (for example this answer or this sample process guide).  They are supposed to review and approve the decom request.

What is infosec supposed to review exactly?  Are there specific things the security team should be doing when they see the request?  For example, should they be archiving off event logs or capturing other information for audit purposes?

Just trying to figure out what I’m not doing but should be when I blindly declare “Approved” on every request.

Lets say a few months from now your company has reason to believe that there is a malicious actor in the network that occurred through leveraging servers in cluster A. However, the actor has been in the network for a while and has established persistence in many areas. Unfortunately, you decommissioned cluster A last month and all the data is gone. Now there are no logs to see what the actor gained access to, how they got in, and where all they went from there. If only you had done a quick look over the system and saved the logs you could have figured out what other systems are compromised!

In other scenarios, based on the content of the VM servers, you may elect that the disk space needs to be zeroed to ensure that data is unrecoverable. Maybe there is an ongoing testing engagement or forensics investigation involving that server that is unknown to other teams that are ready to delete it.

There are various reasons a particular security team may want to review this process and companies may have more specific use cases but that is the general idea.


How can I protect myself from false accusations when our company practices password escrow? During an internship for a small company, my boss created an account for me, so I generated a password and I used it. The next day, my boss told me to write down the password of my account on a piece of paper, put it in a letter and to sign the envelope. Then he took the letter and told me that if he needs to access my account and I am unreachable, he is authorized to open the envelope and read the password to use it.

He also told me that this is a common practice in all companies. Now I don't know if every company does this (I don't think so) but, to me, it's not legal.

Let's say that my boss is a bad person (he's not) and he wants to frame me for something that he did. He only has to open the letter and read my password (let's say that I'm unreachable) and do his nefarious activity with my account.

Now let's say that I can't prove my innocence. How I can prevent all of this?
I thought of writing down a wrong password, but if he really needs my account and I'm unreachable, I'll put him in a bad situation.

So, is there a way to protect myself (without refusing to write down the password)?

That's what the envelope is (or should be) for: In order to use your password, one needs to break the seal of the envelope you signed. When you think your password was abused, you can ask to see the envelope with your signature and check if it is still unopened.

All you need to do is that should your management ever require your password, change the password and hand in a new envelope. You might want to change your password in regular intervals anyway: It's common best practice.

By the way: In companies with a proper IT management this method is unnecessary, because system administrators can receive any necessary information from user accounts without having to know the passwords of the user. If an administrator really needs to log into a user account, they would reset the password (which would create a verifiable audit trail). And there is usually more than one system administrator, so the admin accounts do not require this method either.


Does WhatsApp use certificate pinning? Does WhatsApp use certificate pinning? I found a post by Preatorian Security from February 2014 that points the lack of certificate pinning as a major security problem, and mentions:

  Update 02/21/2014: WhatsApp is actively working on adding SSL Pinning now

How can I investigate if they already implemented this feature on a given client? I'm interested in the Android and Mac (released yesterday) clients.

As far as I know, Whatsapp uses Certificate Pinning. When I tried to analyze the Android app in january, it didn't accept my forged certificates (created with mitmproxy). I didn't invesigate this further and I might have missed something.

However, Whatsapp upgraded its encryption algorithms earlier this year and introduced end-to-end encryption, and therefore messages are now better encrypted than it would ever be possible with TLS.


Photo vault security I moved pictures from my stock iOS photos app to an old photo vault app. I used my LTE to move the pictures and was wondering if whenever I opened the app on WiFi, if my school could potentially see all of the images moved there. I can move pictures from my stock photos app to the photo vault while on airplane mode so I don’t believe they are being uploaded anywhere else. I have also deleted the images in question from my phone and all clouds.

The app in question has been removed in the App Store and is pretty old but here’s a link about it:
https://appadvice.com/app/secret-calculator-photo-vault-lock-hide-pictures/470578793

I can move pictures from my stock photos app to the photo vault while on airplane mode so I don’t believe they are being uploaded anywhere else.

If you're not transfering your photos through your school's Wifi, they can't see something. Just be sure, this app doesn't do any background connections with their "cloud".

The question you actually need to consider -to prevent sniffing when transfering- is if this old photo vault app transfer the photos through HTTPS protocol. As the link didn't provide any usefull information about the security they're using, you can achieve that with one of most well known programs that analyze packets (eg. Wireshark). If it's using https; you're -propably- safe from sniffing.
(except all the other factors; where are they storing the photos, who got access, what kind of encryption etc.)

Your school can -and should- log the transfers and see where the connections are going or coming.


How to communicate securely What is the proper way for two parties, say A and B, to communicate securely where:

Communication between A and B must be secure so that only they know the content of the communication.
A isn't necessarily endangered if it is known that they communicate anonymously with 3rd parties.
Knowledge that B is communicating anonymously with a 3rd party would endanger B.

More specifically, lawyers needs to communicate with a client, the client cannot be known to be in communication with the lawyers.

Tl;dr: both using Tor via Whonix, share a single webmail account hosted by a Tor-facing .onion email provider, in which you communicate by putting pre-browser encrypted PGP messages in the body of unsent items in the Drafts folder (without ever sending it as an actual email), before quickly deleting each PGP message from the other party as you receive it.

Initial considerations...

A lot depends on your threat model - are you wanting to hide the communications (and knowledge of them), from the NSA, or from adversaries with less network surveillance and anti-encryption resources than that?

Let's assume it is a powerful NSA-level adversary, where you truly do want your lawyer-client communication to be both secure, AND secret.

For Internet communication, where it is between only two parties (and I assume it needs to be 'asynchronous', i.e. both parties are not connected to each other in real time online, i.e. usually email or other server-stored communication instead of instant messaging / P2P communication typically secured by OTR) and where, luckily, you don't need to share a publicly discoverable or broadcastable 'username', IM alias, or email address given there's only two parties that need to even know how to do this communication, then I would advise the following extremely anonymous, very secret, and highly secure setup for covert two-way communication:

Instructions

All parties use Tor. This is only one small part of the protection, specifically to very securely hide the IP addresses of you and your lawyers, but also, to use a Tor hidden service which will side-step the entire infrastructure of DNS itself and thus not leak what website you are using to communicate, to the NSA. (as end-to-end HTTPS server-client encryption does not hide the fact of you doing this, from the NSA.)
As for how to use Tor, rather than the simple Tor Browser on your (most likely) insecure Windows, OS X, or even default Linux system, I suggest doing this communication either using the Tails live boot OS, or, with longer setup but arguably better suitability for the way in which you will be securely communicating in this guide, Whonix. Graphical Linux is actually not that difficult to use, Whonix's particular chosen desktop (KDE) actually is quite similar to Windows in its interface. Whonix is a marvellous equivalent to Tails where it's not 'amnesic' like Tails but it is in the form of a Virtualbox-hosted VM, so you can securely store messages you receive from your lawyers OFFLINE on your computer and not leave them on the webmail server that you'll be using, and that will be crucal to this guide.
So, install Virtualbox, and download and install Whonix. This Tor OS works by having two VMs, the 'Gateway' VM to be the 'Torifier', then the 'Workstation' where you do the Tor browsing and communication in. It has the effect of NO IP address leak even being possible inside Whonix-Workstation due to its network interface being routed through the Whonix-Gateway VM, so even JavaScript or Flash could leak your real IP in Whonix - and yet, the VM is also instantly deletable when you need to as well. But still, please, disable JavaScript in Tor Browser once you are up to it.
So once Whonix is installed in Virtualbox (follow Whonix.org's excellent guides if need be, but it's all remarkably self-explanatory, make sure LUKS encryption is set up during the VM installation wizards) - and you get used to how it runs (you just thenm on at the same time (or better, in order), first wait for Gateway to set up its Tor connection, do its checks, do sudo apt-get update and sudo apt-get dist upgrade in Terminal if you need to, then once workstation is on and connected, same in there too), you are ready to move on to your super secret, lawyer-client communication.
Firstly, do NOT use the Tor browser for ANYTHING other than this exclusive lawyer communication on Tor (this applies to the lawyers too, obviously). Do not go to a SINGLE other website in Tor on Whonix. Even if your IP is hidden, that IP will still be correlated to ANYTHING else done in that same Tor session (and by that browser's unique or fairly linkable fingerprint), in the eyes of those running the Tor exit node, the NSA who's most likely listening somewhere along the path between your Tor exit node and the websites you'd connect to, or other malicious parties who have the ability to monitor or sniff.
The service we will be using for communication is a SINGLE webmail inbox (hosted on a Tor hidden service), that you SHARE with the lawyers and both log into with the same credentials (shared in person), and write PGP-encrypted messages in the DRAFTS folder - this will keep it ultra-private by never even having the communications leave the single webserver of the email host due to not actually sending emails (and involving other email servers and parties), at all.
It is crucial you pick a Tor webmail provider that you can log into the inbox only on a Tor .onion address. Consult this page to select and choose what looks good to you. Use one that can offer SquirrelMail login and not just Roundcube, as that way you won't need to turn on JavaScript in Tor Browser to do this. The reason to login exclusively on an .onion address, is for several anonymity and security reasons: again, you avoid DNS lookups taking place out there on the Internet and instead use Tor's highly encrypted/obfuscated hidden service protocol method of lookup instead, and you also avoid HTTPS MITM attacks by the Tor exit node, or anyone else between you and a DNS-hosted webmail address, who can, EVEN with HTTPS, potentially hijack the session (and easily systematically, not just as a targeted attack), to gain your login credentials, read the traffic and collect your PGP messages you'll be sending to each other, or even modify the pages and messages to absolutely anything they see fit.
To communicate your PGP messages in the least risky way possible, do the following: SHARE the same PGP key (ed.: unless it is better to have separate PGP keys? comments welcome), do NOT write your draft messages that you'll leave for each other INSIDE the browser, and encrypt your message content with the PGP client in in Whonix BEFORE pasting the encrypted blob into the webmail compose box each time you do it.
How to encrypt and decrypt the messages in Whonix: the easiest way is to use Whonix's pre-installed PGP client, KGpg, with its on the Desktop. If you use KGpg, first delete all Key Servers in Settings > Configure KGpg, so that no uploading of your key accidentally occurs at any time of your use of the program. To use, first setup up your key (Key > Generate Key Pair or Ctrl+N), securely share it and the passphrase with your lawyers (right click on the key in main window > Export Secret Key...), either in person or by some other non-Internet or -telephony means - UNLESS again it is better to have separate keys to each other, I am not sure - and then to encrypt for composing, or decrypt when reading, simply go to File > Open Editor and it is all easily done in there for either party once you have the key stored in KGpg.
To make the communication to each other practical in the drafts folder: good practice is to firstly, NOT leave ANY telling information outside the PGP blobs in the message body, and if you must differentiate between each other give the subjects or via a little text above each (new) blob, some random letter or number to indicate whether the blob was from you, or from your lawyers. Better than starting a new draft per new message, is just leaving a new PGP blob in one single draft, which is merely updated continually.
This is crucial: DELETE each PGP message from the other party in the webmail as soon as you receive and decrypt it in your PGP client. This means the communication is not stored on the webmail's servers to get leaked, hacked, modified, or otherwise breached for any longer than it needs to. Save any correspondance that needd to be kept for longer, locally in your (encrypted and secured) computer - (preferably within the Whonix installation with LUKS wholly inside the VM container file) - or even archived on an air-gapped, encrypted computer if need be.

Caveats

With this setup you have to trust the .onion-hosted email provider not to modify, make up, or erase any of the draft messages you leave for each other in your inbox on the server, and also not to leak any of it. Even with PGP, it is still data that could be decrypted later all the same.
If the NSA or another high-powered, global adversary were lucky, they be able to may de-anonymize your (or the lawyers') IP address via timing/traffic correlation attacks where they compare size of the packets being requested and sent between you and the webmail's server, IF they own (or have capability to directly sniff the traffic at) enough locations/nodes on the Tor network. However this particular form of de-anonymization (and especially if you are connecting to an .onion hidden service where, you actually avoid the need for a Tor exit node entirely), is extremely unlikely and requires enormous resources which appear only viable for them when trying to surveil someone they already know is a target, and not random Tor users, per se. But the random possibility, always exists.

However, I would advise a pre-Tor VPN connection to hide your 'real' IP as an extra precaution, even so. There are plenty of free VPNs around and I would advise no money to be involved so as to not involve financial trails to this communication in any way possible. Make sure you use a different free VPN to what the lawyers use at their pre-Tor end, as a correlation could be made otherwise. This also would be good for de-correlating the fact that both you and your particular lawyers (i.e. your real IP address and their real IP addresses), from the point of view of the NSA, even use Tor. VPNs are much more common than Tor, at this point in time anyway, and would distance suspicion between your real IPs and Tor even more. Obfs3 when connecting to Tor and also VPN obfuscation (especially with LEAP VPN technology) also can be put into use.

PGP, ordinarily, does not have perfect forward secrecy (like OTR, and TextSecure, do). This means if the encrypted blobs SOMEHOW leak at a later time, whether by a malicious webmail admin, via an unencrypted routine server backup, or if webmail provider turns out not to have the best opsec/server security and is hacked in general, is specifically targeted by NSA due to other high target communications taking place on the same server and then any messages you have still stored in your drafts folder are seized (which is why I urge you to delete them as soon as they are received), or you / your lawyers storing any messages are raided / equipment is stolen and things progress all the way to someone actually accessing your 'blobs', AND then you or your lawyers are forced to give up the (single) PGP password for your commuication (or additionally your opsec isn't as vigilant as it should be), then standard PGP will not save you from such a leak, and ALL your messages under the one key will be decrypted in one foul swoop.

I read somewhere that the PGP spec CAN include PFS key exchange, though do not know what client could be configured to do this. Someone feel free to edit this and give instructions (even in my main bullet-point guide, and then edit out this caveat), you'd be welcome.

Additionally, if someone knows of a simple, offline, portable, serverless, PFS-providing robust crypto implementation with a GUI that could replace a PGP client for communicating covert blobs in a scenario like this, that would be even better.


Two roots for an SSL certificate Please consider the following scenario:

I have an SSL end certificate issues by a well-known authority (e.g. COMODO).
I have my own self-signed root and intermediate certificates which are used by client applications (non web, use web APIs) to make SSL-based connections.

(1) is helpful to make browsers connect to server having no warnings (as root is known by browsers). (2) is better for security as applications only trust anything chained to my root certificate and no certificate/address spoofing is possible.

Is it possible to additionally sign (1) with my intermediate certificate so that clients of any kind can be used?  I have an alternative of hosting web components and APIs on separate hosts, but browser-based clients shall still need to reach APIs having (2) which ruins the whole idea.

TIA.

A bit of theory

Technically it is possible that single certificate may have multiple chains, however it is not your case.

Multiple chains can be produced when cross-certification, when CA server have two or more certificates signed by different issuers and all these certificates are installed in the client's store to build the chain.

This situation is common for Microsoft CA (ADCS), when you renew root CA certificate and reuse the key pair. In this case, root CA have two certificates with (optionally) different settings (for example, cert validity), but with the same subject and public key information. When client builds a chain it ends with two matching root certificates. It is up to client to select the right chain.

alternatively, foreign CA can sign your intermediate (or root) CA certificate and install this certificate to user's store. When client builds a chain, it can go through different intermediate CA certificates (signed by your and foreign roots) and depending on trust settings, client may elect the best chain through some logic.

A more sophisticated scenario of cross-certification is so-called Cross-Certification Bridge, which is helpful when multiple organizations run their own private PKIs and they want to establish a mutual trust between each organization.

To your question
As far as I understand, there are clients that do not trust Comodo, while trusting your private CAs? If this is correct, then you can do cross-certification. Sign Comodo's issuing CA with your internal CA and put this certificate to all clients who do not trust Comodo. In this case, when clients will build the chain, then they will get two chains: up to untrusted Comodo root and to your trusted private root. If the chain selection on clients is good, then they will select proper and trusted chain.

Unfortunately, I don't know how to do this in OpenSSL, however I would recommend to read Microsoft's whitepaper on the subject: Planning and Implementing Cross-Certification and Qualified Subordination Using Windows Server 2003
Here you will get detailed explanation about how cross-certification works.


Is it insecure to hash multiples times? Hashing multiple times (rounds) seems like a standard practice in password hashing to increase the work factor.

Surely, everyone will agree increasing the work factor to compute the password hash is a good thing but I was wondering if we were not reducing the random factor of the hash at the same time.

My theory

Let's take an hash with a n-bits output.

Is it possible that you will never obtain some of the n-bits possible values when you input every possible n-bits possible values?

This would mean that some hash values are more likely than others since they can be obtained from multiple entry values. It also means that the hash function is creating subcycle which can be very bad.

My test

I wanted to check if my theory had some merits but, obviously, I didn't have the computing power necessary to analyze a real hash function so I created a simplistic one.

My function output the first 8 bits of SHA512.

I then input every possible 8 bits values into this function and saved the results.

Definitions

Root : An 8 bit value that you never get
Path : All the possible values that you can obtain for single entry if you hash multiple times
Cycle : Values that repeat themselves when you hash multiple times

The results

Number of Roots : 97
Longest Path : 36
Average Path Length : 17.21
Number of Cycle : 5
Longest Cycle : 6
Number of values in the Cycles : 13
Longest Path without cycle values : 30
Average Path Length without cycle values : 11.72

An alarming conclusion

These results mean that if you hash one time you have 159 possibilities, but if you hash 30 times you only have 13 possibilities left.

Other tests

I added a salt that I prepended to the value on every round. I thought that it might make a difference but I obtain quasi similar results with different salt value.

My questions

I know that my experiment is over simplified but :

Is it possible that hashing multiple times reduce the security of a hash function if you hash too many times?
Is there any studies done on this subject?

See this question for details. Roughly speaking, when iterating a hash function in a space of size N, then, after an average of roughly sqrt(N) steps, you enter a cycle whose length is of size roughly sqrt(N). With a, say, 160-bit hash function (e.g. SHA-1), both sizes will be about 280, i.e. way too large for problems to actually occur.


How to stop JS from executing when passed in as a parameter to the URL? (no script tags) I needed to stop an XSS attack from happening when the payload is inserted into the URL as a parameter. In this case though, there are no script tags. This is my URL which causes an XSS attack:

  localhost/example/file.jsp?testParm1=');alert(1);('&testParm2=');alert(1);('

When I hit enter after typing this into my browser, an alert dialog saying "1" popped up. When I clicked "OK" on that, the alert dialog saying "2" came up.

I am using JSP's, so in file.jsp, I grab those parameters I passed in:

<%
   // Get url parameters
   String lTestParm1 = myObj.retrieveString( "testParm1" );
   String lTestParm2 = myObj.retrieveString( "testParm2" );
%>

Usually for XSS prevention I would escape the special characters so it wouldn't run whatever is in the parameter as javascript (for example if I put testParm1=<script>alert('hey')</script> into the URL), but I can't do that since there are no script tags.

Now in the JS portion of the code also in file.jsp:

<script language="JavaScript" type="text/javascript">

    var lWindow = popUp( '<%= lTestParm1 %>');    // I think it is happening here

    <custom_tag:If condition="<%= lTestParm2 == null %>">
        // Do something
    </custom_tag:If>
    <custom_tag:Else>
        window.location.replace( '<%= lTestParm2 %>' );    // And possibly here
    </custom_tag:Else>

</script>

I put a couple comments beside the 2 lines where I think the problem is.

To try and stop this XSS attack, I replaced each apostrophe with 2 apostrophe's in the URL. This seemed to work for this case.

I couldn't find any other articles/questions relating to this problem, but I did find similarities with SQL injection apostrophe replacement questions. They said that there are still many ways to get past apostrophe replacement by itself.

Here's a link to one of the questions: https://stackoverflow.com/questions/15537368/how-can-sanitation-that-escapes-single-quotes-be-defeated-by-sql-injection-in-sq

This made me wonder if my solution is sufficient enough, or if there are still ways to perform an XSS attack even with my apostrophe replacement in place.

One good way of dealing with this would be to replace all special characters (specifically the following 6 #/'();) with their HTML character entity equivalents. It will visually appear the same but javascript will not recognise it as that character.

The main examples.

# becomes &num;
/ becomes &sol;
' becomes &apos;
( becomes &lpar;
) becomes &rpar;
; becomes &semi;

You can see more HTML references here: https://dev.w3.org/html5/html-author/charref

edit1:
Also, filter out the URL encoded versions as these will be converted to the ASCII equivilant on hitting the server but perhaps after you replace them. it depends on when you validate. You should also limit the length of the input, as this can make XSS less effective if you accidentally let something through. If avoidable, don't reflect inputs into javascript.

edit2: You could even get a library to encode the entire string into the HTML character entity equivalents. Probably the easiest.


Is there a way to execute XSS in an HTML img tag with SVG? Is there a working technique to execute XSS in modern browsers using a SVG file displayed on a web page with an <img src=""> tag?

I know a way to execute without <script> tag, but I don't know how to load a file using SVG or anything else, because XML breaks when I try using different tags to get my XSS working.

Is this actually possible?

No, it's not. Although SVG files can contain JS (see this), these will only get executed if:

the user directly visits the .svg file in their browser
the image is embedded within <embed> tags.

Modern browsers will never execute scripts in SVGs if it's within <img> tags.

And even in the two cases above, the server can provide CSP headers that stop the execution of such scripts.


Trying to do a chunked multipart post request, nginx and php both returns 400 error I'm trying to use chunked protocol and multipart protocol in a POST request, like this

All new-line symbols are \r\n, e.g

POST http://127.0.0.1/print.php?a=1&b=2 HTTP/1.1
accept-language: *
transfer-encoding: chunked
accept: */*
user-agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2228.0 Safari/537.36
host: 127.0.0.1
content-type: multipart/form-data; boundary=test123;

4B
--test123
Content-Disposition: form-data; name="xxx"

123
--test123--

0

But, when I post this request to a PHP server it returns 400 error, which means this is an invalid request.

Any ideas? I'm simply testing a WAF bypass method

While transfer-encoding chunked is defined for both response and request in the HTTP/1.1 standard (but not in HTTP/1.0) it is typically only used for responses. It is not universally supported for requests.

Apart from that your first line should only include the path and not the full URL. While HTTP/1.1 (contrary to HTTP/1.0) explicitly allowed the full URL in this place lots of servers don't accept this.


Are the elliptical curves in ECDHE and ECDSA the same? ECDHE is quite widely used and recommend. And it works with elliptical keys and provides forward secrecy. It's used for the key exchange.

ECDSA is not widely used though, but it does also use elliptical keys. It it used for authentication the server via (TLS) certificates.

More information about the differences here: ECDSA vs ECDH vs Ed25519 vs Curve25519

However regarding the usage in browsers is there any difference between the curves used in ECDHE and ECDSA?
Do browsers support the same curves for every elliptical curves algorithm? Do they possibly even always used the same curve for ECDHE and ECDSA in TLS_ECDHE_ECDSA?

However regarding the usage in browsers is there any difference between the curves used in ECDHE and ECDSA?

No, there probably is not. As the key establishment and certificate verification is likely to be in the same crypto API it is pretty likely that the same curves are supported (or not).

  Do browsers support the same curves for every elliptical curves algorithm?

That's pretty likely because of the same reasons.

  Do they possibly even always used the same curve for ECDHE and ECDSA in TLS_ECDHE_ECDSA?

The curve for the ECDSA part depends on the certificate used. The key in the certificate is static while the ECDH keys are ephemeral. So it is likely that shorter curves are used for ECDH than ECDSA. There is not a direct connection between the two in the protocol, so although the same curve may be used, it is certainly not a given.


How do I track bash history cleanup? I'd like to catch events when bash history is cleaned or some lines are deleted. Are there any best practices or auditing tools with this capability?

Monitoring the Bash history is easily done with a shell script, but just checking it for unexpected changes might not be an effective security measure but rather clutter your logs with false-positives.

One obvious way to monitor file system events associated with your .bash_history file would be by using the inotify API. E.g., this triggers on file modification events:

$ inotifywait -m -e modify ~/.bash_history

You could then compare the contents each time to determine changes, or just compare the number of lines to detect if entries have been deleted with a smaller overhead. (Just checking the file size won't work if the history has reached its maximum length and old entries are dropped.)

But note that it's trivial for an attacker to work around that. You have to expect that any reasonably skilled intruder immediately disables the history, rather than removing suspicious entries afterwards. Also, there are many cheap ways to bypass Bash entirely without provoking log entries (change to Bourne shell, execute from within vi, etc.).

Generally, I'd consider monitoring the Bash history for possible tampering too unreliable and error-prone to be a useful security measure. Instead, I'd first make sure to cover the logs where it's easier to identify security-relevant incidents (/var/log/auth.log, etc.).


Non-Sensitive/Non-Critical Database and Web server protections? I have an unrestricted DMZ that is currently set up with a non-critical/non-sensitive web server and database server inside. The database server gets interfaces from two critical systems but does not store any critical information. I am thinking that the database server should, at minimum, be behind a 2nd firewall. The DMZ should look like this:

Internet--Firewall--dmz--webserver--firewall--database server--LAN--Interfaces

Is this correct or am I over doing and over thinking the protection it needs?  Also, should the connection to the web server, database server, and the database server's interfaces be SSL or would it just be SSL between the database server and it's interfaces? I'm always of a mind that more protection is better but am receiving pushback on this and I just want a neutral opinion.

The non-critical database server doesn't necessarily need to be behind a second firewall, but it is recommended it reside in a separate DMZ, or a separate VLAN within the same DMZ (with ACL's in place) at a bare minimum.

If I'm understanding your explanation correctly, it sounds like the non-critical database server in the DMZ is connected via ODBC to the critical database servers on the LAN?

Which side is permitted to initiate communication through the firewall?

If the non-critical database server is allowed to initiate communication to the critical database servers on the LAN (to pull data), this is very bad.

If the critical database servers on the LAN are initiating communication to the non-critical database server (to push data) this is more preferred.

Without knowing the intimate details, I'm questioning why this non-critical database server needs to interface with critical database servers if it does not store any sensitive data?

Things to keep in mind:

If this non sensitive web application is vulnerable to SQL injection, the non-critical database will be compromised.

If the web server is compromised by vulnerability XYZ, it can be used as an attack point for the non-critical database server.


Know certificate signing algorithm of a remote site using OpenSSL I have been trying to know the "Certificate Signing Algorithm" ( SHA1 with RSA etc.) using openssl.

To start with I tried to see the cerificate using following command, but it also does not show up any signning algorithm details.

echo | openssl s_client -showcerts -connect <myhost>:443

Is there a way I can know it using a single command ?

Pipe the output from openssl s_client (which includes the cert in PEM-format) into openssl x509 -noout -text and it gives a human-readable display of the cert fields, including the signing algo (in two places). You don't need the sed -n /BEGIN/,/END/p step; most OpenSSL operations on PEM-format data, including this one, ignore "extra" data outside the PEM block. (This is NOT true for many other programs though.) -showcerts is useless in this case, since only the first cert, which is the server cert, is displayed.

To be exact, this is the signing algo used on the server's cert by the CA who issued the cert. It isn't performed or even directly controlled by the server.

If you want to look at the whole chain not just the server cert, you do need -showcerts and you need to run openssl x509 ... separately on each cert; a simple but somewhat crude way is

echo | openssl s_client ... | \
awk 'BEGIN{p="openssl x509 -noout -text"} {print |p} /-----END/{close(p)}'


Secure way to store application settings What is a proper or, if possible to tell, the best way to store configuration in matters of security?

So far I can tell that a database with very restricted access is a good way, but please let's exclude the database for the moment. I'm talking about things like encrypted properties files. As this is already a suggestion, I would also like to know about something like common mistakes or things I definitely have to keep in mind to acquire a secure configuration. There are already related discussions on "the best way to store configuration", however I wasn't able to find something with focus on security.

The application runs non-distributed on a host-machine, so the configuration is stored on local system. The application is, so to say, a single user application. We are talking about something like a software-firewall to be concrete. I'm actually thinking of application-scoped settings. I need data protection in a sense of privacy (I don't want to expose functionality and configuration) and integrity. I'm not afraid of an insider (admin) but more of intruders.

I already asked this question on stackoverflow but I think it is more appropriate to ask it here. I will delete the stackoverflow post in timely manner.

Ok, so if a hacker gets into your system you want prevent him to seeing the configs? By the logic, IMO this is not possible. The application needs to read the config and it needs to store the config values in the memory. The hacker with root privileges can always dump the memory and reconstruct the config (if the application is running).

However, you can make it harder for him. For instance, you can keep the config encrypted. The application would ask for the password on startup and use the password to decrypt the config. However, I can imagine, this could be quite annoying for sysadmins ;-)


Is there any benefit to using a salt when the cleartext is random data? I understand that using a salt makes it harder to find cleartext using rainbow tables - but in that scenario the clear text is structured / low entropy. If my clear text is generated randomly, then is there any benefit to using a salt?

The problem I am trying to solve is that of encrypting http session data serverside. I don't want to persist the decryption key on the server, hence currently I am storing separate cookies for the session identifier and the encryption key at the client. But it occurred to me that if I just stored a single value (the decryption key) at the client, then use the hash of that key as the session identifier, then (in principle) the key cannot be derived from the information stored at the server.

Assuming the encryption keys will never be duplicated across multiple users - which I should hope won't happen - then salting is not required for your specific attack scenario.

With that said, the scenario you describe has the users sending the decryption key to the server with every request they make. If the data must be stored server-side and you only care about it being encrypted at rest, that works - somebody who does something like steal a backup of all the session data won't be able to decrypt it - but it's fragile. An attacker who gets access to the running server or to a user's network traffic would be able to steal the decryption keys and use them. I don't know enough about your use case to design a system that would definitely work better, but it's worth considering whether it's acceptable to you that your user's data is trivially decryptable as far as the server process is concerned.


How DNS blacklisting works? Let's say we have this network setup:

PC > Firewall > DNS Server

I was under the impression that the PC would attempt to access the DNS server but the firewall would instantly block the request because it has noticed that the domain being requested is in its blacklist.

Reading online however, it seems the initial request to the DNS server is actually allowed but when the DNS server returns the IP address of the domain, it's blocked and unable to reach the PC.

Why is it done like this or was I right initially and have completely misunderstood something?

It is usually not the case that the DNS request is simply blocked but instead the firewall (or even ISP) will try to send a valid DNS response back so that the client quickly gets back that the domain does not exist or that it resolves to server which shows a warning message about blocked access.

To do this the firewall need to somehow intercept the original DNS request. Since most clients simply use the DNS server provided by the firewall anyway directly or indirectly (i.e. firewall is the central DNS server for resolving IP external domains) it is often sufficient to just configure the server to return a response configured by the ISP instead of the real response. For clients which explicitly use different DNS servers any access to some site port 53 (i.e. DNS) could be intercepted and forwarded to the firewalls DNS server which then again sends the faked response.


Treatment of Database as a Service in Asset Registry I have a Relational Database (DB) that is hosted by a cloud provider in my asset registry to be used for ISO27001 certification.This implies everything is maintained by the cloud provider, e.g. networking, patching, scaling, except stuff I would like to apply such as encryption, access controls etc. I have access to the DB via an API and I handle it as a service only.

When I perform risk assessment on an item like this, do I list all possible DB related threats and vulnerabilities and say they are covered by SLA or I just mention the ones that I have the responsibility for?

It would be helpful to list the database related threats and vulnerabilities. This way you can be sure that they are actually covered by SLA. This could be cross-audited under A.15 supplier relationships & A.9 access control.
The risk treatment may well be handled under SLA but you are still the risk owner unless that has been very clearly transferred to (& accepted by) the hosting partner.


How to Get and Set Digital Signatures with FDA 21 CFR Part 11 Standards How do I get and set digital signatures with the 21 CFR part 11 standards as defined by the Food&Drug Administration of the USA?

Reading the regulations themselves is a big start there. I'd also look at the most recent guidance that I've found. As I quickly interpret it, these aren't digital signatures in the way that most of us are familiar with. Rather, they are fields on data set by a controlled process which requires authentication, creates audit logs, and is under appropriate controls.

I'd implement something like that with a table that links signatures to document ids and records all entries with sequential numbering.

Beyond that, you're probably into needing to pay for consulting work.