To clarify I think you are asking about consumer grade home broadband routers with built-in wireless (802.11a/b/g/n), right?

Out of the box, you are going to have a very difficult time proving any kind of intrusion using these devices.  Besides the fact there is nothing authenticating your valid users.  How would you distinguish between legal and illegal users?

For tampering, you would need to have a snapshot of the device and configuration when setup to compare against it after it has been tampered with.


Using a https Website will my ISP see to which IP i am connecting?

tl;dr: Yes. You need to use a proxy or VPN to hide the destination of your traffic forom your ISP.

The Long Version:
As described in this section of the IPv4 Wikipedia article, IP packets have a header section and a data section. The header section contains, among other things, the Source IP Address and Destination IP Address fields. These fields are essential to facilitating the communication between the source and destination, so encrypting them would make it impossible for the source and destination machines to communicate. SSL only encrypts the contents of the data section, though not the entire contents -- there are a few more layers of protocol headers before you get to SSL (see the OSI model for more on that).

That said, the source and destination IP addresses in an IP packet may not be the final destinations on either side of the underlying communication. The data section of the IP packet can contain another IP packet (or a different protocol) to be unwrapped, interpreted, and transmitted by the recipient in accordance with a VPN or other proxy solution.

To hide the IP of a site you are visiting, regardless of the presence of HTTPS, you would need to use a VPN, proxy, or other anonymity service (such as tor) to make the connection.


How to explain importance of security & privacy to a layman?

Information security is a technically complex topic and it is largely invisible. You can see a door lock, and see a burglar, and see and understand the loss of your TV, but one cannot see or understand what it means for a database of password hashes to be accessed by an unauthorised person.

I found my greatest successes by communicating the end risks simply ("your email account is a doorway into your bank account") and tying the risks to something the person cares about.

The key here is not just "you have to understand the importance", but understanding exactly how it is important to them. An academic approach is doomed to failure for most people.

So, the analogies you use have to be tied to your audience.

I once taught security awareness to the claims department call center of a large insurance firm. The people were not insurance professionals, but just average people taking calls all day from people who have just had an accident or some other form of major or minor personal disaster.

It was difficult to "get them to care" until I made a single simple statement: "you deal with people on what might be the worst day of their year or even their life - don't make it worse by exposing their personal details to hackers or inadvertently infecting them with a virus." THAT was something they cared about, and suddenly they were interested to know what they could do to not make someone's bad day worse.

So, you have to understand that you can comprehend this stuff at a level that others simply won't be able to. Your job is to empathise with your audience and make it "real" for them where they are.


John 1.7.9 with Jumbo patch 6 has you covered. From: http://www.openwall.com/lists/john-users/2012/06/29/1

New hashes:
* IBM RACF [OpenMP]  (Dhiru)
  - thanks to Nigel Pentland (author of CRACF) and Main Framed for providing
  algorithm details, sample code, sample RACF binary database, test vectors
* sha512crypt (SHA-crypt) [OpenMP, CUDA, OpenCL]  (magnum, Lukas, Claudio)
  - previously supported in 1.7.6+ only via "generic crypt(3)" interface
* sha256crypt (SHA-crypt) [OpenMP, CUDA]  (magnum, Lukas)
  - previously supported in 1.7.6+ only via "generic crypt(3)" interface


Hotel reservation. How is this secure with only credit card number and expiry date?

Booking.com doesn't take a deposit or any payment from you; what you're filling in is a reservation form. The card details are used as a form of payment identity in case (a) you don't turn up and they need proof you intended to stay, or (b) you stay and run off without paying when checking out. They hotel still requires a present card for payment, or the CVV to do a card-not-present transaction, or cash if you choose to pay that way instead.

The bigger question of "is this secure" is more complicated. The simplest way to think about it is that there are a number of security controls in place to help prevent fraud, at various stages in the process (website, payment processor, bank), but even if these all fail the bank is insured against fraud, so you will get your money back if you use an appropriate card type. In general, credit cards offer superior and faster fraud protection in comparison to debit/bank cards.


Flash Drive: Is it possible to figure out what/when files were added?

No. The flash drive itself does not have its own concept of time and has to rely on the time being given to it by the host computer. This link has good information on how to detect some date forgery but a sufficiently skilled attacker would be able to plan for this (Note: the link refers specifically to NTFS, so if your flash drive is a different format your mileage may vary).

If you believe the device could have been tampered with the absolute safest thing to do is either format your existing one, or throw it away and get a new one.


What's the point of EMV when only the card is needed to shop online?

Thats what the VbV and Mastercard SecureCode solutions are for (also known as 3D Secure)

With merchants that implement these solutions, a secondary password, or a OTP is required to complete the transaction. This secondary password\OTP is entered on the banks site and not on the merchants site.

This PDF describes the system (and its limitations)


HSTS on a subdomain with includeSubdomains

Based on the RFC, HTTP Strict Transport Security (HSTS), the includeSubDomains states:

  6.1.2.  The includeSubDomains Directive

  The OPTIONAL "includeSubDomains" directive is a valueless directive
     which, if present (i.e., it is "asserted"), signals the UA that the
     HSTS Policy applies to this HSTS Host as well as any subdomains of
     the host's domain name.

Therefore your HSTS policy would only apply to foo.example.com and *.foo.example.com

example.com and bar.example.com would not be impacted.

For more info, there is a great thread on webmasters titled Do I need a wildcard SSL certificate for inclusion in the HSTS preload list?


Antivirus constantly detecting tmp files as threats

I can't comment yet, so i'm posting this as an answer:

This looks like a Trojan which is running in memory. Please, include your TaskManager process list from all users (or preferably with Process Explorer) and try to find a process running from a weird place (like C:\Users\YourUser\AppData\Local\Temp\ ). Kill the process and delete the file. You can try to catch it by monitoring your running tasks for disk writes with both programs.

Also use Autoruns to find which programs are automatically executed when you turn on your machine. Disable those which are completely rare (just be careful not to disable a useful program).

Also you can try to log on "Safe mode" and run Disk Cleanup (sometimes trojans are stored on temp folders). You can manually clean temp folders too (C:\Users\YourUser\AppData\Local\Temp\ and C:\Windows\Temp\ )

If all previous fails, uninstall and reinstall Chrome. Hopefully that will delete the autorun tasks Chrome might have.

After all, if your problem persists, try using another web browser (like Firefox or Opera). Sometimes trojans can setup autorun tasks based on a specific browser.

Also try to include the name of the trojan/virus your antivirus is detecting.

Sometimes it's an art to catch those pests and delete em.


Is Chrome in Metro Mode more secure than Chrome in Desktop Mode?

The difference in sandboxing is not important. Chrome already allows NO access to the file system in its regular mode. You don't gain anything using appcontainer as opposed to integrity levels once you hit 'untrusted'.

I don't believe the Broker process in Metro mode is any more confined, therefor you still have a privileged broker (medium integrity/ same level of access) and an unprivileged renderer (no access in either sandbox).

Functionally, there should be no significant difference, even if the sandbox is implemented slightly differently.

edit: Some notes, because I do not have enough rep to comment:

When it runs in Metro you do not get a "double sandbox". You get the same sandbox implemented through appcontainer instead of integrity, and you get the same user tokens, etc, that are always implemented.

@Avid - "Browser sandbox != operating system sandbox... "

As a matter of fact, "browser sandbox == operating system sandbox". The operating system provides virtually all of the functionality for the sandbox - integrity levels and appcontainer are a Windows feature, not a Chrome feature.


Listing technologies/languages in LinkedIn Project History a Security Issue?

No, not really. In most cases it's not difficult to work out the language/tech used for a particular site or application anyway. Doing your best to hide it would just be security through obscurity. Maybe people will find it a little easier to ID the language/tech used in your projects if you tell them, but they'd find it anyway.


Most (all?) of the cards require a PIN and are designed to lock themselves after multiple failed attempts, so physical access to a card is pretty much useless without knowing the PIN as the cards are designed to be tamper-proof. So far I haven't heard of any way to extract the secrets using a hardware-attack in a real world scenario.

A keylogger on a machine will indeed capture the PIN if you're entering it into an application on the computer. That can be mitigated by using a reader with a hardware keypad and entering the PIN on that keypad. That way the PIN never reaches the computer and even a compromised machine won't be able to capture it. All credit card terminals you use when paying are, at the very least a reader like this one (but often are full-featured computers that handle the entire transaction themselves) so the POS system never gets your PIN.

A keylogger will never be able to compromise the card's secrets, as the cards are specifically designed to never reveal them, it will however compromise the PIN and any data you encrypt/decrypt with that card or token.


Redirection the user after a successful login is common in the most webapps.
For instance when the user try to access the dashboard directly within its url, the system keeps the requested url and brings the user to the login page, after user signed in he is redirected to the dashboard not the homepage or something.


John the ripper - ecryptfs - sample not cracked: 0 password hashes cracked

The tar file needs to be extracted first. It contains an .ecryptfs directory as it would typically be found in an encrypted home folder. The relevant file here is the wrapped-passphrase file. It contains the "real" 32-character password that ecryptfs used for the encryption, and is itself encrypted with the user password.
To use john on this file, you first need to create a passwd-like file from it that john can understand. For this use the command ecryptfs2john wrapped-passphrase > passwd. The ecryptfs2john command is contained in the John the Ripper jumbo package. The command creates a passwd file that looks like this:
wrapped-passphrase:$ecryptfs$0$92dc3db8feaf1676

Now you can use john on the passwd file:
$ john passwd --progress-every=10 --mask='openwal?l'`
Using default input encoding: UTF-8
Loaded 1 password hash (eCryptfs [SHA512 128/128 AVX 2x])
Will run 4 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
openwall         (wrapped-passphrase)
1g 0:00:00:00  4.347g/s 113.0p/s 113.0c/s 113.0C/s openwala..openwalq
Use the "--show" option to display all of the cracked passwords reliably
Session completed

As you can see, john recognized the hash as an ecryptfs hash. In some previous attempts, it was not doing that but was rather showing something about different hash types being detected. Unfortunately, I cannot reproduce this now, so I don't know what exactly was causing it. I had the impression that I was either using a version of john that didn't include ecryptfs support, or that it only worked when I was running john from the directory where the wrapped-passphrase file existed, but with both scenarios I cannot reproduce the problem anymore.


Solely from the information in your question, narrowing down that list of 86 is not going to be easy - I had a quick flick through as I know a fair few of the top names. Some points:

SIEM solutions should all be able to run log correlation type activities
Most include device insertion logging and Tripwire type checks (or can incorpoprate Tripwire or any other SYSLOG logs)
Most of them have reasonable user interfaces
Most have scriptable command line interfaces

What you should do is list out the things you do want/need it to have and select on those items. If you can get it down to under ten you have a much better chance of being able to run comparison tests.


Is it more secure to limit passwords that have two identical characters in a row?

The link you shared says:

  not more than 2 identical characters in a row (e.g., 111 not allowed)

so your limit would apply on 3 characters in a row.

Remember, any limitation enforcing a certain rule reduces the absolute search space for a password. For example, requiring four different types of characters removes the space for all-lower/all-upper/all-digits/all-special character passwords.

The hope with any such restrictions (3 consecutive identical characters / 3 consecutive digits / 3 consecutive digits plus a special character / 3 consecutive QWERTY keys ...) is to reduce the likelihood of users choosing a weak password (one that is more likely to have been already "discovered" and added to a rainbow table).

The benefit may not be apparent if you think of password-cracking as "dumb brute force", but may be clearer if you look at the proportions of cracked passwords from a large dataset that display these weak characteristics.


What information can my ISP see when I visit a website?

The ISP

can see GET and POST Parameters of websites that don't use SSL
can see DNS requests (-> which domains did you visit)

So in your example the ISP would not see the search request as GET Parameters are encrypted with SSL (ref).

Conclusion: the ISP would know THAT you searched on Google but it wouldn't know WHAT you searched for.


What can a hacker do when he has physical access to a system?

To focus on your individual cases:

Absolutely anything he wants. Malware, rootkits, backdoors, keyloggers, the whole shebang.
Again, absolutely anything. It's exactly the same as having the USB disk, because he can set up a site where he can download the files he needs, or just download them from existing sites.
Wipe the disk, delete system files, write batch files, modify system services, alter configuration, etc. The list is endless. There are a lot of malicious things you can do to a system without extra tools. It'd be trivial to write a VBScript to check the current date, compare it to a fixed value, then break the system if the dates match. Drop that into a run key and you've got instant repeat business.

In the first two cases, malware enables him to have full access to the box at any time. In the third case, it's still trivial. He could set up a hidden account on the machine, which he later uses for remote desktop. He could set up remote assist. Depending on which version of Windows the user is running, he could set up terminal services. He could even uninstall security patches to enable a remote code execution vulnerability, then exploit it from home. It's really not that difficult to make a machine like that remotely compromisable.


There are common defects in authentication systems that should be avoided:

In a corporate environment it is important to terminate
authentication immediately.  If an employee is fired they could seek
revenge,  and even a narrow window of access cloud be enough to cause
serious monetary loss.
Bruteforce.  There must be a system in place to rate-limit authentication requests coming form a specific ip. Blocking requests until an IP can solve a capthca is a good approach that is used by Google and others.
Leaking information over an insecure channel.  This is mitigated by TLS (or HTTPS).  TLS has its own problems and is always misconfigured by default.   Make sure you are using secure cipher suites (TLS V1 or later) and disable renegotiation requests.  Any vulnerability scanner worth its salt will show these violations, and they are a common finding in the wild.
Injection and Authentication Bypass. Make sure you understand LDAP Injection.

Forcing every request to contain a username/password solves the first problem of immediate termination.  If every request has to be sent to Active Directory then there is only once place to revoke access.  LDAP is a very fast non-relational database and filter requests are very fast (much faster than SQL).


On-line cryptographically signed date/time?

I think you could use any web site operated by a reputable company that supports access over SSL. The one quirk is that the list of certificate authorities that might sign their certificate could change.

For example if you retrieve https://www.google.com/ you'll get something like:

HTTP/1.0 200 OK
Date: Tue, 06 Dec 2011 17:02:40 GMT
Expires: -1
Cache-Control: private, max-age=0
Content-Type: text/html; charset=ISO-8859-1
...

Notice the Date header right in there?

If you're paranoid, you might want to maintain a list of possible web sites to access, just in case something happens to one of them.


You are asking the wrong question. EMP and "magnetic stuff" is not your true concern.

First, "EMP/magnetic stuff" will not wipe your harddisks, unless something really unexpected happens, such as a nuclear bomb going off in the stratosphere (and that will likely destroy the circuits, but not likely wipe the platters), or you putting the harddisk onto an induction cooking plate, or similar things. In which case you have more serious stuff to worry about anyway.

Even placing a harddisk in immediate proximity of a strong permanent magnet for several hours (I've actually done that by accident!) doesn't seem to affect it in any significant way, although I wouldn't know what the effects might be if you put your harddisk between two layers of neodymium magnets for 5-10 years.

A "storage facility", such as a shoebox on a table placed in an otherwise empty, closed garage, provides enough protection against any "magnetic stuff" that might reasonably occur.

The actual problem: Harddisks are not made for long-term storage, and they are definitively not made with zero failure rates. You should reasonably not expect a harddisk to store your data reliable for longer than 5 years. Yes, there exist harddisks from the mid-1980s that still work today (I own one of these), but that's anecdotical and meaningless since they have practically nothing in common with present-day devices.

Typical rates of failure (numbers vary, depending on whom you ask) are around 5% per year within the first two years and around 10% per year thereafter.
Typical unrecoverable sector failure rates on consumer drives are specified as 1 in 1014 bits, server-grade disks having 1015 instead. Those are lower bounds as specified by the manufacturer (and no guarantee of failure), but still.
With a typical present-day disk having around 1013 bits, this means that if you fill such a drive to its full capacity, there is roughly a 50% chance that at least one sector may be unrecoverable.

There exist better media for long-term storage. M-Disc promises 1,000 years of lifetime, and while those 1,000 years are almost certainly a false promise, you probably won't live to tell a difference. If they live 50 years, that's mighty fine. You need an extra powerful writer to burn them, but every normal DVD player can read them.
Since earlier this year, these exist in blu-ray format, which should give enough capacity to hold your most important stuff "forever". Verify the disc after burning, and better burn two of them to be sure, put them into a wooden box inside a rockwool bed inside a steel box (to protect against the casual storage facility fire), and keep that box locked in your storage facility, door closed. Best put a shrink-wrapped DVD reader in there too, just in case they don't make them any more in 50 years.
Unless a nuclear bomb explodes or you fail to pay the rent for your storage room, your data will live longer than you.


How do I convert a GPG certificate to a CRT certificate that can be imported into Windows Certificate Manager?

Short answer: you can't, because they are two different and incompatible key+certificate systems.

Longer answer:

Windows Certificate Manager uses X.509 certificates, each of which
must be signed by a Certification Authority whose root certificate is
considered valid by Windows. Thunderbird will use the public key
stored in your recipient's certificate to encrypt content.
OpenPGP and GPG use their own certificate format that is unrelated to
X.509, and use their own encryption and signing mechanisms which are
incompatible with S/MIME.

SSH is unrelated to either, so of no help to you.


What is the difference between antivirus and firewalls

Firewall and antivirus software are two fundamentally different and complementary kinds of security applications.

Firewall :

Also known as a 'packet filter'. Basically, software which monitors network traffic and connection attempts into and out of a network or computer and determines whether or not to allow it to pass. Depending on the sophistication, this can be limited to simple IP/port combinations or do full content-aware scans.

A firewall can be thought of as a screen or sieve that categorically strains out potentially harmful data.

Antivirus:

A software which will find programs/files/software/etc that might compromise your computer, either by being executable or by exploiting a vulnerability in the program normally supposed to process them -- Rootkits, trojans, or other types of malware.

It detects these kinds of harmful programs that are already installed on your computer or about to be installed.

It can perform various protective measures (based on the security settings in the Anti-virus software) such as quarantine, permanent removal, fix, etc.,

It will also look for potentially harmful files that are downloaded from the internet or attached to an email and notifies/removes it to protect your computer.

NOTE: Antivirus software has to be updated frequently; each new strain of virus will likely have different signatures.


Should both user ID and Password be masked for online banking?

Best practice says that a username should be something that can be considered public information and thus doesn't need to be protected.  The fact that they find the username needs to be protected either means that a) they are doing something counter to best practices that makes it need to be kept secure or b) they are engaging in some security theater to make people feel more secure about their account and possibly make shoulder surfing minimally more difficult.

I can't see how it would give any real benefit as the password is already masked and thus, unless the keys are being logged or the keystrokes recorded.  If they are able to get the fully masked password, then they will also be able to get the fully masked username.

One measurable gain I suppose I could see would be if they cache the username.  This would mean that if you are accessing your bank account in a public place, the username could be displayed, already entered and masked, such that a shoulder surfer would only be able to get the password and not the username.


To make a random, unbiased shuffle, you apply the Fisher-Yates algorithm. If you want to shuffle an array x of n elements (numbered from 0 to n-1), you do this:

for all i from 0 to n-1
    let j = rnd(n - i) + i
    swap x[i] with x[j]

where rnd(k) means: generate a random uniform value in the 0 to k-1 range. Note that it may happen that i = j in the loop above, meaning that you may swap an array element with itself. This is normal, and needed for proper uniform selection of a permutation.

Your problem, then, is how to convert a stream of random words into random selections in a smaller range. sjcl.prng.randomWords() returns an array of 32-bit words, i.e. values in the 0 to 232-1 range. If you simply divide a word value by k, and keep the remainder, then your selection is biased. The trick is to reject part of the range, so that the rnd() function looks like this:

rnd(k):
    while true
        let z = next-random-word
        let r = z mod k
        if z - r + k <= 2^32
            return r

For instance, if k = 37 (you want a random unbiased integer in the 0 to 36 range), then you generate a random z. If that value z falls in the 0 to 4294967288 range, then you just reduce the value modulo 37, and you have your random integer; this is unbiased because 4294967289 is a multiple of 37. However, if z falls in the 4294967289 to 4294967295 range, you have to try again with another z.

(Mathematically speaking, some sort of loop is unavoidable when k does not divide 232. The risks of looping many times are negligible, though.)

I don't know exactly what you need your shuffle for; if that is for generating a "password" then doing a shuffle of printable characters from 33 to 126 (the ASCII printable characters, excluding space, thus 94 values) is weird, because there is no law against using the same character twice in a password. In fact, forcibly preventing the same character from appearing twice in a password reduces the space of possible passwords, and thereby reduces security. To generate a random password, it is simpler and also better to produce each character randomly and independently of the others; fiddling with permutations and shuffling is just unnecessary complexity (and complexity is known to be, in general, harmful to security by itself).


How the salt and the password are mixed together has no importance whatsoever IF the hash function is "perfect" (i.e. is a random oracle). However, perfect hash functions don't really exist; we don't even known if even "slightly imperfect" hash functions can exist at all (functions which are not random oracles but still guaranteed to be preimage-resistant). Practical hash functions have "quirks" which relate to their internal structure, and must be avoided by taking care of how the input is prepared. It is extremely hard to tell which way to combine password and salt is better, so the normal way is to leave it to trained cryptographers. These people have come up, after decades of work, with some constructions which seem to be strong, and it is improbable that a lone developer could come up with something significantly better by slapping together one or two functions.

In any case, even if your method of mixing the password and the salt is good (it may be good, but it is hard to know for sure), your function is still way too fast. You should have thousands or even millions of nested hash function invocations here, because a password hashing function ought to be inherently slow. See this answer for a complete treatment of the question.


Security Review - password_hash implementation for PHP

In C, I usually recommend that you should be consistently using size_t to store all length values, not int or long.  Using int and long exposes you to integer signed/unsigned bugs.  Reference: INT01-C from the CERT C Secure Coding Standard.
However, there is a complication in this case, due to the way the PHP native code interface works:

When you read an integer using zend_parse_parameters(), PHP expects you to store it in a long.  Therefore, you should pass zend_parse_parameters() a pointer to a long, then convert the long to a size_t carefully: validate that the number is non-negative and falls within the range for size_t (l >= 0 && l < SIZE_MAX), then cast it to a size_t and use a size_t thereafter.

When you read a string using zend_parse_parameters(), PHP expects you to pass a buffer to store the string and a pointer to an int to store the string length. Therefore, you should pass zend_parse_parameters() what it is expecting.  Then, carefully convert the int to a size_t: validate that the length is non-negative and falls within the range for size_t (len >= 0 && len < SIZE_MAX), then cast it to a size_t and use a size_t thereafter.
Similarly, Z_STRLEN_PP() returns an int (I think) so you'll probably want to do the same for it.

(Beware of passing a long as a length to memcpy(); I don't know for sure, but that code smells pretty dubious to me and of high risk for an integer casting/truncation bug.)
buffer = php_base64_encode((unsigned char*) str, str_len, NULL);
for (pos = 0; pos < out_len; pos++) {
    if (buffer[pos] == '+') {
         ...
    } else {
         ret[pos] = buffer[pos];

That looks like it could read past the end of buffer to me.  I think you need an additional check to make sure that pos is smaller than the length of buffer.


Why use XOR or OR operator for "bypass" a conditional jump

We are now at the JNS instruction. This means Jump Short if Not zero
  ...
  So lets go back to where the JNS instruction was and unset the SF flag
  so the jump gets executed. SF is the 7th bit in the register so in
  order to cancel it we need to xor with 2^7 = 128

There's actually an error in the first sentence here, JNS means "Jump if Not Sign", i.e. jump is taken if sign flag is not set. The following logic is valid: he decides that he wants the jump to be taken since otherwise the program will exit. So the sign bit should be cleared.

As he says, the sign flag is bit 7, a xor with 128 (= 2^7, or 0b10000000 in binary) will flip it. (the result of a xor is 1 if exactly one of the input bits is 1.) Since he checked just before that the bit was set, there's no risk of accidentally setting the bit. Generally one would and with the inverse (i.e. 127, or 0b01111111) to clear the bit. (result of and is 1 if exactly both inputs are 1.)
Wikipedia among others has truth tables for the logic functions.

In the second case, the bit at position 6 needs to be set, and or with 64 (= 2^6, or 01000000) does it. (result of or is 1 if at least one input bit is a 1.) He could have used xor to toggle it too, but that would again require checking if the bit is set first.


Is it possible to use Captive Portal for WiFi and WPA2-EAP at the same
  time?

Yes is absolutely possible

  How to achieve it?

In General it is achieved by giving wall gardened access to user even if he and successfully authenticated EAP authentication , it is called chaining eap authentication with webauth , i have done this is cisco wlc and free radius environment quite easily

  Is there any EAP supporting Captive Portal ?

Coova offers this functionality with its very basic version which can be found at

http://coova.github.io/CoovaChilli/WPACaptivePortal/

for over view the request and respose of Radius is as :-

Access-Request packet from host 192.168.100.200:2084, id=14, length=171
    User-Name = nobody
    EAP-Message = 0x020200061900
    ChilliSpot-Config = allow-wpa-guests
    Calling-Station-Id = 00-11-24-90-XX-XX
    Called-Station-Id = 00-06-25-C5-XX-XX
    NAS-Port-Type = Wireless-802.11
    NAS-Port = 1
    NAS-IP-Address = 192.168.100.200
    NAS-Identifier = 00:06:25:c6:xx:xx

    .. EAP Access Challenge/Request and TLS Termination ..

 Sending Access-Accept of id 19 to 192.168.100.200 port 2084
    ChilliSpot-Config := require-uam-auth
    MS-MPPE-Recv-Key = 0x317f2c50e739bd69d14be1d09ec111abe3f562886879b70eee16395637dc5eb5
    MS-MPPE-Send-Key = 0xcbc74e30dce41c343b4afe0ea90b7a6413b659bba3a330bcd265da9df4e85ae7
    EAP-Message = 0x03070004
    User-Name = nobody

Hope this will help you


Why would a switch be configured to Fail Open?

...because a switch is a Connectivity device, not a Security device.  It is designed to enable communication, not to secure the network.  That design bias emphasizes availability over security in situations where both are threatened.

Much pain would be avoided if people would remember that when designing networks.


Does revealing part of your hash give an attacker advantage when attacking your password?

TL;DR: The answer depends on the hash algorithm, what part of the hash is revealed and the strength of the password.

Assuming that the hash algorithm is known the knowledge of a specific part of the hash might make brute force attacks easier: The attacker might now run most brute force tests offline and also in parallel and is thus not restricted by rate limiting or even account locking after failed attempts which is (hopefully) in place to deter massive brute forcing.

How much easier the attack gets depends on the hash and on the strength of the password though. If the hash algorithm is slow (as recommended) then brute forcing will be slow too. If the password is weak enough such offline brute forcing will still likely be successful too. In contrast: if the site implements a wait time after each failed login attempt or maybe even locks the account then online brute force attacks will often fail even for weaker passwords.

How much easier it gets depends also a lot on the type of hash and which parts are revealed. If the attacker does not know the salt which was used in hashing (and which is commonly stored as part of the hash) then brute forcing is nearly impossible - provided that the salt is chosen from a large enough random pool.


Looking for botnet IP address feeds to protect against DDoS

I guess something should be noted on the botnet and DDoS.

The main interest of the distributed system of the botnet, is that you cannot identify a bot from a genuine client.
Think of it like this:

Scenario

Someone infects many computers by sending a virus. Each tricked user is now part of the so-called botnet. Let's say you have 100M bots.

Consequences

IP address usage

This scenario implies that the IP addresses of the bots have dynamic or static IP addresses depending of their ISP policy. So collecting IP addresses is worthless. Soon or later, the pool is going to be renewed.

Distributed network and identification

DDoS works this way: you will ask each bot to connect to one server.
Question: How do you know if they are trying to access your server for a legit purpose or just to saturate your connection pool?

Given this, as you can't identify whether a client is part of the attack or not, you cannot compile a reliable list of IP of the distributed network.

Conclusion

Although is it not impossible, I think that the prevention of DDoS attacks by IP is not possible because of the two exposed challenges: use of a real identifier (IP address) and identification of bots.

Maybe if a group of servers would report attacks on live to a master server, it is more than probable that the next attack from that set of bots will have different IP addresses. Furthermore, you cannot deny access to your site if an IP appeared once in the list of one address that tried to access one server know to have suffer a DDoS attack, because you will ban legitimate clients that do have nothing to do with the attack.

By the way, I never heard of such a list.

TOR network exit node are more easily identifiable. Some resource like http://proxy.org/tor.shtml


Client IPSEC VPN Key Exchange vs. Site to Site IPSEC VPN Key Exchange

There is no need for a key exchange, that typically applies to SSL/TLS protocols (and such). VPN's often use preshared keys. Sometimes (OpenVPN) you can define a DH keyfile but only for the ephemeral key exchange that takes place after the connection is established, this enables forward secrecy.

Update

There are VPN's that do a key exchange, IIRC both Cisco and Dell support this in their Enterprise VPN products.


"Public facing" dropbox folder uploads to admins machine. Potential security issues?

Yes, that is very dangerous. Because the attacker is able to place a file directly on the disk simply viewing directory contents can infect the machine. For example:

I assume that computer syncing with dropbox is running Windows. Windows shows preview Images for all files (e.g. Word documents, text files, images, ...). Those are generated based on the contents of the file. Any file can exploit a vulnerability in such a thumbnail-generator when the user opens the directory in windows explorer.

In addition to that, all security risks that apply to email attachments also apply to this scenario (malicious Word macros, etc..)


For anti-CSRF, isn't a session id cookie in a hidden form field easier than a random token?

I can't tell if you independently re-invented double-submit cookies and didn't think anybody'd thought of it before, or just didn't do any research on a well-known topic. https://duckduckgo.com/?q=double+submit+cookie+weakness&ia=web has no lack of results, including some from this very site (see Double Submit Cookies vulnerabilities and Is the double submit cookie pattern still effective?).

Your approach is slightly novel in using the session cookie (which you seem to think is distinct from an "authentication" cookie; I'm sure there exists a site that separates those but they're generally the same thing). The problem is, then you're exposing the session cookie to script (either via the DOM or by making the cookie non-httponly). This isn't the end of the world; indeed, it's pretty common to pass your session token as an HTTP Authorization: bearer header value that is set by script and avoid cookies altogether (this has the added advantage of being inherently secure against CSRF, since the browser won't automatically forward any authorization data; the attacker would need to already know it in which case they could submit the request directly). Also, by the time the attacker can read your DOM or document.cookie, there's a ton of other nasty stuff they can do; the httponly flag is a really minor patch.

A refinement of this pattern is to use a cryptographic hash of the session token, stored either in the DOM (usually in a hidden form field) or in script-accessible data somewhere. It can be a keyed hash (such as an HMAC), but honestly it doesn't need to be; the attacker won't be able to reverse the hash anyhow, and if they have the session token already they don't need to generate the hashed value because they can just send a GET request and the server will send the value back.

Normal double-submit cookies are weak as a CSRF mitigation because there are ways to plant a cookie, especially if the target site doesn't use HSTS. If the attacker can plant their own anti-CSRF cookie value, then they can successfully forge requests from the victim's browser by including that cookie value in the body, too. Using the session cookie works around this - the attacker can still overwrite it, but then they've de-authorized the victim's browser which kind of defeats the point of CSRF - but adding a single round of SHA-256 or similar on top of the session cookie lets the actual session cookie value remain invisible to script.


How do cert authorities set and determine subjectAltNames if not provided by end user?

A CSR is nothing more than a (signed) proposal of what kind of certificate you want to have. It is actually not really needed to create a certificate, i.e. a certificate could be created completely without having a CSR first.

The CSR proposal contains the public key which should get included into the final certificate and it contains things like subject, subject alternative names etc which propose to add to the certificate too. The CSR is signed with your private key so that the CA can verify that you actually own the private key matching the public key of the certificate.

The CA takes the information from your CSR which it likes when creating a certificate and also adds many information by its own, i.e. not taken from the CSR. It will take the public key from the CSR. The subject it adds to the certificate will probably be based on your CSR proposal, but it might also modify it, add subject alternative names you did not add (i.e. might add www.domain) and exclude others which you've tried to sneak in etc. It will also add start and expiration time, AIA (like URL for OCSP requests), issuer information, certificate purpose ... - and most of these will not be taken from the original CSR.

  Basically I am attempting to act as my own CA using OpenSSL (1.1.0i)

I'm not sure if and how one could use the openssl tool to create certificate hierarchies without CSR but one can definitely do this with the OpenSSL library. For example I regularly create test certificates with root, intermediate and leaf certificate like this in Perl without needing any CSR:

use strict;
use warnings;
use IO::Socket::SSL::Utils;

my @root = CERT_create(
    subject =>  { CN => 'root' },
    CA => 1,
);
PEM_cert2file($root[0],'root-cert.pem');
PEM_key2file($root[1],'root-key.pem');

my @middle = CERT_create(
    issuer => \@root,
    subject =>  { CN => 'middle' },
    CA => 1,
);
PEM_cert2file($middle[0],'middle-cert.pem');
PEM_key2file($middle[1],'middle-key.pem');

my @leaf = CERT_create(
    subject =>  { CN => 'example.com' },
    subjectAltNames => [
        [ 'DNS', 'example.com' ],
        [ 'DNS', 'www.example.com' ],
        [ 'IP', '10.0.3.4' ],
    ],
    purpose => 'server',
    issuer => \@middle,
);
PEM_cert2file($leaf[0],'server-cert.pem');
PEM_key2file($leaf[1],'server-key.pem');


That's not the problem. Some people use VPNs for privacy (which is arguably misguided, as a VPN is a remote network connectivity tool and not a privacy tool, but that's an argument for another day) and having DNS queries leak out of the non-VPN connection is a concern in that scenario.

Say, for example, I live in an oppressive regime with little regard for the sanctity of free speech, where rich people can pay to keep certain information secret through a legal injunction preventing public dissemination of information. Now say someone publishes (or "leaks") this information to a site somewhere, and I go visit it to see what's being hidden. Being vaguely savvy in the world of privacy (e.g. someone who read a Facebook post about VPNs) I decide to use a VPN in order to hide my supposedly-nefarious activities from the systematic surveillance machine. But, alas, my system and browser are not correctly configured, and instead of sending that DNS query through the VPN tunnel, it sends it directly out in the clear, so that my ISP and those pulling the strings can see it. The DNS request demonstrates my intent to visit the site, and it's off to the re-education camps for me.

TL;DR - People use VPNs for privacy because VPN providers market them as privacy tools, and DNS requests being leaked outside of this channel give the game away.


The reason you can't find a formal comparison is that you're comparing apples and oranges: AD is a server application while OpenID Connect is a protocol. Consider the following sentences:

Clients authenticate to Active Directory using the Kerberos protocol.
Clients authenticate to _____________ using the OpenID Connect protocol.

If you want a comparison of Kerberos and OpenID Connect in terms of protocol things like bandwidth used, ease of working with the API, etc, that can be done. If you want to compare Active Directory and _____________ in terms of application things like usability for end-users, flexibility of config for admins, etc, then you'll need to find one or more vendors who sell authentication platforms that support OIDC and compare the application as a whole to Active Directory.

One obvious point that I'll throw in is that OIDC vendors tend to be focused around "single sign-on" or "authentication-as-a-service" meaning that they are cloud-native, integrate easily into all kinds of websites, and someone else takes care of the datacentre part. That said, I think Azure AD also does all of those things, while being a full Active Directory ...


Mostly, I use the Google Authenticator App on my Smartphone as the primary means.

When necessary, it pops up and I tap the green checkmark to pass the 2FA part.

For account recovery I use Google Voice and have linked my phones (2 cellphones, one dumb and one smart, but both can receive texts) to Voice, so a text will go to both of them.

Then at Google I have set it to use an account at Yahoo as my alternate.  I never use it directly, and have it set to forward to my gmail, which, thanks to linking to Google Voice, makes it show up on both phones.

That way you can't ever lose control.


Special characters in filename leads to starting virus executable

The trick is the right-to-left override character. Languages such as Arabic write right-to-left instead of left-to-right. To embed such text in a string, you can switch the direction of the text, and that can help in hiding the real extension.

helloworld.<RLO>cod.exe

will be displayed as

helloworld.exe.doc

because the part after the RLO character is reversed.


.. to only work with certain protocols? ..  to only work with certain ciphers?

Certificates are mostly protocol independent.

But there is a slight correlation between certificate and cipher: one part of the cipher specifies the authentication algorithm and the possible algorithms depend on the kind of certificate. This means that you cannot use a RSA certificate with a *_ECDSA_* cipher and no ECDSA certificate with RSA key exchange. There are also ECDH (not ECDHE) and DH (not DHE) ciphers which require specific information in the certificate.  But the choice of symmetric encryption (i.e. AES, RC4...) and the HMAC is independent from the certificate.

Which means the type of certificate limits which ciphers can be used but you cannot restrict the possible ciphers or protocols directly with some information in the certificate.


What PCI self assessment questionnaire to choose?

The introduction to the SAQ A-EP Document (PDF) reads (emphasis mine):

Before You Begin
SAQ A-EP has been developed to address requirements applicable to e-commerce merchants with a website(s) that does not itself receive cardholder data but which does affect the security of the payment transaction and/or the integrity of the page that accepts the consumer’s cardholder data.
SAQ A-EP merchants are e-commerce merchants who partially outsource their e-commerce payment channel to PCI DSS validated third parties and do not electronically store, process, or transmit any cardholder data on their systems or premises.

Your servers receive cardholder data (albeit via an API rather than through an interactive web-page) and processes cardholder data (to tokenize it before forwarding to a third-party site). Therefore my reading of the above is that SAQ A-EP is not applicable.
The use of the word website in the first paragraph is, presumably, to cover "normal" websites that hand both the acquisition and processing of cardholder data to another party: for instance by opening a new window or embedding an <iframe> in their webpage (and where the contents of the window/iframe is provided by the third-party and not your servers).
While one could debate whether "website" in the first paragraph includes a non-interactive API, I think that is irrelevant1. The second paragraph does not use "website" – it talks only of "systems" and "channels" – so would unambiguously apply to your situation. Since you do process cardholder data, you cannot be an "SAQ A-EP merchant".
Therefore, of the two, the SAQ D questionnaire would apply to your situation2.

1 My strong suspicion is what really matters in the first paragraph (and this view is backed-up in the second paragraph) is the passage I highlighted, namely "that does not itself receive cardholder data". Even if your API is not considered a website, it does (or will) receive cardholder data, and therefore you would not be eligible for the (presumably less onerous) obligations of SAQ A-EP.
2 Note that the introduction of SAQ D (PDF) reads "SAQ D for Merchants applies to SAQ-eligible merchants not meeting the criteria for any other SAQ type.". Of the two SAQs you mention, you clearly (in my mind) don't meet the criteria for SAQ A-EP. However, according to Understanding the SAQs for PCI DSS version 3 (PDF), there are a number of other types. It's conceivable (though from a quick scan of the opening page, unlikely) that you could be eligible for one of those.


Windows and BlackBerry device for learning penetration testing

For Windows Phone 8 I would buy a Nokia Lumia 520. It's cheap, I guess it can do anything that other WP phones can do. Why buy something expensive? Maybe if you need more memory or storage?

For Blackberry, which OS? There are many versions, each with its own problems I guess.


My Home WiFi Password was given away to a plumber who said he needed it, it then unusually went down for no apparent reason, is this suspicious?

We will have no idea if the disruption is malicious or not; we'd be guessing.
If you feel that something malicious happened:

change the wifi password immediately
change the router's admin password
check all router settings, especially open ports, allowed devices, remote access
use an app on your phone to physically trace any wifi transmitting device in your home to look for devices that are not your own (these apps are tricky and are not always easy to use)


If a thief has the phone in their possession, how can Password Recovery be implemented securely?

If you consider that a device is compromise, you cannot do anything that relies on sending information to the device.
This includes 2 factors authentication (SMS, or app) and emails.

The only option you have left is to base the account reset on the user knowing something (master password, security questions), or meeting face to face with said user (provided you can authenticate him physically). Alternatively, standard post-mail could be used if you have your client's address validated.

Today's applications do no bother to do this, since the client are always virtual and the only thing that ties someone to his account is his email address. This is why portable device protection are necessary for the user and there is nothing more a service provider can do to avoid this.


Breaking out of the virtualization layer

A virtual machine is an isolation layer. The code which runs into the VM (the "guest") is not supposed to be able to escape the VM and reach the host, except through the access facilities which have been explicitly enabled by the VM (e.g. networking).

Therefore, to break out of the VM, you need to find and exploit a security hole in the VM implementation -- VMWare Workstation in your case. Methodology would then be: search the Web for a description of known vulnerabilities. For instance, a simple Google search links to this.

The VM emulates a virtual machine: the guest kernel and the host operating system live in completely distinct worlds. Or, more accurately, the VM is a single process from the point of view of the host; the guest runs on hardware which does not exist, and maintains its own forest of internal process. Nowadays, VM managers are hypervisors; they use dedicated CPU opcodes to "remain hidden" from the guest: whatever the guest tries to do, it does so through some code which runs on the CPU, and the hypervisor intercepts the opcodes which could "see through the veil". This movie is a big metaphor on the hypervisor / virtual machine relationship, and it explains the situation quite well -- if you get past the heavy weapon handling and the spunky females in tight clothes, that is.


What are the best practices for hardening a php.ini file?

I find a good step for hardening your php.ini file is to use the PHPSecInfo tool, this tool will outline what settings you have currently in your php.ini that may cause a security risk.
In addition to using that tool give this article on Hardening PHP from php.ini a look its good and picks up most of the major concerns.

Personally the two main things I always make sure are configured correctly are:

display_errors - On a production server this should be turned Off and the errors should be logged to a file.
group_id - This is set to an appropriate value for a low privileged user e.g. www-data not root.


Is there a way to be 100% sure that your computer is clean of viruses?

Technically it is impossible short of verifying every circuit path, bit of storage/memory and piece of data on your computer.

You have to practically start your trust some where. Computers are incredibly complex devices and there are simply too many possible attack vectors.

For the majority of attacks, formatting the hard drives and doing a clean install is sufficient, however there are demonstrated attacks that can compromise systems permanently or infect software you build yourself through hardware or compiler level exploits.

If you expect you are targeted, you're best bet is to source hardware from someplace you trust and be very careful what you install. If you just want to be safe from general threats, avoid questionable content, patch your system regularly and keep virus scanner up to date to minimize risk of an infection after you rebuild.


Secure online credit card payment on a delayed time scale

PCI-DSS comes into play in your scenario. Time is irrelevant. It's the storing of the PAN that triggers PCI-DSS complexity.

If you want to avoid it, architect a different approach. For instance, payment processors can put an authorization hold on the funds for a time then process the full payment.

I would talk to the many payment processors out there to see what they can do for your organization.


It's your laptop that was connecting (or trying to connect) to that IP, not the other way around. I tried connecting to that IP, and basically it won't connect.

Your netstat didn't really show an established connection either, since it's in CLOSE_WAIT. Googling that IP didn't bring up anything about possible related threats, but I found at least one discussion where that mysterious IP was explained as "likely misconfigured default setting". If you think about it, it is a very peculiar IP, 123.123.123.123, which might well be a string used as an example IP address, just like "abc123" for a password, or contact@domain.com for an email address. So there's nothing there, it's might just be a random default setting that makes no sense.

I have no idea where that misconfigured default IP could be set though: applications on your laptop, scripts or any assets in web pages, etc. If you run netstat with the -e and -p options you might be able to understand a bit more.


Can one iOS app read the data of another iOS app maliciously?

No. All third-party iOS applications must have a sandbox, and the sandbox prevents direct access to any other app's data. Two apps from the same publisher can create a shared location that both can access, but even then, any data stored in an app's own directories is never exposed to other apps. Apps can also push data to one another, but there is no way for one app to force another to send it data unless the developer of the sending app explicitly creates one.

From Apple's File System Overview doc:

  For security purposes, an iOS app’s interactions with the file system are limited to the directories inside the app’s sandbox directory. During installation of a new app, the installer creates a number of container directories for the app inside the sandbox directory. Each container directory has a specific role. The bundle container directory holds the app’s bundle, whereas the data container directory holds data for both the app and the user. The data container directory is further divided into a number of subdirectories that the app can use to sort and organize its data. The app may also request access to additional container directories—for example, the iCloud container—at runtime.

The Library/Caches directory for an app has the same privileges as any other app-specific folder. Its main distinction is that its contents are considered to not need backing up or to be disastrous if lost, though they are less ephemeral than temp data (which may be purged automatically while the app is not running). As such, files in the Caches directory are not synced to iCloud. You can also use the "do not back up" attribute for a file in any directory that should not be synced.


Making a offline GNUPG2-key - should I make Master-key S&E or S only?

Is it better (safer... less confusing...) to make the Master-key Sign (and Certify) only - eg. by using "RSA (sign only)"... or must/should I make it both Sign (and Certify) and Encrypt - eg. RSA and RSA ? Is Sign&C-Only more secure or doesn't it matter?

You only need to create a master signing key. The purpose of the master signing key is nothing more than to sign other keypairs which you use as your subkeys. Because of this, there is nothing you will ever need to encrypt using your master key. Security-wise, it doesn't matter if you create a master encryption key because you'll never use it, but it's unnecessary and kind of sloppy.

  I'll definitively add an Encryption sub-key - but should/must I add a Sign sub-key too? ...Or could I just use the (full!) Master-key too sign stuff? (It would be a bother perhaps, but lets say I very rarely signed my files/mails...)

You do need to add a signing subkey as well, not just one for encryption! The purpose of keeping a master key offline is to avoid using it excessively in situations where it might get stolen. Signing everything with your master signing key completely defeats the purpose of keeping it offline, even if you sign things only rarely. The only time you should ever use (or even access) your master key is when you are generating new subkeys and need to sign them. As such, you need to generate a keypair with both encryption and signing subkeys, and sign that using the master key.

Note that there are secure smartcards you can get which can store your master key in an encrypted form and sign subkeys without you ever needing to put the secret key on your computer, just by plugging in the device. I suggest you look into one of those to help with managing your keys.


If the page you are refreshing is sufficiently resource intensive. In most cases it will not result in a denial of service as the latency in the network connection far exceeds the page load/cpu time. If you found a page that did significant background work, such as creating a database backup you could in theory repeatedly refresh the page and consume all available CPU/memory/etc.


PKCS#12 is an extremely flexible format, so any answer to your question is relative to what the archive producer decided to do: which algorithms, which parameters...

Normally, when doing password-based encryption, you will end up with 3DES or AES, and the key derivation algorithm is PBKDF2 with a cost parameter that you do not get to choose. To make the story short, this will be as safe as these things can be IF (and that's a big "if") the used password is strong.

For a specialized use case, you can generate the "password" as an actual big key: take your favourite cryptographically secure PRNG (e.g. /dev/urandom on Linux and MacOS X) and use it to produce a sequence of 24 random hexadecimal digits. This will offer 96 bits of entropy, and things will be fine. The confidentiality of the private key in the PKCS#12 file will be maintained, and the integrity will be reliably verified.

A simple way to generate such a random "password" on a Linux system is:

(dd if=/dev/urandom bs=16 count=1 2>/dev/null) | sha1sum | cut -b 1-24

On Windows you can use PowerShell:

$rng = New-Object System.Security.Cryptography.RNGCryptoServiceProvider
$buf = New-Object byte[] 12
$rng.GetBytes($buf)
([System.BitConverter]::ToString($buf) -replace "-", "").ToLowerInvariant()

If you really want to add an extra layer, the reasonable way is not to assemble a symmetric encryption algorithm and a MAC yourself: these things are deceptively hard, meaning that it is easy to make something which works, much harder to make something which is strong, and very much harder to make something that can be ascertained to be strong. Instead, use an existing protocol which is supported by an existing, well-vetted implementation. I suggest GnuPG (the OpenPGP format implemented by GnuPG supports both symmetric and asymmetric encryption).


If two servers are in the same private network, is it better for them to talk to each other through HTTP or HTTPS?

In general it is more secure for communications to make use of encrypted (https) communications.

For data, that is PII or financial in nature I alway recommend secure protocol.

However, when you introduce encryption it can make some processes more difficult.

Debugging - it is harder to analyze network traffic to find issue.
IDS/IPS - There network appliance analyze traffic and respond to attacks. If they cannot see into traffic they have less info to respond with.
Latency/ CPU cost - Adding encryption increase the time before first connection and the cpu power needed to communicate (https://istlsfastyet.com/). The intro of http2 has lowered the latency somewhat and modern hardway usually has crypto acceleration built in.
PKI management - HTTPS Pki management is difficult is using private certificates for local domains.

On a private network, the need for https is greatly reduced but issues such as snippers and accidental leaks do exist.  It really depends on the private network, data and risk tolerance.
For example:

Log data flowing between two server by a shielded-wire in a datacenter in a locked cage. May not need encryption.
Open wifi with no encryption, I would strongly recommend here.

PKI based tls is more expensive via computations and required more set up.  Instead you may want to use encryption that relies on pre-shared keys. If you can securely enter the keys.


An expiry code means that if an unauthorised person with malicious intent gains access to the code before the user finalises registration, then fraud can be prevented if the malicious person does not also have access to the victim's personal information.

But how effective of a control would the expiry be? If someone with malicious intent has access to the mail and a desire to exploit it, then it is reasonable to assume that the malicious person has access to all mail. If there is access to all mail, then all the victim's info is exposed to the malicious person, so the control is not effective in this case.

Compare this to the risk of a legitimate delay in finalising registration, requiring a re-issuing of the code and posting. The expiry period would need to be long, in which case, a malicious person has a lot of time to act.


Is Aescrypt a valid tool for encryption or not?

See this question for some caveats. There is nothing positively wrong which is reported about it, but it seems to use custom format and password-to-key processing, which means that it was not well analyzed. I see no mention of an integrity protection. Therefore I would recommend caution until further analysis.

Assuming that AESCrypt does everything right (including integrity checks), then yes, sending by email files which are protected by a password is fine... provided that you choose strong enough passwords, and that you have a way to convey the password to the intended recipient with all the needed confidentiality. It would not buy you much to use both the innate encryption features of RAR and an additional encryption layer, especially if both use the same password.

Systems which support asymmetric encryption like GnuPG will still make your life easier. You still have to make sure that you have the right public key (the one owned by the recipient), but at least it is a public key so you can transmit it securely with less constraints (you can dictate the hash by phone, but you do not have to fear people who merely spy on the phone line, contrary to speaking a password over the phone).


Password algorithm to be integrated on a website

It's a really good idea to not do this yourself; it's easy to mess up if you don't know what you're doing.

The short of it is that you want to hash your passwords with a slow algorithm using a per-user salt.  I won't go into much detail, because there are plenty of resources, here and across the web, talking about which hashing function to use, how to store salts, why you need to do these things, etc.

The frontend is completely irrelevant; you just take in user input and pass it to your password-checking function.


How do I know if a Google Chrome extension is leaking data?

According to developer.chrome.com:

  [Chrome Extensions] are built on web technologies such as HTML, JavaScript, and CSS.

This means, anything that could affect the behavior of an extension will exist in a plain-text format (as opposed to a binary). Chrome allows you to debug extensions, giving you a comparatively easy way to see what an extension is doing, and whether or not some behavior of an extension is potentially malicious.

This requires the user to be somewhat fluent in the above-mentioned technologies. There are certain attacks, purely using CSS, which can be used to exfiltrate data. Without knowledge of CSS or understanding of these attacks, it would be hard to identify them among megabytes of auto-generated CSS code.

A non-technical user will likely not be able to carry out such an analysis. In this case, it helps to follow typical security advice:

Only install extensions from credible sources (i.e. the Chrome Web Store)
Popular extensions are more likely to get audited than unknown extension
Only install extensions where the benefit greatly outweighs the risk
Pay attention to the permissions required by the extensions and if it makes sense that those permissions are requested


Why does saving a salt as plain text still improve security?

Salts aren't designed to protect against dictionary attacks.  The salt is used to prevent a pre-image or a rainbow attack in which large amount of passwords are pre-computed, and can be looked up almost immediately rather than weeks or months later.

Putting a large amount of random data before the password makes this impossible.

In addition, the salt protects against the same password having the same hash value, and forces the attacker to compute a new hash for all passwords rather than use the same hash for all passwords.


We use 3 primary methods of media destruction. Which method that is chosen will, of course, depend on any number of factors including; corporate policies regarding data handling, legal or regulatory requirements, corporate policies regarding equipment refresh/retirement, time constraints, physical condition of the device, etc.
Secure Deletion
This would include any number of methods by which we attempt to fiddle with the bits on disk. The most typical is some kind of N-pass overwrite. This has the advantage of leaving the drive intact for use later, can be done in any number of ways, and is relatively configurable. Whether you use DBAN on a desktop PC with 1 or 2 drives or something like an ImageMASSter with expansion sleds and work on 20 disks at a time. This method also works equally well on removable storage such as ZIP or floppy discs. It has already been discussed fairly well at How can I reliably erase all information on a hard drive? Since it sounds as if the disk in question is failing, then this is likely not a reliable option and moving on down to a physical destruction method may be required.
Electrical Scrambling
In the olden days when you had a room packed with tape there were few things better than a big honkin' degausser for making sure that you knew what left the room. As hard drives supplanted tape, their use simply got transferred to the new medium. The biggest advantage to using a degausser to take care of hard drives is speed. Just pass a box through the unit, ignore the jiggling in your fillings, and walk away with clean drives. The downside is the lack of ability to audit data destruction. As discussed in the Wikipedia article, once a hard drive is degaussed, the drive is mechanically unusable. As such, one cannot spot check the drive to ensure cleanliness. In theory the platters could be relocated to a new device and we cannot state, categorically, that the data will not be accessible.
Wanton Destruction
This is without question my favorite. Not only because we demonstrate, without question, that the data is gone, but the process is very cathartic. I have been known to take an hour or so, dip into the "To Be Destroyed" bin, and manually disassemble drives. For modern hard drives all you need is a torx set and time (possibly pliers). While one will stock up on their magnet collection, this method of destruction is very time consuming. Many companies have developed equipment specifically for hard drive destruction en-masse. These range from large industrial shredders to single unit crushers such as this beauty from eDR. I have personally used that particular crusher, and highly recommend it to any Information Security professional who has had a bit of a rough day.


Is there a way to negotiate a secret between 2 parties with no prior knowledge?

There is Diffie-Hellman (which SSL can also use), but this is only secure if an attacker cannot perform active attacks, or the parties can be mutually authenticated.


AEAD and nonces explained in layman's terms (Symmetric encryption example using Libsodium)

It seems like a nonce is a type of salt of a specific size that can only be used once because otherwise replay attacks can happen. Can you help me understand this further? Wikipedia and other sites got too complicated.

A nonce is required to make sure that the ciphertext doesn't leak information. Such a nonce or IV is required for any CPA secure cipher as repeated plaintext may otherwise leak information.

For stream ciphers - as used by most if not all AEAD constructions - a unique nonce is required otherwise you will leak all of the plaintext. It may also compromise the (internal) hash key, leading to a full compromise of the authenticity property (!!!).

  To a layman, how would you describe AEAD and how to use the "Authenticated Associated Data (unencrypted)" parameter?

The AAD can contain any data that needs to be authenticated but doesn't need to be - or cannot be - kept confidential. For instance: it may be a good idea to protect the recipient field of a message in a protocol, but if it is hidden then the network may not be able to get it to the destination in the first place.

  In the PHP function (which I copied from https://paragonie.com/b/kIqqEWlp3VUOpRD7), does using the nonce not just as a nonce but also as the "Authenticated Associated Data" reduce the security compared to some other approach where the sender would add some value here and communicate offline to the receiver what the receiver should expect this value to be?

Adding the nonce to the AAD never increases security, because AEAD ciphers already include it into the calculation of the authentication tag.

How much "some value" adds to the security depends of course on the protocol and possible attack vectors. Note that a nonce must be unique, but your protocol may not use it against replay attacks. In that case adding data to the AAD may help prevent such attacks.

Note that AEAD already requires a secret key and a nonce; there is no need to add another key or nonce (to secure the cipher itself). Adding the identity of the sender / receiver odes generally makes sense.

  Why would the JavaScript version accept different parameters? JS asks for a secret_nonce separate from a public_nonce, and in order for the results to match PHP's function, I need to supply identical values for secret_nonce and public_nonce. So what's the point?

The JS library doesn't actually use the secret nonce parameter called nsec. If you read the documentation you will always find:

  nsec is not used by this particular construction and should always be NULL.

Note that poly1305 requires two keys, of which the second "key" is handled as a number. However, the second key - usually denoted r - may be generated pseudo-randomly as specified here.

Generally it is preferred to use a single key for the cipher alone, so implementations will probably not support the dual key version and generate r internally. But I think that is why the nsec parameter exists in the first place.

For the GCM / GHASH the key is universally created internally as well.


Hypothetical: if I wanted to swap my corp laptop for an exact replacement?

The data on the laptop is likely more valuable than the laptop itself.  Many orgs will sell you old laptops once they reach end of life but they will require the laptop back from you to wipe it clean and purge data from it as well as licenced software etc. Asking to buy it and being honest is not only the most ethical thing to do, but the smartest thing to do. (Not least because why would you want to keep an old worn out laptop over a brand new one?)

Before we even get to security controls, you will face a number of problems trying to swap out the machine for a new one. Getting the exact same spec laptop will be hard, first of all these spec machines are usually sold exclusively to enterprises, secondly the same models tend to have differences from year to year, the IT guys will probably intimately familiar with these differences.

I do not recommend saying your laptop was stolen, mature orgs will launch an investigation, data officers and legal teams could become involved, this will would mean there is a good chance that the police would be involved, so you would end up breaking a lot of laws, not least wasting police time.

In the same vain I do not recommend saying the laptop was broken, as the IT department will require the broken laptop back, to ensure that it can be safely disposed of.

Many security controls will dictate the requirement of an asset inventory of authorised devices, including the CIS critical controls, ISO27001 etc. This will mean there is a chance that each asset will be tracked and auditable against its MAC address (which will allow switches to only allow authorised devices on the network), device owner, hostname, serial number, and asset numbers. Additionally the laptop may be part of the orgs domain.

So if the goal is to get this “done in the most ethical way”, I think you will fail straight away. Proably a better way of saying it is to get it done in the least unethical way, as you would likely need to do the following:

Break the law
Circumvent the companies security controls
Breach your contract of employment
Break the orgs security policy
Break the orgs acceptable use policy
Break the orgs data handling policies

If the orgs has basic security controls in place (minus drive encryption) then you would also need to:

Source an identical laptop
Remove tamper proof asset tags and place them on the new laptop
Configure the new laptop to spoof the old laptops MAC address (Which would revert to the hardware address once reinstalled)
Change the serial number of the new laptop to that of the old laptop (This would need to be done in the BIOS and would probably require you to flash the BIOS)
Have the laptop reimaged with the orgs image and joined to the domain with the same hostname, which would require access to local admin right on the laptop, domain admin rights and/or the orgs imaging server

TLDR: If the org has some basic security controls in place then swapping one machine out for the other would not only break the law but would require considerable effort.


How secure is Vigenere cipher for random data?

I agree it would be difficult (possibly impossible) to break a Vigenere cipher on random data that's never used and is simply random.

But your scheme where you use that random data as a one-time-pad would not have informational theoretic perfect security like a one-time-pad.

It will have the security of a Vigenere cipher -- the weakest link in the chain.  You wouldn't be able to easily directly attack the Vigenere cipher on the random data, but you could easily attack the combination.

I mistakenly misremembered the Vigenere cipher with its primary operation being XOR not addition modulo character space.  My mistake makes the attack on your scheme trivial due to properties of XOR.  I'll call my mistaken scheme VigenereXOR.

The old example using VigenereXOR:

 import scipy
 rand_bytes=[scipy.random.random_integers(256) for i in range(512)] # 512 random bytes
 vig_key = "MYSECRET"*64
 vig_key_bytes = [ord(c) for c in vig_key]
 encrypted_random = [(r ^ vk) for r,vk in zip(rand_bytes, vig_key_bytes)]
 message = "But your scheme where you use that random data as a one-time-pad would not have informational theoretic perfect security like a one-time-pad."
 message_bytes = [ord(c) for c in message]
 encrypted_message = [(r ^ m) for r,m in zip(rand_bytes, message_bytes)]

Now if an attacker observes both encrypted_random and encrypted_message, they can XOR them together, at which point they would have the original message simply encrypted with the Vigenere cipher as (A XOR B) XOR (B XOR C) = A XOR C; hence all the frequency attacks on the message Vigenere could be directly applied.

On the real Vigenere cipher:

 encrypted_random = [(r + vk) % 256 for r,vk in zip(rand_bytes, vig_key_bytes)]

there may be sophisticated attacks on it.  At the very least you obviously do not have perfect security from the scheme.  If the scheme had perfect security, then the length of the Vigenere key would be irrelevant and it obviously isn't -- a one character key could be used -- which would be trivially attackable.  You may note that you can still construct (A + B mod 256) XOR (B XOR C) = ((A + B mod 256) XOR B) XOR C.  (A + B mod 256) XOR B is not randomly distributed (e.g., if A = 8, then the only possibilities for (A + B mod 256) XOR B are 8,24,56,120,248 after trying all 256 values of B).  Headway of this sort possibly can be made to make this attack much better than brute force.

It's a common textbook result (with a straightforward proof) that you can't get information-theoretic perfect security if your keyspace (what was exchanged prior to encryption) isn't at least as large as your message space.  See Shannon's classic 1949 paper.


How does Google or any other social media sites know what password I've used previously?

These sites store your previous passwords in some form. It could either be in plain text (i.e. the password as it is) OR a hash (eg. SHA256 or better) of it.

Storing plain text passwords is a bad design security wise because it leaves your password in the database which can be reused as it is if the database is compromised.


Hydra - Attacking when login page encodes the username and password

As the code clearly indicates, the name, password, and verification token are hashed together before being sent over the network. So, no, you cannot figure out which is which just from the network data alone.

Hydra is not the tool that is going to work for you here. You need to come up with a way of sending psd with all that data formatted in the expected way (combined, hashed, and encoded).


Facebook messages with a suspicious link, what information can they get if I dont enter any details?

If they didn't get me to login, how would they get my login details? Could I still be compromised?

Most likely they did not get your credentials. You can change your password just to be on the safe side if you want to, but I would not worry to much about it.

  And if their intention wasn't to get my details, how did the person that sent it to me get compromised?

There are many possible ways. Perhaps he entered his password into a phishing site (either the one you were taken to, or some other site). Maybe he reused the same password on other sites, and one of them got hacked.

(A way things like this spread back in the day was through clickjacking attacks, where the malicious page would load e.g. Facebook in a transparent iframe, and fool you into clicking the invisible facebook buttons. But I am pretty sure Facebook protects against that nowadays.)

  Would it be dangerous if I were logged into the mobile Facebook website in a browser (not the app)?

I don't think it makes a lot of difference. If there was some kind of exploit, it happend in the browser after you clicked the link. And it's the same browser no matter what app you come from.

  Is it possible that something was downloaded to my Android just bey clicking the link? Is there a way I can check (or scan) effectively?

Yes, it is possible to get infected by malware by just visiting a site. But if your browser is up to date and you have Flash and Java disabled by default I would not worry to much about it.

There are plenty of antivirus programs that include support for mobile devices. You could install one and scan your phone. No scan is 100% though.

(I don't know enough to make a specific recommendation, and software recommendations are not on topic here anyway.)


In RSA, can any of the two keys be used for both encryption and decryption?

There are many incorrect wordings/usages here.
RSA is merely the one public-key cryptosystem that can support both encryption and signature naively in the almost same type of operation.
TextBook RSA
What confuses the people is the Textbook RSA which is simply c = m^e mod n for encryption and m= c^d mod n for decryption, whereas sign = hash(m)^d mod n for signature and verify(m,sign) that calculates hash(m) and checks that hash(m) == sign^e mod n.
Both are insecure as you can see that you can multiply the ciphertexts, or .. ( this is a very long story;  start from reading Twenty Years of Attacks on the RSA Cryptosystem for more attacks from Dan Boneh).
RSA encryption
RSA encryption requires padding to be secure. PKCS#5v1.5 and Optimal Asymmetric Encryption Padding (OAEP)  are the paddings that must be used. The former had lots of attacks due to incorrect implementations. The latter is much easier to implement. They are both proved to be secure so the only problem is the implementations.
RSA signatures
RSA signature requires padding to be secure, too. This time the padding is a Probabilistic Signature Scheme and designed for signatures.
RSA sign!=RSA decryption
Don't use/say that RSA decryption is a signature. It is not. The signatures algorithm consists of two algorithms; sign and verify. During the sign operation, PSS be part of it.
For a detailed reading see from Cornell University page; RSA Signing is Not RSA Decryption
Don't use one RSA key for more than one purpose
Don't use the same RSA public-private key for more than one purpose. Use either for enc/dec or sign/verify. If you need both, you two different public/private key pairs where the modulus is distinct.
Public key is not for encryption
Public key cryptosystems are slow compared to private key cryptosystems. Therefore we prefer a hybrid cryptosystem where the public key is used for key exchange and the private key is used for encryption. Examples are;

RSA-KEM for Key encapsulation Mechanism and AES-GCM for Data Encapsulation Mechanism
DHKE for key establishment and ChaCha20-Poly1305 for data encapsulation mechanism

Where RSA is used today?
In today's security, RSA is mostly used for the signature. Although RSA-KEM is promising for key encapsulation there is no standard for that, we use Elliptic Curve Diffie-Hellman most of the time.


What information can be gained from an Apple device's screenshot or its EXIF data?

Including sample data of an OSX screen capture from a OSX desktop parsed by three different tools below. It does not seem to contain the IP address but it does contain the make and model of your computer and in some cases some directory information (I also noticed that if you use an external display it will contain different information than if the screenshot is taken from your primary display).

Update: I just tested an iPhone screen capture (iOS 9.3.2 but with location services turned off and pretty much maximum privacy settings) and had near identical types of information for that device as the info below.

Note: Computers with different operating systems and software may include additional information not shown below. Also different tools may be better or worse at interpreting EXIF data and this may lead to some information not being listed here.

Viewing the screen captures with a hex editor seemed to indicate that most of the EXIF data was found by these tools. Again this could easily change with any given software updates.

You can upload the files to the following website to see some information on your own files:
http://regex.info/exif.cgi

ICC_Profile — this block of data describes the color space used to encode pixel colors.
Profile CMM Type    appl
Profile Version 2.1.0
Profile Class   Display Device Profile
Color Space Data    RGB
Profile Connection Space    XYZ
Profile Date Time   2016:02:15 15:07:11
3 months, 26 days, 23 hours, 39 minutes, 51 seconds ago
Profile File Signature  acsp
Primary Platform    Apple Computer Inc.
CMM Flags   Not Embedded, Independent
Device Manufacturer
Device Model
Device Attributes   Reflective, Glossy, Positive, Color
Rendering Intent    Perceptual
Connection Space Illuminant 0.9642 1 0.82491
Profile Creator appl
Profile ID  0
Profile Description Display
Profile Description ML (hr-HR)  Thunderbolt Display
Profile Description ML (ko-KR)  Thunderbolt Display
Profile Description ML (nb-NO)  Thunderbolt Display
Profile Description ML  Thunderbolt Display
Profile Description ML (hu-HU)  Thunderbolt Display
Profile Description ML (cs-CZ)  Thunderbolt Display
Profile Description ML (da-DK)  Thunderbolt Display
Profile Description ML (uk-UA)  Thunderbolt Display
Profile Description ML (it-IT)  Thunderbolt Display
Profile Description ML (ro-RO)  Thunderbolt Display
Profile Description ML (es-ES)  Thunderbolt Display
Profile Description ML (he-IL)  Thunderbolt Display
Profile Description ML (nl-NL)  Thunderbolt Display
Profile Description ML (fi-FI)  Thunderbolt Display
Profile Description ML (zh-TW)  Thunderbolt Display
Profile Description ML (vi-VN)  Thunderbolt Display
Profile Description ML (sk-SK)  Thunderbolt Display
Profile Description ML (zh-CN)  Thunderbolt Display
Profile Description ML (ru-RU)  Thunderbolt Display
Profile Description ML (fr-FR)  Thunderbolt Display
Profile Description ML (ca-ES)  Thunderbolt Display
Profile Description ML (th-TH)  Thunderbolt Display
Profile Description ML (es-XL)  Thunderbolt Display
Profile Description ML (de-DE)  Thunderbolt Display
Profile Description ML (pt-BR)  Thunderbolt Display
Profile Description ML (pl-PL)  Thunderbolt Display
Profile Description ML (el-GR)  Thunderbolt Display
Profile Description ML (sv-SE)  Thunderbolt Display
Profile Description ML (tr-TR)  Thunderbolt Display
Profile Description ML (ja-JP)  Thunderbolt Display
Profile Description ML (pt-PT)  Thunderbolt Display
Profile Copyright   Copyright Apple Inc., 2016
Media White Point   0.94955 1 1.08902
Red Matrix Column   0.44434 0.22476 0.00548
Green Matrix Column 0.37944 0.72617 0.07797
Blue Matrix Column  0.14041 0.04907 0.74146
Red Tone Reproduction Curve (2,060 bytes binary data)
ICC Profile Aarg    (32 bytes binary data)
Video Card Gamma    (48 bytes binary data)
Native Display Info (62 bytes binary data)
Chromatic Adaptation    1.04861 0.02332 -0.05034 0.03018 0.99002 -0.01714 -0.00922 0.01503 0.75172
**Make And Model    (40 bytes binary data)**
Blue Tone Reproduction Curve    (2,060 bytes binary data)
Green Tone Reproduction Curve   (2,060 bytes binary data)
ICC Profile Aabg    (32 bytes binary data)
ICC Profile Aagg    (32 bytes binary data)

Using ImageMagick's command: identify -verbose filename

Image: EXIF-2.png
  Format: PNG (Portable Network Graphics)
  Class: DirectClass
  Geometry: 840x728+0+0
  Resolution: 56.69x56.69
  Print size: 14.8174x12.8418
  Units: PixelsPerCentimeter
  Type: TrueColorMatte
  Endianess: Undefined
  Colorspace: RGB
  Depth: 8-bit
  Channel depth:
    red: 8-bit
    green: 8-bit
    blue: 8-bit
    alpha: 1-bit
  Channel statistics:
    Red:
      min: 39 (0.152941)
      max: 243 (0.952941)
      mean: 145.848 (0.571955)
      standard deviation: 38.1181 (0.149483)
      kurtosis: -0.548953
      skewness: -0.365279
    Green:
      min: 48 (0.188235)
      max: 240 (0.941176)
      mean: 145.454 (0.570408)
      standard deviation: 33.2798 (0.130509)
      kurtosis: -0.495621
      skewness: -0.482358
    Blue:
      min: 38 (0.14902)
      max: 231 (0.905882)
      mean: 110.294 (0.432524)
      standard deviation: 28.2349 (0.110725)
      kurtosis: 0.223295
      skewness: 0.261946
    Alpha:
      min: 255 (1)
      max: 255 (1)
      mean: 255 (1)
      standard deviation: 0 (0)
      kurtosis: 0
      skewness: 0
  Image statistics:
    Overall:
      min: 0 (0)
      max: 243 (0.952941)
      mean: 100.399 (0.393722)
      standard deviation: 28.973 (0.11362)
      kurtosis: 48.6621
      skewness: -4.99921
  Rendering intent: Undefined
  Interlace: None
  Background color: white
  Border color: rgba(223,223,223,1)
  Matte color: grey74
  Transparent color: none
  Compose: Over
  Page geometry: 840x728+0+0
  Dispose: Undefined
  Iterations: 0
  Compression: Zip
  Orientation: Undefined
  Properties:
    date:create: 2016-06-13T20:35:36+00:00
    date:modify: 2016-06-13T20:34:13+00:00
    PNG:iCCP                 : chunk was found
    PNG:IHDR.bit_depth       : 8
    PNG:IHDR.color_type      : 6
    PNG:IHDR.interlace_method: 0
    PNG:IHDR.width,height    : 840, 728
    PNG:pHYs                 : x_res=5669, y_res=5669, units=1
    signature: 3e74422ab0e2b55b3cbec053dd3a147894cc35a8e2083d6a2eba2b890fba5d89
  Profiles:
    Profile-icc: 3892 bytes
      Display
  Artifacts:
    verbose: true
  Tainted: False
  Filesize: 818KBB
  Number pixels: 612KB
  Pixels per second: 7.644MB
  User time: 0.060u
  Elapsed time: 0:01.080
  Version: ImageMagick 6.6.9-7 2014-03-06 Q16 http://www.imagemagick.org

http://www.sno.phy.queensu.ca/~phil/exiftool/

ExifTool Version Number         : 10.20
File Name                       : EXIF-2.png
Directory                       : .
File Size                       : 799 kB
File Modification Date/Time     : 2016:06:13 13:28:01-07:00
File Access Date/Time           : 2016:06:13 13:46:55-07:00
File Inode Change Date/Time     : 2016:06:13 13:28:01-07:00
File Permissions                : rw-r--r--
File Type                       : PNG
File Type Extension             : png
MIME Type                       : image/png
Image Width                     : 840
Image Height                    : 728
Bit Depth                       : 8
Color Type                      : RGB with Alpha
Compression                     : Deflate/Inflate
Filter                          : Adaptive
Interlace                       : Noninterlaced
Profile Name                    : ICC Profile
Profile CMM Type                : appl
Profile Version                 : 2.1.0
Profile Class                   : Display Device Profile
Color Space Data                : RGB
Profile Connection Space        : XYZ
Profile Date Time               : 2016:02:08 13:38:48
Profile File Signature          : acsp
Primary Platform                : Apple Computer Inc.
CMM Flags                       : Not Embedded, Independent
Device Manufacturer             :
Device Model                    :
Device Attributes               : Reflective, Glossy, Positive, Color
Rendering Intent                : Perceptual
Connection Space Illuminant     : 0.9642 1 0.82491
Profile Creator                 : appl
Profile ID                      : 0
Profile Description             : Display
Profile Description ML (hr-HR)  : LCD u boji
Profile Description ML (ko-KR)  : 컬러 LCD
Profile Description ML (nb-NO)  : Farge-LCD
Profile Description ML (hu-HU)  : Színes LCD
Profile Description ML (cs-CZ)  : Barevný LCD
Profile Description ML (da-DK)  : LCD-farveskærm
Profile Description ML (uk-UA)  : Кольоровий LCD
Profile Description ML (it-IT)  : LCD colori
Profile Description ML (ro-RO)  : LCD color
Profile Description ML (es-ES)  : LCD color
Profile Description ML (he-IL)  : LCD צבעוני
Profile Description ML (nl-NL)  : Kleuren-LCD
Profile Description ML (fi-FI)  : Väri-LCD
Profile Description ML (zh-TW)  : 彩色 LCD
Profile Description ML (vi-VN)  : LCD Màu
Profile Description ML (sk-SK)  : Farebné LCD
Profile Description ML (zh-CN)  : 彩色 LCD
Profile Description ML (ru-RU)  : Цветной ЖК-дисплей
Profile Description ML (fr-FR)  : LCD couleur
Profile Description ML (ca-ES)  : LCD en color
Profile Description ML (th-TH)  : LCD สี
Profile Description ML (es-XL)  : LCD color
Profile Description ML (de-DE)  : Farb-LCD
Profile Description ML          : Color LCD
Profile Description ML (pt-BR)  : LCD Colorido
Profile Description ML (pl-PL)  : Kolor LCD
Profile Description ML (el-GR)  : Έγχρωμη οθόνη LCD
Profile Description ML (sv-SE)  : Färg-LCD
Profile Description ML (tr-TR)  : Renkli LCD
Profile Description ML (ja-JP)  : カラー LCD
Profile Description ML (pt-PT)  : LCD a Cores
Profile Copyright               : Copyright Apple Inc., 2016
Media White Point               : 0.94955 1 1.08902
Red Matrix Column               : 0.44434 0.22476 0.00548
Green Matrix Column             : 0.37944 0.72617 0.07797
Blue Matrix Column              : 0.14041 0.04907 0.74146
Red Tone Reproduction Curve     : (Binary data 2060 bytes, use -b option to extract)
Video Card Gamma                : (Binary data 48 bytes, use -b option to extract)
Native Display Info             : (Binary data 62 bytes, use -b option to extract)
Chromatic Adaptation            : 1.04861 0.02332 -0.05034 0.03018 0.99002 -0.01714 -0.00922 0.01503 0.75172
Make And Model                  : (Binary data 40 bytes, use -b option to extract)
Blue Tone Reproduction Curve    : (Binary data 2060 bytes, use -b option to extract)
Green Tone Reproduction Curve   : (Binary data 2060 bytes, use -b option to extract)
Pixels Per Unit X               : 5669
Pixels Per Unit Y               : 5669
Pixel Units                     : meters
XMP Toolkit                     : XMP Core 5.4.0
Exif Image Width                : 840
Exif Image Height               : 728
Image Size                      : 840x728
Megapixels                      : 0.612


PCI DSS 3.2 SAQ-A for card-not-present mail/telephone orders (MOTO)

I am confused because it says SAQ-A is valid when "All processing of
  cardholder data is entirely outsourced to PCI DSS validated
  third-party service providers", yet SAQ C-VT is needed when a virtual
  terminal (hosted by a validated third-party) is used to take payments.

What differs is who takes the call.

For SAQ C-VT, the Merchant has employees who sit at a Virtual Terminal hosted by a validated Third-Party Service Provider.  Customers call the Merchant, the Merchant's employee types their card numbers into the VT, the purchase proceeds.

When SAQ A says (emphasis mine):

  SAQ A merchants confirm that, for this payment channel:

  Your company accepts only card-not-present (e-commerce or mail/telephone-order) transactions;
  All processing of cardholder data is entirely outsourced to PCI DSS validated third-party service providers;

They are describing a setup where the Merchant outsources the entire telephone-order process to a validated Third-Party Service Provider.  The Customer calls the number provided by the Merchant, but it rings at the Third-Party call center, and a Third-Party employee takes the details, enters them into the terminal, and proceeds with the purchase.

(In both cases, of course, the Third-Party is subject to much more extensive compliance requirements than either SAQ A or SAQ C-VT.  The limited scope of those two SAQs rely upon the offloading of scope to the Third-Party Service Provider).

  So how could telephone orders be taken and the merchant remain under SAQ-A?

If the phone calls go directly to the Third-Party Service Provider, and not to the Merchant, the Merchant may remain SAQ A.


How to prevent someone guessing the token in a reset password link

You should create a cryptographically random token for this. Yours is definitely not random enough, and could be guessed much quicker than the (2^122 / 2) you mention. The importance of cryptographic randomness has been discussed many times already on this forum, for example here.

As you mention that you are using .net, have a look at ASP.Identity which can generate tokens for you, using the DataProtectorTokenProvider. If you are not using ASP.Identity (or Owin for that matter), you can also look into using RNGCryptoServiceProvider to generate secure random tokens.  I'm not saying you could not do it yourself, but it is hard.

Edit: If you are talking about a GUID (as you reference to it), you can read this answer:

  To identify a user of an online banking application on the other hand, (or really probably even a password reset function of a site where identity is valuable) GUIDs are definitely inadequate.


it is unlikely that the web application you are testing only has the one database as information_schema is read-only metadata.
you can dump some of the views in there to find out if there are other databases that you aren't allowed to see for some reason:
information_schema.schemata  is the table (it is really a view) you would want to dump.
edit:  can you explain what you are trying to do with your --tamper and --data statements