Pentesting - best bang for your buck? (credentialed versus non-credentialed)

It depends what your goals are. If the goal is to find as many vulnerabilities and risks as possible, white box is the best approach. If the goal is "What can an attacker do given X amount of time to my application", then black box is the best approach.

We perform both at our clients and the main difference on when they want what generally depends on what type of resilience they are testing. The white box approach is what we commonly will do for continious and structured testing of applications. The goal here is not to find a single vulnerability and then close shop once you have pawned their systems. It is to provide as much coverage as possible and discover as many vulnerabilities as possible, going from good practice (CSP and HSTS headers) to proper vulnerabilities like XSS.

The latter we use more during engagements where the client wants to test their incident response or detection capability. The focus is on getting in by any means nescessary using any information found in the wild.

In the end it also comes down with what type of client you are dealing, but is also your job to inform your clients about the reason why they need this type of testing. I always tell them that if it is a first time thing the chances are we will discover a lot of things. It's important to make them and their management understand this is not a bad thing and that it is something they can use as an opportunity to improve or request more budgetting to attract more people with security related skills. The client still decides, you can inform them on what you suggest they need, but if they have made up their mind you need to respect that as well, it's their money after all.


CMP - Simply get certificate, knowing some information

There is no obvious standard for retrieving already generated certificiates using CMP. In RFC4120 there is the PKI Information Request, https://tools.ietf.org/html/rfc4210#section-6.5, but this is rather generically described without standardized methods for getting this information.
EJBCA does not support retrieving this information through CMP.


From the cryptographic side of things, one big topic these days is side channel attacks: attackers try to extract information on private values in a given system by observing side effects such as power consumption, precise timing... A synthetic view of such attacks is that there are two distinct "worlds":

the "abstract world" in which a system receives inputs as sequences of 0 and 1, and outputs similar sequences;
the "physical world" in which computation takes place within measurable constraints such as computation time.

Side-channel attacks are about exploiting the differences between these two worlds.

The cloud is an attempt at disbelieving this difference. With the cloud, you get virtual machines under the assumption that they are indistinguishable as physical ones, since they compute the same things. Indeed, a VM will respond with the same sequences of 0 and 1 for the same inputs, so in the abstract world, a VM is a perfect emulation of a physical machine. But if we take notice of physical details, some problems arise. In particular the two following:

For many cryptographic protocols, there is a need for randomness. Randomness is extracted from physical elements. With a VM, the "physical" elements are emulated. A consequence is that a PRNG within a VM may be of suboptimal quality.

Typically, consider what happens if you take a snapshot of a live VM, and (later on) restore that snapshot: it is quite possible that the VM's PRNG will output the exact same sequence of random values that it did the first time, which can lead to severe security issues. An extreme example is the generation of the "k" value in DSA and ECDSA signatures: reusing the same k for two signatures (on distinct messages) reveals the private key (see this answer).
A VM run on some hardware, and that hardware may host several VM simultaneously. These VM share the same resources, in particular caches. This allows for cross-VM cache timing attacks.

This has been recently demonstrated in lab conditions: the researchers managed to pull off a cache timing attack on some AES implementations, allowing a VM to guess an AES encryption key used in another VM which just happened to run on the same hardware.

Side-channel attacks on cryptographic algorithms do not exhaust the vast well of security issues related to cloud computing, but they are still a fertile investigation field, and are enough to warrant a cautionary warning: you really really do not want to see your VM run on the same hardware than the VM from your competitors.


Why is Facebook planning to drop support for SHA-1 encrypted sites, when they themselves use a SHA-1 certificate?

From the first paragraph of the link you've provided:

  As a result, apps that don't support SHA-2 certificate signatures will no longer be able to connect to Facebook starting on October 1, 2015.

I would read this differently to your interpretation. This is not a requirement to the apps to have certificates signed with SHA-2 but it is a requirement to support SHA-2 signatures. This is probably because facebook is moving to SHA-2. And if the certificate for facebook is signed by SHA-2 apps which don't support this algorithm will not be able to validate the certificate and will thus (hopefully) fail.

If you look at the certificate of facebook you will see that it expires at 15/10/15. This means that they will have a new certificate after that date and I guess this will be signed with SHA-2 which is the reason they require apps to update now.


How can the Equation Group HDD firmware malware help bypass FDE?

This is equivalent to an evil maid attack, which compromises the (unencrypted) bootloader to capture your FDE password the next time you start your computer.

This assumes the bootloader is kept on the same drive. If that's not the case (for example if you keep your bootloader on a removable drive) and you explicitly configure your computer to not boot from the main hard drive (as to not execute potentially malicious code planted on it) then this attack won't work.

By default, with both LUKS and Bitlocker, a small part of the drive is kept unencrypted and the FDE-aware bootloader lives there and is executed on each boot; so the drive does more than safekeeping the encrypted bits. A TPM could help mitigate that by verifying the integrity (hashes) of the bootloader before giving out the keys, and Bitlocker takes advantage of that by default. For LUKS, there is no official support for TPM but some solutions exist like TrustedGRUB (for actually extending the chain of trust) and tpm-luks for saving and retrieving the LUKS key from the TPM.


Use TLS certificate as both server and client?

This scheme is often used for sendmail (MTA) and OpenVPN. It is decent, and I have until now only found one pitfall:

On the/each server, you have to carry a whitelist for:

the allowed CA (possibly, but doesn't hurt)
the allowed clients

How to specify the clients is up to the specific software. I'd recommend specifying their CN (commonName) and requiring that the presented cert is ① otherwise good and ② signed by the CA specified.

I'm implementing SSL client certificate-based SMTP relaying with this (beats SASL any time of the day, IMHO: the mailers (MUA) send to localhost, and localhost uses their (official) cert to connect the the smarthost, which uses that cert to permit relaying). OpenVPN setups with this are not very common (most people just whitelist one hand-made CA and permit all certs signed by it) but still in use (i.e. not rare either).


SQL field level encryption, how safe is it?

If you are interested in using column level encryption in SQL Server 2005 and higher I have a bunch of sample code of how to use the built in encryption features in SQL Server to secure sensitive data.  The code is all available at http://sqlcrypto.codeplex.com/

In the code I show how to encrypt sensitive data and ensure that only authorized users can decrypt it.  I take advantage of the built in key management functionality and have strong randomly generated symmetric AES key managed by the database engine and those AES keys are then secured with certificates.  Database roles control who has access to which keys and with the built in SQL Server encryption you can even use passphrases to additionally secure keys or certificates so that you don't even have to trust your DBA if the data is that highly sensitive.  Having said that, if you don't trust your DBA then you have other problems :)

Since SQL Server does the right things with encryption (ensuring unique IVs) you cannot search encrypted columns without doing a table scan and decrypting every row to see if there is a match. I provide some sample code for building an HMAC of encrypted data so that you can at least do a basic search without leaking cleartext information.

I also have examples of how to store salted, stretched hashes of passwords using both the built in hashing algorithms (which are insufficient for production use) and a SQLCLR implementation of the bCrypt hashing algorithm for much better password storage.

There is also some sample code to show the use of transparent data encryption to encrypt the full contents of your data and log files on disk.

Some of the advantages to using the built in encryption are:

Great key management, the server does the right thing when generating encryption keys and uses multiple levels of encryption to protect the keys
Correct encryption the server ensures that every piece of data is encrypted with a nonce IV every time it is written, that means that someone cannot look at two encrypted values and determine that they are identical cleartext values.
Optional integrity checking of encrypted columns to ensure that someone cannot just overwrite an encrypted value with another encrypted value
Portability, you can access your data from multiple platforms without having to deal with headaches of differences in the platform implementations working differently.
Good data at rest security, the encryption is done before any log or data pages are written to disk so any data logged does not contain cleartext.
Ability to easily follow the principle of least privilege and only grant access to encryption keys to roles and/or users who require them.


How do I protect myself against the attacks in this php script?

What was uploaded is a popular shell script - a common post exploitation method.
The one you got seems like it is of the C99 variety.

In short, its a script that gives the attacker a control panel to your server, so that he can execute commands, download and install malicious things, find files with passwords, further infect the system, launch other attacks and other.

OsCommerce recently had a very severe RFI vulnerability allowing exactly these things to be uploaded, and that is probably how you got it - there are automated tools looking for the vulnerability and exploiting it.

Your system is no longer safe: The attacker might have downloaded rootkits or he may have created a second backdoor on your machine so deleteting the file won't suffice.

The ideal solution is to perform a full wipe and restore anything you want from backups - that is, if you trust your backups are clean.

If you can't do that, you have to do a full investigation of the server, but you can never be sure.

As for you question: There's no point enumerating the different attacks the script contains, as it provides basically a command line to your server and the attacker could run any command he wants or download any tools he needs. It just has some preconfigured functionality for his convenience.


OSSEC New Install: Scan and analyse full log?

I'm not certain it will automatically, as its core purpose is real-time alerting and active response.

In saying that, you can run manual log analysis on any log file. The instructions at http://ossec-docs.readthedocs.org/en/latest/programs/ossec-logtest.html give guidance on configuring log analysis. You just need to provide the name of the file to be monitored.  For example:

# cat /var/log/access.log | /var/ossec/bin/ossec-logtest -a


This would depend on the e-mail server that you're connecting to as opposed to being a function of the Mobile Phone operating system.

The (old) default was to send outgoing mail over port 25/TCP using the SMTP protocol.  Traffic over this port is, by default, unencrypted.

Many modern e-mail services do not make use of this port and instead will use an encrypted version of SMTP over port 465/TCP or 587/TCP (more info. here)

If the encrypted version is used then someone on a wi-fi network would not be able to see your traffic without additional measures to defeat the encryption (which are much more complex than simple traffic sniffing)


Extract smartcard certificate for server to server authentication

It's impossible for me extract the private key from the smart card, of course, so I don't know if this is possible or not.

It is not possible, because the private key cannot be extracted from the smartcard.

  So, I suppose I have only the public part of the certificate.

Yes that is exactly that. The certificate transmitted to the server by the SSL/TLS protocol does not contain the private key.

  There is something I can do to login remotely?

The common way is that the first server signs the request with its own certificate (that will be controlled on second server) and passes the client certificate in a custom header. You build a trust chain that way:

client authenticates to first server with its certificate signed by a CA - first server trusts the CA and through it trusts the client certificate
first server authenticates to second server with a server certificate. The second server trusts the certificate and then trusts the client certificate passed in the request

After the edit, what you describe is a serious MITM attack: you want to manage the data exchanged on a secure connection. If you could do want you want, your server would be able to submit any request on behalf of the user, while the request would be authenticated with the user certificate said differently a strong authentication including non repudiation. That is exactly what smartcard certificates prevent! The best you can do is to contact the ministry to explain that you would like to provide a service above this data, and asking what they propose. If they agree they will be able to adapt the authentication system to allow value added providers, if they do not, I'm afraid that your project will not be possible. And even with client side code, you should considere the legal consequences.


What is the difference between Digital certification revocation and retiring?

I would think this might have to do with what flag is used to mark the cert when it is added to the revocation list. A cert added with reason 4(superseded) or reason 5(cessationOfOperation) are not being revoked because of some compromise or inherent flaw so could be considered to be "retired".

There have been several types of certs(sha1 and MD5) that are signed with insecure hashes that are being phased out or "retired" as well.

https://en.wikipedia.org/wiki/Revocation_list


How AV software makes sure quarantined files never get executed?

There are a couple ways an antivirus program might go about preventing the execution of a quarantined file:

Hold it open for exclusive access. It can simply use the normal CreateFile API and pass zero for dwShareMode, preventing all other kinds of access to the file. If an executable can't be read, it can't be executed. Since antivirus programs are usually one of the first things to start, they can reopen all such files when the system reboots.
Use Software Restriction Policies. When the antivirus program is installed, it could create an SRP that blocks the execution of programs in the quarantine directory.
Hook a function that's critical for the creation of a process. Process starting always involves NtCreateSection, so the antivirus program's kernel-mode driver could hook that and determine whether the file in question is an executable and check whether PAGE_EXECUTE is requested.

Of these, only the first is useful for non-programs (e.g. documents that may contain exploits). To keep an eye on all file loads, the antivirus program could hook NtCreateFile, since no files can be read without invoking that. Alternatively, to watch for the marking of pages as executable, it could hook NtProtectVirtualMemory. Either way, the kernel-mode driver could look around a bit at what's going on in userspace before allowing the operation to proceed.

The easiest solution, however, would be to encrypt the quarantined files with a key that's not stored on disk. With such a system, the user would have to type a password to decrypt and un-quarantine the files. This could be accomplished fairly easily with some asymmetric-key cryptography.


As a Developer

Unless your APP 1 is built to be federation service, you shouldn't be extending APP1 to act as a federation service. This is just bad software design.

If APP2 lacks authentication and authorizations, you should, logically just add that into the application. It can be a SSO method but make sure it's authenticating with a Service Designed to do Authentication/Authorizations.

If APP1 and APP2 have nothing to do with one another (which sounds like it) than DON'T CREATE A DEPENDENCY VIA AUTHENTICATION.

As a Security Professional

To Answer you questions:

This depends on your risks and how important these applications are to the organization. You might want to re-read about JWT's. In order to verify a token, you need the secret, and in your design APP1 has it, and you either need to have it also on APP2 (exposing more risk) or rely on APP1 to verify the token at which point you need to ask yourself "Why would APP 1 care whether the token for APP 2 is valid?" The answer is because you built an unnecessary dependency for APP 1 to be responsible for APP 2's safety.
By the nature of tokens, you don't handle them client side, if a token is not refreshed it expires, it's no good, you should be denying it.  A refresh token is used for generating a new auth token once it's expiration is hit. A 30 min refresh token means that after 30min you need to fully re-authenticate. If that was your goal, than have no refresh and 30 min auth tokens.
The purpose of a token system is to remove state from your application. If you are going to be doing sessions, than do sessions and ignore tokens. If you want to do One-Time-Passwords, for APP 2 Authentication, than do OTP, it's horrible to both because to you have all the risks of both and no good reason for both. I would read up on sessions vs token authentication.

My opinion of this based on your question -- It will be a security management, IT management, and Dev Management nightmare have an independent app relying on another independent app for authentication services.

I am sure there is more to the story, but if I was doing decision making on this, there would be a lot of "would you explain to me why this makes sense?" comments.


Running the code through a URL decoder, you can see that it is a simple Javascript and not a specific 'virus'.

What you are seeing is not the actions or the result of the initial exploitation. You cannot determine the attack vector from the results. They got in through 'some means' and wrote to files on your file system. That means a code review might not reveal anything. That also means your solution might not be found in your code.

How did they get in? Maybe code vulnerability, SQLi, ssh brute force, FTP, server OS vulnerability, service vulnerability, 3rd party uploaded code, infection on your machine through attachment or browser vulnerability, aliens, physical access, perhaps you have multiple personalities and your 'alters' didn't tell you they rewrote your code. HOW they got in is the last problem you have right now.

Your first problem right now is that someone is in control of your server. Copy the logs, shutdown, reinstall, patch, change passwords, set up additional monitoring, and THEN do code review to look for vulnerabilities.


Using one-time-pads require list of used ones?

A one time pad is just a random secret key which is used to encrypt some text in the same size of the key. There is no need to remember which one time pad got used if you just destroy it after use. There is no need to keep it since you've already used it once for encryption.


How come keys can stay secure through factorization of primes

There are around 10^305 eligible primes for 2048 bit key (1024-bit long primes, as given by the prime counting function approximation), so the total combination count(p*q) is around 10^610. Each key is 2048 bits long, so the whole key space is 10^613 bits. Or 10^562 petabytes of data. This is an impossibly large number of keys, number of atoms in the universe is 10^80.

So no, enumerating this keyspace is out of the question. RSA is weak to quantum implementation of Shor’s algorithm, but we haven’t built a quantum computer big enough for cracking even 10-bit RSA keys.


Is the CN field on an SSL cert a secure form of authentication?

If the CN (or other parts of the certificate like SAN) is usable for authentication depends on how much you can trust the one who put the CN there to properly verify the value. For example with a self-signed certificates you cannot trust the CN at all since you cannot verify who created the certificate in the first place (anybody could) and thus cannot trust this one to properly validate the value in the CN.

With certificates issued for domains by a public CA it depends. If this is a cheap/free DV certificate the issuer if the certificate just checked that the owner of the certificate had at least for a short time partial control of the domain - either over the domains DNS, the domains web server or maybe the email (depending on the verification method). This could have been an attacker as recent events show again.
EV certificates on the other hand have more complex verification and thus are much harder to spoof.

Thus, if you can trust the one who puts the subject in the certificate to properly verify that the claimed owner is the actual owner and if you properly verify the certificate (issuer, expiration, revocation...) and if the sender of the certificate can prove ownership of the matching private key (done when used for authentication inside TLS) and if you can be sure that the private key is actually kept private by the owner (otherwise it is hopefully rejected) - then you can trust the value in the CN/SAN and use it for authentication.

And this is what is actually done in TLS: the server certificate is checked by the client to make sure that it talks to the right server (i.e. no man in the middle). Additionally a server might request a client certificate to authenticate the client. In protocols like SIP where each peer can be client and server it is not uncommon to have such mutual authentication (i.e. both server and client certificate) where the same certificate is used as server certificate when acting as server and as client certificate when acting as client.


Is it possible to recover wannacry encrypted files through file system recovery?

The short answer is no.
There is some analysis on ransomwaree back then. Ransomware indeed think ahead of undelete tools.

Perhaps you mistaken it with system run under virtual machine (e.g. VM snapshot)  ; intrusion monitoring system (that also take snapshot of the machine state or files from time to time, like tripwire, OSSEC); version control system, etc.


Does a compromised kernel give complete control over a device?

Running code in "kernel space" means running it in the ring 0 space. In other words, it is the strict definition of "having total control".

The only exception would be if you are running a hypervisor. In such a case, running code in ring 0 of the virtualized OS would "only" give you full control of the virtualized device, not the hypervisor (which is said to be running in ring -1) it is running on. You would need a separate escape exploit to get to that.


DAA is a specific deprecated government standard for authenticated encryption. It is not something you would want to use. In particular, it is a modified version of CMAC using the insecure DES cipher.

HMAC uses a hash algorithm to provide authentication. It is usually quite fast. CMAC on the other hand uses a block cipher in CBC mode, making it a lot slower. The only reason CMAC, which requires double the number of calls to the block cipher for encryption, would be used is if it is being used on an embedded system which already has hardware acceleration for the cipher, making it easy to re-purpose it for authentication. In general, you will want to use HMAC.


Runtitme Error page is being displayed for XSS or SQL injection payloads

Can we come to a conclusion that the application is vulnerable to SQL Injection or XSS attacks.

Why would you think so?

If the injected XSS payload is not shown, there is no XSS vulnerability (at least not reflected; we cannot say anything about persistent).

We cannot say anything about SQL injection. There may or may not be one, the presence of an error message doesn't tell either way, you need to perform further tests (and enable error messages if you can).

The fact that you get a generic error message only tells you that your request was invalid, but not why. It could be that the application expected an integer but got a string, and thus shows an error (this is how it should be). It could also be that you injected into a query and broke it, and thus got an error message (this shouldn't happen), or it may be a number of different issues.


Difference between stateful and stateless firewall filters

You are right about the difference between stateful and stateless filters. As for UDP packets: this fully depends on the filter rules, i.e. they might be blocked or let thru depending on the rules.

But stateful firewalls also keep a state for the seemingly stateless UDP protocol: this state is only based on source and destination IP address and port and will time out after a while since UDP does not contain an explicit connection start and end. This state makes it possible to associate incoming UDP packets with outgoing packets and thus let incoming packets belonging to an outgoing state through. An example for this are outgoing DNS queries followed by the incoming DNS reply: a stateful packet filter can require incoming UDP packets to match outgoing packets while a stateless filter has no such information and thus cannot do such granular filtering.


How can a website verify that my phone number belongs to me?

Is this just security theater

No.

  or is there an API or database available where I can verify that a phone number does indeed have a certain name attached to it?

The phone companies (ed: didn't used to, but apparently now they do per @ceejayoz) make this information public (caller registry is not reliable, esp. in cases where the name on the bill isn't the owner of the phone), but given the wealth of information marketing agencies and credit bureaus hoard, the information is absolutely out there-- it's just a question of whether anybody is selling it yet. Hell, even Facebook could offer such a service if they were so inclined.

But given what I've dealt with in this space in years past, it's more likely they're checking to verify the carrier itself. Fraudsters using burner phones to abuse OTP systems was a massive, massive problem that had yet to be solved while I was still there and we didn't have a reliable way to filter them out at the time-- yet simply knowing if we were dealing with a Verizon or Boost Mobile customer and performing additional verification for the latter before sending out texts would have eliminated a significant amount of fraud.


List of certificate authorities in browsers and mobile platforms

Yes there is, but each browser may use a different set, here is a list for the main browsers:

Firefox: https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/included/
Chrome: it uses the certificates included with the OS.
Opera: it install the most uses CA within installing the application, you can find the rest in the online root repository: https://certs.opera.com/
iOs: https://support.apple.com/kb/ht5012


Does xkcd.com/1353 overstate heartbleed's capability?

Modern OSes use virtual memory spaces for each process that leads to process isolation.  So it is impossible for a webserver using the flawed OpenSSL library to read memory allocated to other processes (not explicitly shared with the process), at best attempts to do so would result in a segmentation fault.

The truth is heartbleed is a simple overread of a buffer by trusting the payload size being sent in an attacker controlled header and never verifying that the payload was actually that size and written to memory (see [1], [2], [3]).  The attacker sends a heartbeat packet to the server with a header saying the length of its payload being sent (the size in the header is two bytes hence up to ff ff = 65535 bytes), writes the sent payload to memory, and then reads back data of that size back to the client which allows to read whatever is in memory in the webserver's process following the written payload.  This is quite important as you can repeat the attack many times and eventually may get lucky and be able to get private keys for the HTTPS server, and at that point you can MitM the HTTPS server.  (And get at things like erotic fan fiction or user's email). Yes, in the meantime you may come upon random data that the webserver was already serving up, but really the private keys (and less so session cookies) is the important part.

Furthermore, the scary part is that the attack does this in a way that will not be logged unless you are in a debug mode/eavesdropping every packet on the wire and log the beginning of every TLS handshake request.


Self-signed or CA-signed certificates in internal servers

It all depends on what you want to do.

First, unless you only have two machines and really need a cheap solution, avoid self-signed certificates. They are free and easy to generate but maintenance becomes exponentially more difficult as you add servers leading to improper behavior (blindly trusting certs permanently on every server, using certs with very long expiration, etc.).

Now, there are two other options: setting up you ow CA or using an external root.

Setting up your own CA is tricky: on one hand, it's very easy to do, on the other, it's pretty hard to do it right: there are plenty of very easy traps to fall for that will substantially decrease the security (and sometimes usability) of your PKI so it's a solution that need to be carefully planned, tested, implemented and maintained.

That said, having an internal CA (assuming it is properly setup and maintained) will give you plenty of very powerful tools for setting up internal security and it makes managing individual server certificates MUCH easier (in some situations, it can be completely automated).

The alternative is to use a commercial CA. If the following conditions are met, then it is a pretty good solution:

Your security needs falls in the standard offering (for instance, if you just want to secure web servers).
You plan to use exclusively public domains that you own (i.e. no "mycompany.local", no IP address, no "short" NetBIOS names).
You might need, at some point, to offer external access to some (or all) of your internal machines.

One final advise: avoid using a single wildcard certificates on multiple servers. That will make it harder to maintain your private keys securely and breaching a single server will leave your whole infrastructure in vulnerable.


How many iterations of Rabin-Miller should be used to generate cryptographic safe primes?

I just answered to the same question on stackoverflow, so I will duplicate my answer here (I don't think duplication is the way to go; maybe the question should be migrated):

Let's assume that you select a prime p by selecting random values until you hit one for which Miller-Rabin says: that one looks like a prime. You use n rounds at most for the Miller-Rabin test. (For a so-called "safe prime", things are are not changed, except that you run two nested tests.)

The probability that a random 1024-bit integer is prime is about 1/900. Now, you do not want to do anything stupid so you generate only odd values (an even 1024-bit integer is guaranteed non-prime), and, more generally, you run the Miller-Rabin test only if the value is not "obviously" non-prime, i.e. can be divided by a small prime. So you end up with trying about 300 values with Miller-Rabin before hitting a prime (on average). When the value is non-prime, Miller-Rabin will detect it with probability 3/4 at each round, so the number of Miller-Rabin rounds you will run on average for a single non-prime value is 1+(1/4)+(1/16)+... = 4/3. For the 300 values, this means about 400 rounds of Miller-Rabin, regardless of what you choose for n.

(Edit: actually, for a randomly chosen non-prime, Miller-Rabin works better than that (see @Brett's answer) and the average number of rounds will be closer to 300 than 400. It does not substantially change my argument.)

So if you select n to be, e.g., 40, then the cost implied by n is less than 10% of the total computational cost. The random prime selection process is dominated by the test on non-primes, which are not impacted by the value of n you choose. I talked here about 1024-bit integers; for bigger numbers the choice of n is even less important since primes become sparser as size increases (for 2048-bit integers, the "10%" above become "5%").

Hence you can choose n=40 and be happy with it (or at least know that reducing n will not buy you much anyway). On the other hand, using a n greater than 40 is meaningless, because this would get you to probabilities lower than the risk of a simple miscomputation. Computers are hardware, they can have random failures. For instance, a primality test function could return "true" for a non-prime value because a cosmic ray (a high-energy particle hurtling through the Universe at high speed) happens to hit just the right transistor at the right time, flipping the return value from 0 ("false") to 1 ("true"). This is very unlikely -- but no less likely than probability 2-80. See this stackoverflow answer for a few more details. The bottom line is that regardless of how you make sure that an integer is prime, you still have an unavoidable probabilistic element, and 40 rounds of Miller-Rabin already give you the best that you can hope for.

To sum up, use 40 rounds.


How can I secure keys for stored data in a Python web application against server side breach?

The key to answering this question lies in thinking about what access your main web application has and what could happen if an attacker were able to re-program it to do whatever they like.

This thought experiment quickly shows the only way to completely prevent the sensitive data being leaked in this scenario is for the web application to never see it, for example by encrypting it on the client with a key known only by the client. This approach is often impractical for web applications.  However it is used for some applications such as cloud backups.

However, all is not lost.  One can still dramatically reduce the risks of a bulk loss of all of the sensitive data in the system in a couple of ways.

1. Store the encrypted data, but do not store the keys.

In the event of the server being compromised, the attacker only gets the encrypted data.  In normal operation the key can be supplied by the user - for example as their password.  This has the disadvantage that if a user loses their password, they also lose their data.

2. Place the sensitive data (or keys) on a separate server, behind a firewall accessible only via a restrictive API.

The key to this approach is to design the restrictive API such that if an attacker gains access to call it by compromising the main web application, they are limited in what they can retrieve. There are many ways to achieve this, but the basic ideas are as for any service.  Here are some of the things to consider if implementing such an API:

Require authentication (as the relevant end-user)
Don't provide bulk export APIs
Keep the API simple to reduce the risk of programming errors
Rate limit requests


How to securely transmit data (user access info) from node server to react client

No. If you fetch such information for the user dynamically, there is no way to hide it from the browser.

In the end, the user will have to decrypt the encrypted roles. A bad actor will simply check the JS responsible for this part and log the information as it's being decrypted. You cannot stop this without changing your architecture.


Is enough to remove ".." from strings to avoid directory traversal attack?

I can't presently think of a good reason why removing all ".." strings doesn't work, but the most appropriate way would be use the realpath() function and ensure the start of the string matches the intended full directory path.


Do any Exchange hardening guidelines recommend disabling OWA Webready? Should they?

Makerofthings7,

I'm not saying this is a definitive source for you, but it's the best I can find "straight from the horse's mouth":

WebReady security vulnerability reveals complexity of modern software engineering

In that article by Tony Redmond, he states a few interesting things:

  Microsoft recommends disabling the feature on all CAS servers, an
  approach that fixes the problem at the expense of removing some user
  functionality. You might consider such an approach to be a tad
  extreme, but a potential attacker might exploit the now-discovered
  weakness by encouraging a user to view an infected document (probably
  sent as a message attachment) with OWA after connecting to an
  internally-facing CAS

Now, whether you take that to mean "Microsoft temporarily recommends..." or whether Tony believes MS' approach is to disable it as it is simply a luxury item and security is more important...you'll have to make that call.  As he states a short bit later:

  As in all instances to do with security, you have to balance the
  potential risk of penetration and exploitation against the effect of
  applying a fix that removes user functionality. Of course, it’s
  entirely possible that no one cares about WebReady because it’s never
  used and so no one will miss it if you remove the feature from all
  servers.

One thing I did find interesting in the article (I know it doesn't quite help):

  Users of Exchange Online in Office 365 don’t need to worry about the
  problem as Exchange Online uses the online versions of Microsoft’s
  Office applications to view common file formats.

So, take it for what it is...one man's blog article (albeit with some merit) discussing the issue and possibly paraphrasing Microsoft's unofficial stance.


Are FIDO U2F keys (like dual Yubikeys or dual Google Titan keys) undermined by the Google account recovery process?

After all Google decides to recover your account or not. So from a logical stand point you can not lock down the account, because you do not have the ultimate control over the account.

You can answer a lot of security questions and hope that google or the google helpdesk will ask all questions and decide wisely. But after all it is not in your hands.

It does not seem like google would allow to have an account unrecoverable.

So yes, authentication and also two factor authentication is only as good as the processes - in this case the recovery process. And if you have a poor recovery process, then the 2FA is poor, too.


Distributed Denial Of Service Attack Mitigation

In most cases, it is very hard to mitigate DDoS attacks on your own. Most banks and large companies will engage the service of professional DDoS mitigation service providers. The latter will detect anomaly traffic patterns and reroute all traffic to their scrubbing centers for filtering out the bad traffic. The following filtering-based mechanisms are commonly used to mitigate such attacks:

1) Whitelisting recognized IP addresses. e.g., if your company is located in the US and so are most of your clients located, then it could be reasonable to filter our network traffic coming from other parts of the world during an attack so that most of your clients can still be able to access your service.

2) Blacklisting traffic coming from known "spammer" regions.

3) Deploy progressive challenge mechanism like CAPTCHA to prove that the traffic came from a human source and not some program.

4) Rate limiting by destination IP address. Each IP address is only allowed to send a fixed number of requests and the rest of the requests will be simply dropped.

5) Signature-based anomaly detection and subsequent IP blocking. Even if the malicious packets appear normal, there could still exist distinct patterns in the overall traffic. e.g., an average user will only send traffic continuously for 5 minutes each day but the traffic sent by the attacker just keep coming in for long periods of time.

And finally, increase your network resources to survive the attack or temporary rent extra cloud-based resources to "absorb" the attack. Such a counter measurement is used by DDoS Mitigation service providers like Incapsula, Akamai and Verisign to prevent themselves from becoming victims.


How to defend against HTTP request flood

depending on your implementation, it can be done three (3) ways:

1. application layer approach:

set an authentication on your web server or application. this can be done by allowing only POST/GET functionality through an identified list of authenticated and authorized users.
authorized requests only from known IP range.
authorized requests from all and block certain IP range.
do a 301 to any non-authenticated/non-authorized users.

2. network layer approach:

this is far more practical considering you are deciding for the fate of the packet right before it reaches the other end or even if it had already completed the 3-way handshake. consider these examples:

a. restrict the number of concurrent connections per IP on your firewall. this will give you the ability to define how many connections can a client requests simultaneously.

in iptables, you can do this by:

 # iptables -p tcp --syn --dport 80 -m connlimit --connlimit-above 20 --connlimit-mask 24 -j DROP

in openbsd, you can do this in pf.conf:

 pass in on $ext_if proto tcp to $web_server \
     port www keep state \
     (max 200, source-track rule, max-src-nodes 100, max-src-states 3)

where it means:

Limit the absolute maximum number of states that this rule can create to 200
Enable source tracking; limit state creation based on states created by this rule only
Limit the maximum number of nodes that can simultaneously create state to 100
Limit the maximum number of simultaneous states per source IP to 3

b. for pf, you can filter the traffic by matching the tcp packets based on flags and decide for your next rule.

3. do an combination of an application layer and a network layer approach


Injecting script from outside for local machine url request

You can intercept the request through a proxy and then inject the alert() into it.
To do that you would need, Burp Suite.


Why are the CVSS scores differ so much between Redhat and NVD page?

Working out the inputs to the calculations is very subjective:

Take the CVSSv2:

RH:  AV:N/AC:M/Au:N/C:P/I:P/A:P

NVD: AV:N/AC:L/Au:N/C:C/I:C/A:C

Both agree the Attack Vector is Network, and the Authentication is None. But disagree with everything else.

NVD think the attack difficulty is easy and the impact is complete.
RH think the attack difficulty is medium and the impact is partial.

Since the attack doesn't get root, I'm not sure impact can really be complete. But you can see why the values are different.

PS: Although not relevant to this case some of the temporal score for CVSSv2 are particularly weird:
Take https://nvd.nist.gov/vuln-metrics/cvss/v2-calculator?name=CVE-2016-7872&vector=(AV:N/AC:L/Au:N/C:C/I:C/A:C) and apply a "Official fix available" and the result drops from 10 to 8.7. It you had a rule that you had to fix everything above a 9 immediately, you'd have to fix it if there wasn't a patch, but not if there was a patch available.


Custom email domain with a third-party provider: security holes to watch out for?

one security threat is about content, and you can use PGP for encrypting your email, PGP is end-to-end and if you use a strong key your email provider can't decrypt your emails in reasonable time and cost.


There' a pretty good Microsoft KB article on this exact subject.

Basically, LM is used for compatibility with older clients. Specifically, Windows 98 and below. If you do not have any older clients on the network, then the cause for both hashes is most likely due to the password length being <15 characters.

  When you set or change the password for a user account to a password
  that contains fewer than 15 characters, Windows generates both a LAN
  Manager hash (LM hash) and a Windows NT hash (NT hash) of the
  password.

It appears that the reason for this is due to the hashing limitations of LM, and not security related.

  In the event that the user's password is longer than 15 characters,
  the host or domain controller will not store the LM hash for the user;
  the LM response cannot be used to authenticate the user in this case.
  A response is still generated and placed in the LM Response field,
  using a 16-byte null value (0x00000000000000000000000000000000) as the
  LM hash in the calculation. This value is ignored by the target.

It is advised to disable LM hashes as the protocol is severely broken as you suggested. For those who might not be aware, some of the problems with LM's include:

Passwords are not case sensitive.
Password are split into 7 chars and hashed seperately, making brute force trivial.
Passwords are limited to a maximum of 14 characters in length.

There are a couple methods to removing LM hashes listed on the KB article I mentioned, I will quote the GPO method in case the link goes bad.

Method 1: Implement the NoLMHash Policy by Using Group Policy

To disable the storage of LM hashes of a user's passwords in the local computer's SAM database by using Local Group Policy (Windows XP or Windows Server 2003) or in a Windows Server 2003 Active Directory environment by using Group Policy in Active Directory (Windows Server 2003), follow these steps:

In Group Policy, expand Computer Configuration, expand Windows Settings, expand Security Settings, expand Local Policies, and then click Security Options.
In the list of available policies, double-click Network security: Do not store LAN Manager hash value on next password change.
Click Enabled, and then click OK.


Generic answer: ideally, the session should be exactly as short as possible, the limit being, indeed, the user's annoyance.

You make sessions because the user would not accept to reenter his password for every single page request. A session is a deliberate, controlled weakening of your security model; you accept it because otherwise the site would be unusable. However, your interest, on the server, is to keep sessions short.

Now, of course, this is a trade-off. User's annoyance is not binary. A bank will balance their own feeling of security against their perception of the user's annoyance (and the importance thereof -- the bank knows that it can thoroughly abuse the user, since bank account owners are somewhat "captive"). Apparently, your two banks chose distinct compromises.


Hashing a credit card number for use as a fingerprint

Ok, so if this is a business requirement that you must meet (check to see if a card already exists in the system) this is how I would do it.

First, PCI-DSS does allow for a PAN (the primary account number, or credit card number) to be stored in hashed form using "strong cryptography" and they recommend (but do not require) that a salt be used as well.  PCI-DSS v3 § 3.4(PDF link)  The reason is to inhibit the ability of a malicious party who gets ahold of the hash from determining the PAN that was used as the input for the hash.

Second, your plan to store this in a separate, secure system and expose it only via an API is a good defense in depth measure.  If I were implementing this, I wouldn't have it send a hash back to the primary system, I would simply take the hash as a parameter for the API call and have the API return "true" or "false" depending on whether the hash already exists in the system or not.

For the hashing function, the key to preventing the recovery of the inputs (as required by PCI-DSS) is to chose an algorithm that allows you to make the process computationally hard, so the task of brute-forcing the relatively small input space of valid PANs reasonably slow.  SHA-512, suggested by another answer, is not this algorithm.   Looking at the test matrix for hash cracking provided by hashcat.net the fastest machine in their matrix  can calculate nearly 2 billion SHA-512 hashes per second.  With an estimated input space of approximately 30,000,000,000,000 cards**, that means that unsalted, you could compute the SHA-512 of each of those PANs in just over 4 hours, and have the card numbers for ever card in the database, should it ever be stolen.

So, what we need is a slow hash function, however the definition of slow changes all the time as computers get faster and technology evolved.  This means that a secure hash function will be one with an adjustable work factor, so over time you can increase the computational effort required to compute the hash of a given input.  There are several candidate algorithms that meet this criteria including PBKDF2, bcrypt, and scrypt.   The general consenus for password hashing is bcrypt, and that is what I would suggest here.  For the cost, set it as high as your application allows.  It likely isn't something you're going to be computing terribly frequently (I'd imagine, depending on your application, you're going to be looking at x hashes per minute or hour or day rather than per second) and the higher the cost, the harder it will be for an adversary who captures the hash to brute force.

** My estimate is based on a 9 digit account number, a computable check digit that doesn't increase complexity and a WAG of 30,000 active bank identification numbers (the first 6 digits of the card) based on a list I found.


How many hostnames can be supported by a wildcard ssl certificate? Is there any limit?

There are two distinct things here. One is about the number of hostnames that you can put in a certificate. The other is the notion of "wildcard names".

In the Subject Alt Names extension, you can put "alternate names" of type dNSName. Each of them is an "acceptable server name" (i.e. clients will accept the certificate for a server that purportedly uses that name). The ASN.1 notation for the extension is the following:

   SubjectAltName ::= GeneralNames

   GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName

   GeneralName ::= CHOICE {
        otherName                       [0]     OtherName,
        rfc822Name                      [1]     IA5String,
        dNSName                         [2]     IA5String,
        x400Address                     [3]     ORAddress,
        directoryName                   [4]     Name,
        ediPartyName                    [5]     EDIPartyName,
        uniformResourceIdentifier       [6]     IA5String,
        iPAddress                       [7]     OCTET STRING,
        registeredID                    [8]     OBJECT IDENTIFIER }

See the "MAX" ? It means "no limit". You can put as many names as you want in a certificate.

Well, since we are talking about DER encoding, the total length of the certificate must not exceed 702223880805592151456759840151962786569522257399338504974336254522393264865238137237142489540654437582500444843247630303354647534431314931612685275935445798350655833690880801860555545317367555154113605281582053784524026102900245630757473088050106395169337932361665227499793929447186391815763110662594625664 bytes, and each name will take a dozen bytes or so (at least). But existing libraries and protocols are likely to enforce stricter limitations. For instance, if the certificate is to be used in SSL/TLS (e.g. a certificate for a Web server that does HTTPS), then the certificate MUST fit within 16 megabytes (its length is encoded in a three-byte field, as per the SSL/TLS protocol). Thus, you can have a maximum of about one million alternate names in a certificate.

Then, each of the name may be a wildcard name, meaning that it contains the "*" character. The "*" will match any sequence of characters except dots. Existing browsers, there again, enforce other constraints, in particular:

There shall be only one "*" character in the name (so no "*.*.stackexchange.com", to take an actual case).
The "*" must appear as first character, not elsewhere (so no "meta.*.stackexchange.com", to continue on that real-life situation).
The "*" must stand for a complete name component (hence "*.example.com" but not "*foo.example.com").

A name component is limited to 63 characters, and the characters must be only letters (case insensitive), digits and the minus sign ("-"), so there are about 3764-2 = 23169162752708970943114627382699355445603465075569066753527132965271355336698663689946873706000418559 possible names matching a wildcard name (the "-2" is because the empty string is not a valid name component)(there are other restrictions, e.g. not beginning with a minus sign, but clients tend not to enforce these).

Since you can have a million alternate names in a certificate, multiply that number by one million, and you will have the maximum number of host names that match your "wildcard certificate". It ought to be enough for most purposes.

Take note of a common confusion. We say "wildcard certificate" but that is a misnomer. What is meant is "certificate such that at least one of the contained names is a wildcard name".

For a real-life example, have a look at Google's certificate (connect to https://www.google.com/, then ask your browser to show the certificate). Right now, the returned certificate contains no less than 49 alternate names which are the following:

*.google.com
*.android.com
*.appengine.google.com
*.cloud.google.com
*.google-analytics.com
*.google.ca
*.google.cl
*.google.co.in
*.google.co.jp
*.google.co.uk
*.google.com.ar
*.google.com.au
*.google.com.br
*.google.com.co
*.google.com.mx
*.google.com.tr
*.google.com.vn
*.google.de
*.google.es
*.google.fr
*.google.hu
*.google.it
*.google.nl
*.google.pl
*.google.pt
*.googleadapis.com
*.googleapis.cn
*.googlecommerce.com
*.googlevideo.com
*.gstatic.cn
*.gstatic.com
*.gvt1.com
*.gvt2.com
*.urchin.com
*.url.google.com
*.youtube-nocookie.com
*.youtube.com
*.youtubeeducation.com
*.ytimg.com
android.com
g.co
goo.gl
google-analytics.com
google.com
googlecommerce.com
urchin.com
youtu.be
youtube.com
youtubeeducation.com

Notice that 39 of these names are "wildcard". With the numbers above, this means that this certificate can potentially match no less than 903597347355649866781470467925274862378535137947193603387558185645582858131247883907928074534016323811 distinct host names. And that's Google -- one can expect that their certificate "works everywhere".


Is an up-to-date browser secure on an out-of-date OS?

Do not use an outdated OS, even with a modern browser.

  Assuming that after that day I still use an updated browser, is it true that I'm still safe?

No, you cannot avoid browser-based security holes only by updating the browser. There are a few reasons for this. Primarily, the browser is not entirely self-contained. It makes use of operating system libraries, for example the system memory allocator. This allocator is designed to mitigate various memory corruption-related security issues. If the allocator is not kept up to date, memory exploitation bugs may be easier to perform against the browser, no matter how up to date the browser is.

Another reason is that browser security often relies on OS sandboxing features. A powerful browser exploit must be combined with a so-called sandbox escape. How easy that escape is depends on how secure the operating system is as well as how secure the browser is. By using an outdated operating system, your browser is being protected by out of date and potentially vulnerable security features.

  Can it "patch" the OS-based security holes?

No. Patching operating system vulnerabilities requires elevated privileges, which a browser does not have. Even if it did, browsers are not designed to modify system settings or system files. There is no extension or web page you can go to that is able to patch security vulnerabilities in your OS.

  Minor question: typically, how long would the browsers stop supporting abandoned OS?

Browser vendors typically publish when they will stop officially supporting a particular operating system. After that point, changes made to the browser that break on older systems will no longer be considered bugs and may not be fixed. Programs typically continue running on older systems for a very long time, however. They only stop working when they begin to rely on newer system APIs that aren't present in older versions. This is relatively rare. A browser should be able to run on an outdated operating system for many years, albeit not very securely, and without official support from the vendor. Most likely, as it begins to rely on newer and newer APIs, features in the browser will just start breaking one by one (especially security-related features) until it eventually does not start up at all.


How secure is it to use passwords consisting of one common part and one site specific prefix?

This reminds me of how Dan Kaminsky got hacked. He used to use passwords like:

fu*k.hackers
fu*k.mysql
fu*k.vps

So bad guys has revealed his pattern and the rest of the "job" was easy.

The lesson of the story is; stay away from this.


Is it enough to change only the MAC address of a VM to enhance anonimity?

I heard that it is a good practice to change the MAC address of
  your Kali VM so that no particular action can be traced to you (at the
  link level)

To rephrase, changing the MAC address may make it harder for the network administrator to identify who is behind any actions they are monitoring. It has no effect beyond the router/gateway, as you have noted.

The result and effectiveness of changing the VM's MAC address will vary widely depending on the configuration of the VM and host's networking. Some of the following may vary between hypervisor but should be true in general.

NAT VM Adapter

If the VM is on a NAT'd network provided by the host machine, changing the VM's MAC address has no effect for your purposes, as the "real" network is already behind a router (your host), so the "real" network will only see the host's MAC address.

Bridged VM Adapter

A bridged adapter places the VM directly on the same network as the host, often by using a custom driver that can inject packets onto the network and retrieve them as well. In this case, the VM will have its own MAC address that is independent of the host. In this case, changing your MAC address should have the desired effect.

One caveat is with regards to wireless networking. If the bridged adapter in use is a wireless adapter, the host will substitute the source MAC with its own (the MAC address is used in 802.11; the wireless access point would not recognize frames from the VM's MAC address as there is no such authenticated client). In this case, it would not help for what you want.

USB Adapter

Finally, if you are using a USB network adapter that is passed through to the VM, wired or wireless, it is completely independent from the host and will work as expected for your purposes.


When you configure the network on VMware player for instance to be in "NAT" mode, it'll simply do a "NAT HIDE", in which your host, after sending traffic to the network card, will have his SOURCE IP changed to the HOST IP (this is also know as PAT, port address translation).

If you don't have any specific rules on the HOST firewall denying traffic between vm network and host network then you will be able to access your host.


In the article you linked to, the Javascript code is not being included inside the image file itself per se, it's manifesting within the HTML page that references the image. Untrusted input is being returned inside the image tag without sufficient validation or sanitisation. This is persistent cross-site scripting since the malicious input is being returned every time someone views the page that includes this image (i.e. it's probably stored in the database as part of the user's profile).

Conventionally, the HTML markup to include a profile picture might look something like this:

However, it has to be different for each user, so the application code that generates it might look something like this (example is PHP):

<img src="/<?=$imagename?>">

So if the user Alice uploaded alicespic.jpg, users would see that image when they visited her profile, for example. However, this is where the vulnerability can occur, if the image name is not properly validated or sanitised.

For example, if Mallory could set her profile's image name to inncoent.jpg" onload="alert(1), the following HTML markup would be generated:

Utilising the onload event means that the arbitrary script will be executed once the image has finished loading. Essentially, this Javascript code will be executed every time someone views the affected profile, but it will run inside their browser.

This would not occur if the developer only allowed safe characters to be included inside the image name.


Is it possible to detect malicious software just by analyzing the code structure?

No you can't, not all the time reliably. To detect viruses simply by static analysis would likely contradict Rice's Theorem which says that such problem is undecidable.


Compile the php with debugging symbols enabled, run it under valgrind, and see if you can trigger the overflow.  Valgrind will give detailed information about the overflow and where it occurs in the source code.

Generating a backtrace via gdb should also help you diagnose the issue.

See also Best way to triage crashes found via fuzzing, on Linux?.


Physical destruction of a drive is tricky business. There are many companies that deal specifically in the field of data destruction, so if you are doing any kind of mass you may want to at least look at their price list. If you contract, make sure the company is properly bonded/insured, and provides audit trails for each  destroyed item. In the worst case scenario that your information does get out, you want the document in hand that says your contractor properly destroyed the item in question. Then, at least, you can transfer the liability.

When it comes to drive destruction you typically see one of two main fields:

Disk Degaussing
Physical Destruction

Degaussing

Degaussing used to be the norm, but I am not such a big fan. On the plus side it is fast, you'll normally just dump the disks on a conveyor belt and watch them get fed through the device. The problem is auditability. Since the circuitry is rendered wobbly, you won't be able to do a spot check of the drives and verify that the data is gone. It is possible, with some level of probability unknown to me, that data could still exist on the platters. Retrieving the data would, without question, be difficult, but the fact still remains that you cannot demonstrate the data is actually gone. As such, most companies now will actually be doing physical destruction.

Physical Destruction

At the low end, say a small box of drives at a time, you'll have hard drive crushers. They're often pneumatic presses that deform the platters beyond useful recognition. At the risk of supporting a specific product, I have personally used this product from eDR. It works well, and is very cathartic.

At a larger scale, say dozens or hundreds of disks, you'll find large industrial shredders. They operate just like a paper shredder, but are designed to process much stiffer equipment. The mangled bits of metal that are left over are barely identifiable as hard drives.

At an even larger scale you can start looking at incinerators that will melt the drives down to unidentifiable lumps of slag. Since most electronics can produce some rather scary fumes and airborne particulates, I would not recommend doing this on you own. No, this is not a good use of your chiminea.

Manual Dis-assembly

If you are dealing with one or two drives at a time, then simple dis-assembly might be sufficient. Most drives these days are largely held together with torx screws, and will come apart with varying levels of difficulty. Simply remove the top cover, remove the platters from the central spindle. Taking a pocket knife, nail file, screwdriver, whatever, have fun scoring both surfaces of each platter. Then dispose of the materials appropriately. I cannot speak to how recoverable the data is afterwards, but it is probably sufficient. The biggest thing to keep in mind is that while most desktop hard drive platters are metal, some are glass. The glass ones shatter quite extravagantly.

You should also take care of removing and destroying the memory chips on the board because of cache memory and (with "hybrid" drives) of NAND chips containing up to 4GB of cached data.
A good way to do that is to wrap the board in linen or another coarse cloth and hammer it, that should keep broken parts from flying everywhere.

Additional Considerations

Before you decide on a destruction method, make sure to identify what kind of data is stored on each device and treat it appropriately. There may be regulatory or legal requirements for information disposal depending on what data is stored on the disk. As an example, see section 8-306 of DoD 5220.22-M.

For hard drive destruction, DoD 5220.22-M section 8-306 recommends:  "Disintegrate, incinerate, pulverize, shred, or melt"

All that being said, performing a single pass zero wipe is probably sufficient for your purposes. Modern research indicates that modern hard drives are largely immune to the "magnetic memory" problem we used to see on magnetic tape. I would never bother doing anything more on a household drive unless the drive itself was exhibiting failures.


The SSL-3.0 specification contains the following excerpt, in the description of the ClientHello message:

  Forward compatibility note: In the interests of forward
  compatibility, it is permitted for a client hello message to include
  extra data after the compression methods.  This data must be included
  in the handshake hashes, but must otherwise be ignored.

What this means is that while TLS extensions were only defined, formally, for TLS-1.0 and later, they can be included in a ClientHello for SSL-3.0, and nothing prevents any client or server to actually use such extensions as part of a SSL-3.0 handshake. OpenSSL, however, appears unwilling to do just so. Notably, the command-line tool, when used as a client (openssl s_client), does not send a SNI extension (or any extension) when instructed to use SSL-3.0 only.

There is no room for extensions in a SSL-2.0 ClientHello message. A consequence is that if a client wishes to support a SSL-2.0-only server, then it must send its ClientHello in the SSL-2.0 format, and this prevents the use of any extension.

Note that SNI support involves both client and server (the client must send the extension, the server must understand it). Old clients may not know about SNI (a notable example being Internet Explorer when running on Windows XP). A client that requires using SSL-2.0 or SSL-3.0, but does not support TLS-1.0, must be quite old (more than 15 years) and is unlikely to be aware of the existence of SNI. TLS-1.0 was published in January 1999 while SNI was first formally published in June 2003.

In any case, you should not use either SSL-2.0 or SSL-3.0, both of which having irremediable security issues. There is even a standard that prohibits using SSL-2.0. It can be argued that a Web browser that does not know SNI or TLS-1.0 is a browser that has not been updated for many years, and therefore must include a huge number of known vulnerabilities, and is probably already host to a handful of malware and part of one or several botnets. In that view, the only sane behaviour of a Web server that receives a connection request limited to SSL-3.0 (or lower) is to reject it unconditionally. It may be contagious.


Why does the SSL/TLS handshake have a client and server random?

From The First Few Milliseconds of an HTTPS Connection:

The master secret is a function of the client and server randoms.

master_secret = PRF(pre_master_secret,
                    "master secret",
                    ClientHello.random + ServerHello.random)

Both the client and the server need to be able to calculate the master secret. Generating a pre-master secret on the client and just sending that to the server would mean the the client never gets to find out the master secret.

Why not just use the pre-master?

This would mean that the entire key generation routine was based on client generated values. If a Man-In-The-Middle attacker replayed the handshake, the same pre-master secret would be sent and then used for the connection. Having the server generate a random value (ServerHello.random) will mean that the MAC secret is different if the ClientHello.random is repeated, and therefore the MAC and encryption keys will be different, preventing any replay attack.


All shipping iOS devices (with the possible exception of the AppleTV, which doesn't have third party apps) have two filesystems, implemented as two partitions on the flash storage. The first is mounted read-only and just contains the OS. The second contains user data: the installed apps, and their supporting data including documents and caches. This second partition, on the iPhone 3GS, iPhone 4, 3rd and 4th generation iPod Touch and the iPad only is encrypted with a key that is managed by a hardware encryption chip on the device's PCB. This key cannot be leaked out of the chip directly; though I don't know if there are any side-channel attacks.

When the device is turned on, the encryption chip unlocks the second partition. That means that this encryption only protects the data at rest. In fact, it's designed to support quick remote wiping: when the device receives the remote wipe signal it just resets the key.

iOS 4 separately uses the same encryption facility to support its file protection API. Files store with the NSFileProtectionComplete option are encrypted on the filesystem, and the decryption key is only available while the device is unlocked. That means that when you lock the screen, even if an app has a background component that is still running, the protected files cannot be accessed.

In the case of protected files, if the user has a passcode configured then the passcode and the device key are combined to derive the protection key. Actually, it's a little more complex: each file is protected by a separate key. These keys are protected by a class key. The class key is protected by a key derived from the hardware key and the passcode. This gives you the following properties:

when the device is locked, the files are completely unavailable because the kernel doesn't have the passcode with which to generate the unlock key.
brute force discovery of the user's passcode must be done on the device, which slows down attempts.
remote wiping still involves just resetting the device key.


Cache Bank conflicts and CacheBleed: What is there to worry about?

Side-channel attacks are currently all the rage. The conceptual core idea is that while a cryptographic algorithm is a mathematical object whose inputs and outputs can be expressed in an abstract way, it will also run on some physical hardware somewhere, and that execution may leave traces in various ways, that might reveal bits of information about the data which is processed, in particular any private key.

It all began with the publication of timing attacks against RSA by Paul Kocher, back in 1996. In that case, the RSA private key could be rebuilt by making some precise measurements of the execution time of the RSA private operation (decryption) and correlating it with the input data.

There can be many ways by which hardware leaks information. Embedded systems, and in particular smart cards, are especially vulnerable because they get their power or even possibly their clock signals from the outside; and, more generally, they have to keep their secrets secret even when they are, as it were, between the hands of the attacker. Software platforms, e.g. Web servers, have it much easier, comparatively speaking.

There have been a lot of demonstrations in lab conditions of how timing attacks could be applied to algorithms and implementations on software platforms. There are two levels at play here:

The algorithm can have a data-dependent execution path leading to varying execution time even in the abstract model of the algorithm execution. This is what happens with usual square-and-multiply algorithms for modular exponentiation. Kocher's attack is about such an algorithm.
The algorithm may be all "constant-time" within the abstract model, but still exhibit data-dependent execution time variation, directly or indirectly, because of the way it is implemented. For instance, a window-based optimization on the square-and-multiply may still leak information because the elements accessed in memory won't be the same depending on private key bits, and this implies varying behaviour with regards to caches.

CPU cache is a pervasive optimization in all modern hardware platforms except the most reduced (smart cards do not usually have cache, but that's about it). Caches work by keeping a copy of some recently accessed data elements in a special piece of RAM that the CPU can read much more efficiently than common RAM. Details depend a lot on the cache technology (cache line size, alignment, cache-back or write-through, associativity...). Cache-based attacks are attacks that try to leverage cache behaviour. Basically, the algorithm, throughout its execution, will access some data elements, evicting from the cache some other data, so that the next read access to the evicted data will trigger a roundtrip to main RAM, which will be detectably slow (in modern systems, a RAM access that goes to main RAM may take hundreds of clock cycles).

The attacker needs some rather accurate access to the hardware to make cache-based measures. In most demonstration, the attacker can run his own code on the same hardware. This could be another process (in the mainframe model), but it also works if the attacker runs another virtual machine that happens to have been scheduled on the same CPU as the target system. Since modern CPU are multi-core, this is a normal occurrence even in the clouds with the best repute. In some rare cases, lab-level demonstrations of a network-based cache timing attack have been run, by making a call to another service on the same machine that would happen to exercise the relevant cache lines. In the network case, it still requires some precise timing (we are talking about microseconds here) so it is generally assumed to be very hard to pull off from any place other than the local LAN.

Defence against side-channel attacks entails using constant-time code. Basically, the memory access pattern shall be fixed for all possible secret values. This applies to both data accesses, and code (since code itself is also accessed from RAM). Therefore, no data-dependant conditional branches.

Writing constant-time crypto code can be tough to do. However, there are known efficient implementations, e.g. for AES. It is possible to make a good, fast and yet constant-time RSA implementation.

OpenSSL developers, however, did not go that far. They made an effort, but they tried to cut corners, and it backfired. This is what CacheBleed is about. The RSA implementation in OpenSSL is not constant-time in the sense explained above; it merely makes a spirited effort at keeping a fixed access patterns to cache lines, as opposed to actual memory slots. Thus, they were constant-time only on some very specific hardware, not on all of them, and cache-based timing attacks were still possible. CacheBleed uses the "attacker's code on same hardware" model, whose main practical incarnation nowadays would be two VM running in the same cloud.

Do not panic, though, because it is unclear whether cache-based timing attacks are really practical. We have lots of lab demonstration, but no actual usage in the wild has ever been spotted.

One important point to consider is that cache-based attacks are not restricted to cryptographic algorithms. Anything that processes secret data is conceptually vulnerable. And if a machine is dealing with encryption, then it certainly manipulates confidential data. Cryptographers tend to focus on cryptographic keys because keys concentrate confidentiality and are high-value targets; and also, that's their job. However, the scope of cache timing attacks is larger. In other words, if cache timing attacks apply at all on your system, then you have a big problem and the cryptographic layer is only a small part of it.

What should you do ? The same thing as always: install the security patches. It should go without saying. That it still needs to be said is embarrassing. For you, I mean.

And, on a more general basis, if you intend to "go cloud" and share the same hardware with complete strangers, well, think twice. A really good cloud provider will enforce hardware separation for their big customers, i.e. ensure (contractually and technically) that any given machine will never run concurrently two VM from distinct customers. Alternatively, there is a lot of good to be said about private clouds.


The best way is to simply encrypt your traffic from/to the country. Using a VPN tunnel, or a SSH socks5 tunnel are the two most common solutions. They will encrypt the traffic from your laptop to the server, before it reaches the internet. Of course someone could sniff the servers traffic, but it would be out of reach to whatever country you're visiting.

You can get a VPN account from many different providers for a monthly/yearly fee if you don't want to set up a server yourself (which is quite difficult). They will provide step-by-step guides to get you going, and it's really easy to get it installed. Many of them also promises anonymity.

A SSH-tunnel requires that you have access to a shell account. You can easily set up a SSH-server in your own home. It would encrypt the traffic from your laptop to your home network before it reaches the internet. The traffic will seem as it came from your home network. This is the simplest solution if you want to do it yourself, and you can specify the applications that should run through your secure tunnel, wheras with a VPN-account everything will run through the tunnel.

My own solution is to run all my browsing traffic through a ssh tunnel, and have a portable, slimmed firefox installation that I use when I want to browse around for fun (youtube, reddit, ...).

If you don't use a tunnel, make sure you only login to websites using secure https. Never download and run any files using your unsafe connection. Use a safe dns provider such as opendns or google dns to protect yourself from dns-spoofing. Preferably an encrypted DNS-provider. I'm not sure if encrypted DNS is very common (but I know that opendns provides it).

Some email providers, such as gmail, use full HTTPS by default. While others like yahoo only use HTTPS during the log in. Keep that in mind aswell (and enable it if you are using hotmail because it's not enabled by default).

I could expand indefinitely on this subject. But if your knowledge is slim, just get a monthly VPN account from a safe provider. This is the safest and easiest solution to protect yourself.

If you decide to get a VPN-account, I recommend that you do some research before choosing which one. Here is a link to torrentfreak with a list of VPN providers.

https://torrentfreak.com/which-vpn-providers-really-take-anonymity-seriously-111007/


sqlmap - Testing parameters when reading request from file

By default sqlmap tests all GET parameters and POST parameters.

Source: https://github.com/sqlmapproject/sqlmap/wiki/Usage (Injection -> Testable Parameters)

It would seem the issue isn't specifying that sqlmap needs to test all parameters.

I would suggest checking what the request headers look like, when you run your last command.

EDIT: I typically don't see variables replaced with asterisk in the file.


Absolutely there is a point. Properly configured HTTPS includes an authentication check that ensures that the server is the site you intend. More technically, it confirms that the client-specified hostname (ie: what's in the URL bar for your page) match the name on the SSL certificate. Assuming that a site's private key hasn't been stolen, when you communicate with HTTPS, you know who you are talking to and that there is no man in the middle (MiTM). You have no such guarantee when you are using straight HTTP. You may be talking to an attacker's site or there may be a MiTM modifying what the real site is sending to you.

This HTTPS authentication is the opposite of website authentication as SSL authentication authenticates the server to the client while website authentication authenticates the user to the server. The only time website authentication would be relevant for a download would be if you wished to restrict or otherwise monitor who is performing the download.


Why does my "Client Hello" change depending on server config?

I can confirm that I have tested hardened web servers for compliance and had no issues with IE or FF negotiating these ciphers. The only hiccup is that default configuration of FF, unlike other browsers, is configured to accept AES128-based suites over AES256-based suites if both enabled.


Reversible password storage obfuscation method for third-party login credentials

Let's suppose that in your app (let's call it App1), the user already has to enter some credentials C1 (name and password) which App1 uses when it connects to your central database. Right now, your central database contains C2 as cleartext, to be used when App1 connects to App2.

Let H() be a hash function with a large output, say SHA-512. When the user enters his password (C1) in the interface of App1, App1 computes H(C1) and obtains a 512-bit value, which it then splits into two 256-bit halves, Pl and Pr.

The credentials C2 are symmetrically encrypted with a key derived from Pl. This derivation should be slow (like bcrypt or PBKDF2 or something equivalent); I suggest relying on an existing, well-audited format for the encryption details and the key derivation, e.g. OpenPGP. Let's call E(C2) the encryption result.

Now let your central database store E(C2) and bcrypt(Pr).

When the user enters C1 in App1, App1 applies H() to obtain Pl and Pr. App1 then contacts the central database and sends Pr (within a SSL tunnel, of course). The central database applies bcrypt() on Pr to see if that matches the stored value; if yes, it sends E(C2) back to the client. Then, App1 uses Pl to decrypt the blob and obtain C2.

This way, the central database never obtains the decrypted C2 at all; and C2 are known to App1 only in a transient way (in RAM, not "hidden" in the code). What the central database knows is sufficient to test a password for validity, but slow hashing and salting is employed to counteract that issue (as part of E() for Pl, using bcrypt() for Pr).


Question about access control with RBAC and DAC

It looks to me like the question is asking how many relationships there would be, but you are calculating the maximum number of possible relationships.

  there are total of 1250 users and 29 permission so the number of relationship I got is 36,250.

Each user doesn't need all 29 permissions. 1200 users need 10 permissions, 100 need 9, 10 need 6, and 2 need 4, which is 12968 total.

  I did 1250 * 4 (users X roles ) + 29 * 4 (roles X permissions) which gets me 5116.

Since there are more employees listed than there are in the company, some are going to need multiple roles, but every employee isn't going to have every role. 1200 will need a "Clerk" role, 100 will need a "Teller" role, 10 will need a "Manager" role, and 2 will need an "Auditor" role, for 1312 total user-role associations. Additionally, each role will not have all 29 permissions (that would defeat the point), 1 role will have 10, another 9, and 6, and 4, for a total of 29 role-permission associations.

Technically the question doesn't give enough information for an exact answer, as some of the 10 permissions clerks need could overlap with some of the 9 permissions tellers need, and so on. This would slightly reduce the number of associations for the DAC but not the RBAC, as someone who was both a clerk and a teller may need only 13 permissions instead of 19 due to the overlap.


Does Ransomware on one computer put entire network at risk?

Short answer, without any supplementary information, one should at least consider the risk of network infection as important.

The main thing is at least to be able to put a name on the malware, and even better to detect how this first computer was infected.

Some worms indeed use network connection to propagate themselves: they scan the local network generally targeting some defined unpatched OS flaw and take advantage of this to propagate. However, this the worst scenario because:

The other system may be up-to-date and correctly patched,
Not all worms are acting like this,
You may even not be facing a worm at all, in such case the ransomware contamination was just the result of another way of infection not impacting for the rest of the network (phishing email, browser flaw exploited by some site visited by the user, etc.).

If possible, I would encourage you to take a look for suspicious network activity. A dozen of infected PCs scanning the network to find supplementary victims is usually quite noisy...


What computer information can WiFi networks see?

This started off as a comment on Snappie's answer, but it's getting a bit long...

  Assume all data is encrypted using SSL

But not all data is encrypted!

(in addition to IP address, and the amount of data being passed in either direction...)

They can also see the IP names of all the resources you access (including web) from your DNS activity (not encrypted). If you are using a proxy, then this is also exposed in the proxy logs.

They can see what type of network interface you have (from the MAC address).

They can see when your computer connects to the network (Wifi connect, DHCP).

From passive sniffing of encrypted traffic they could probably guess what family of OS you are using.

I believe Chrome can be quite chatty as it tries to work out if something is a URL or a search term and tries to diagnose what network connectivity it has. I would presume that this could be exploited to determine if you are using Chrome, although its not something I know a great deal about.

If, at any time, your browser does make a non-encrypted request, then this will reveal a lot of details about your browser and OS. Depending on the service, it may also reveal a lot about your affiliation to the site.

...and this is just from passive data collection. If they choose to start sending data at your device, it will reveal a lot more.


E-mail can be made to appear like it came from a big organization?

It sounds like you're asking about email spoofing.  Look here for a good primer on the subject

Email all by itself is not a secure technology, and it is very easy to spoof a sender.  Often times the mail server doesn't need to be hijacked to send email as that person.

People who want to protect their branding need to implement anti spoofing technologies.  Some anti spoofing technologies include SPF records, DKIM signing, and DMARC authentication.

When the sender and the receiver both implement SPF, DKIM and DMARC properly then spoofing risk is greatly reduced.


Can a forensic exam find an image's geographic metadata after geotagging was disabled?

Try to correlate the photo’s time with other artifacts recovered from the device. Those other artifacts might provide evidence of location.

Consider network logs. If the phone was connected to a free WiFi access point at a restaurant two minutes before the photo was taken, and remained connected afterwards, the photo was probably taken within a few dozen meters of the restaurant.

Check the browser history. Some sites ask for location data; if they were connected to a site that had permission, it could still be present.

Check for other apps that use location data, such as IFTTT or a home automation app. They may have a ‘geofence’ feature and it may keep a log of where the device has been. Or they may have a navigation app that tracked where they were.

Were other photos taken near the same time? If they have their EXIF data still intact, you can show that the phone couldn’t have gotten very far between pictures.

Also consider what’s in the picture. The background can easily give away the location. See this article for info about such efforts on a large scale.

Cell records can also place the phone in a geographic area, but the phone may not store that detail, and you’ll need a warrant to get the records from the wireless carrier.

If you find one bit of evidence, don’t stop looking. You will need more than one data point to convince people.


Should I let my child's school have access to my kid's personal laptop?

It might just be because I am already "that parent", but it would be a strong NO from me - and the school administration would get a strong talking to about this. I would push to have that policy changed (though without much hope), for everyone and not just my own child.

There are privacy issues. Security issues. Potentially legal issues - is the software licensed? Cracked? Are they logging all traffic from the laptop, or more? Do they want to install custom software?
And, why are they even asking for all this? What justification could they have.

They want to ensure the children are safe online.
Fine, require some form of parental control. It's your laptop, it's your child - it's your responsibility. (E.g. my son's school requires content filtering on smartphones brought into school. They "demand" some dodgy app by a local fellow. I declined and installed a proper app.)
They want to ensure children's laptops are secure.
Great, first lesson "how to stay safe online". Require Windows Defender (or some other AV/AM) is active and updated, etc. Though this really shouldn't matter to their network...
They want to ensure children are not accessing illegal / inappropriate sites.
First of all, it only concerns them inside/during school. None of their business at home... And they can easily set up a locked down proxy for the school network.
And again, at home they should still have the parental control / filtering software anyway.
They want to educate your children.
Oh do they? Because this sounds like the opposite of that. This is an educational opportunity, a veritable goldmine for several topics, and they are going the other way.

You might need to discuss with the teachers, the principal, the school board... You might need to reeducate them about this. And you might even lose, but fighting this is the right thing to do - as @Mike and some of the commenters mentioned, best chance to teach your kids about safeguarding your own privacy and preventing onerous demands from misguided authority. :-)


Should I be worried about brute-forcing passwords that encrypts AES?

.. encrypted using the sha256 of a password provided by the user.

You should not use a simple hash to create the key from the passphrase. These hashes are optimized for speed and thus brute-forcing is possible. Instead you should use proven key derivation functions like PBKDF2 or similar. See the Wikipedia article about Key Derivation Functions for more details.


How to store ECDSA public key securely in Android

You really do not need to worry about that, that is the reason its called public key. You should instead seek to secure your private key, because its the key you actually use to sign the data and it is only required to use the public key pair to verify the signature on the data. If an attacker uses another public key that is different from the one that was generated with your private key, it will fail verification. What you should worry about is if the attacker could de-compile your application and by-pass the logic for verifying the data/document.
And to handle your tampered (re-compiled) android application concerns, you can ensure any application that is making a request to your server comes with a token in the request header that was generated using the application signature as a salt. This signature can be generated from calling some android API's that retrieves and computes the key you used to sign the app during release/debug build (release build should be ensured). So if an attacker de-compiles your app and re-compiles it again, definitely your previous signature has been invalidated as the attacker would be forced to use a new key to sign the app. This time if this modified app calls an endpoint from your reverse engineered app, it would generate and send a token different from the original one. So from here you simply block the IP or just respond with code 401 from your server since the token in the header does not match what you are expecting.
This time, you need to secure the keystore file that you used to sign the app when you were building a release version. Don't track your keystore file with a versioning system like GIT in your code base, because once this file is in someone else's possession not in your organization, then the previous security implementation is screwed once an attacker gets hold on it. I hope i have been able to clarify some concerns of yours. Good luck


How are SSDs different from HDDs from the privacy point of view?

We have a whole bunch of questions on the difficulty of wiping data from SSD's. You should have a good browse round this site.

Simple answer is:

By default, SSD's leave more data on the drive. This is because of wear leveling - overwriting doesn't exist as a concept in the same way as on a physical platter. That said, there are known solutions, the most common being the use of whole disk encryption as a way to wipe the drive, by just forgetting the key.


evidence collection in incident response

In an security incident response situation, incident containment should come before evidence preservation. To give you an example, imagine a hack at your company. You would want to limit the ability of the hacker to compromise your company's system any more than he already did.

Only after the incident has been contained, would evidence preservation come into play. It is extremely important to preserve the integrity of the evidence such as dates/times , user logins etc... when collecting relevant data.


Is there a way to notify me when my Android phone connects to an unencrypted GSM network?

In case you are not aware, many people have considered GSM security to be weak and there are freely available rainbow tables for decrypting GSM. Any determined eavesdropper with off the shelve equipment will be able to listen to your calls.
You might be interested in reading this Are phone calls on a GSM network encrypted?

But if you are worried about the security of your calls, it should be safer to use Skype instead :)


Getting rid of a large quantity of paper

The worst thing you can do is tearing them apart. It's time consuming and attacker just needs extra time and patience to put pieces together.

The same rule applies for shredding - if after shredding are left too large pieces, again, attacker just needs time and patience.

There are several shredding techniques (from wikipedia)

  Strip-cut shredders, the least secure, use rotating knives to cut narrow strips as long as the original sheet of paper. Such strips can be reassembled by a determined and patient investigator or adversary, as the product (the destroyed information) of this type of shredder is the least randomized. It also creates the highest volume of waste inasmuch as the chad has the largest surface area and is not compressed.
  Cross-cut or confetti-cut shredders use two contra-rotating drums to cut rectangular, parallelogram, or diamond-shaped (or lozenge) shreds.
  Particle-cut shredders create tiny square or circular pieces.
  Cardboard shredders are designed specifically to shred corrugated material into either strips or a mesh pallet.
  Disintegrators and granulators repeatedly cut the paper at random until the particles are small enough to pass through a mesh.
  Hammermills pound the paper through a screen.
  Pierce and Tear Rotating blades pierce the paper and then tear it apart.
  Grinders A rotating shaft with cutting blades grinds the paper until it is small enough to fall through a screen.

Also, there are several standards for shredding (from wikipedia)

  Level 1 = 12 mm strips OR 11 x 40mm particles
  Level 2 = 6 mm strips OR 8 x 40mm particles
  Level 3 = 2 mm strips OR 4 x 30mm particles (Confidential)
  Level 4 = 2 x 15 mm particles (Commercially Sensitive)
  Level 5 = 0.8 x 12 mm particles (Top Secret or Classified)
  Level 6 = 0.8 x 4 mm particles (Top Secret or Classified)

What I'm trying to say is - it's not about - "Let's torn this paper and we'll be fine!" It's about how hard is to put this pieces together. If it's next to impossible, then shredding is done well.
However, if attacker is aiming for the lowest hanging fruit, then any kind of shredding is better then none.

Example of well done shredding (once it was a money)

I guess setting them on fire or destroying them in chemical reaction would be the fastest, but this techniques should only be preformed in controlled environments by professionals!!!
Alternative is to decompose paper in water, however, it's pretty long process (10-14 days) and you'll need enough space and water to do so.


If you are injecting both fields at the same time:

Think about the SQL string with the replaced text:

"SELECT * FROM users WHERE userName='$usr' AND password='$psw'  "

becomes

"SELECT * FROM users WHERE userName='' OR '1' = '1' AND password='' OR '1' = '1'  "

Can you run that query from a SQL prompt and get a response? I think you might find that the logic flow with all those ANDs and ORs will trip you up.