Which security standards define the time of inactivity before locking the screen

The large standards (ISO, NIST) tend toward one-size fits all, the real intent is to promote careful consideration, and deliberate and informed decision making. Specific values such as these are a property of a good policy implementation, the slightly abstract standards tend to only recommend maxima or minima, if even.

Such a "control" is typically assigned a persistent, unique identifier by a particular standard, the common ones are suitable here are AC-11 and SC-10 (from NIST SP800-53(PDF) ) and FTA_SSL (from ISO/IEC 15408, aka Common Criteria for Information Technology Security Evaluation, "FTA" is the class of access control, "SSL" refers to session locking).

Roughly from more-specific to less-specific:

OMB M-06-16 (PDF) U.S. Presidential Memorandum Protection of Sensitive Agency Information

   3. Use a "time-out" function for remote access and mobile devices requiring user re-
    authentication after 30 minutes inactivity; and

Australian DSD Information Security Manual 2013 Controls
Session and Screen locking, Control 0427

  · configure the lock to activate either:

  after a maximum of 15 minutes of system user inactivity
  if manually activated by the system user

(see also control 0428 which states 10 minutes for "confidential" and "secret" levels).
Unchanged in 2014 edition.
U.S. CNSS CNSSI-1253 Security Categorization And Control Selection For National Security Systems

Control AC-11 Session lock

  ...not to exceed 30 minutes

NIST SP800-53 Recommended Security Controls for Federal Information Systems and Organizations

NIST SP800-46
Guide to Enterprise Telework and Remote Access Security

Control AC-11 Session Lock:  Timeout is "organization defined"
(See also Canadian ITSG-41)
Control SC-10 Network Disconnect

SP800-46 suggests 15 minutes as appropriate for remote access (page 4-3)
PCI-DSS v2

  8.5.15 If a session has been idle for
  more than 15 minutes, require the user
  to re-authenticate to re-activate the
  terminal or session.

(in v3 the requirement has been renumbered to 8.1.8, but otherwise unchanged)
and

  12.3.8 Automatic disconnect of sessions
  for remote-access technologies after a
  specific period of inactivity

U.S. FBI/DoJ CJISD-ITS-DOC-08140-5.2 Criminal Justice Information Services Security Policy

  5.5.5 Session Lock

  The information system shall prevent further access to the system by initiating a session lock after a maximum of 30 minutes of inactivity, and the session lock remains in effect until [...]

ECMA ECMA-271 Extended Commercially Oriented Functionality Class for Security Evaluation

  7.4.1.8 Session lock or terminate
         The TOE shall support a session lock. The TOE shall provide an idle process   monitor for each front-end
         which inhibits after a customer defined amount of time user interactions except user authentication.

Rather old (December 1999) the same time frame as ISO/IEC 17799:2000, sadly never updated by ECMA. TOE is Target Of Evaluation, some Common Criteria terminology.
ISO 27001:2005(E)/ISO 27002:2005(E)(see this document for a useful overview)
Control A.11.3.3 Clear desk and clear screen policy
§11.3.3.3

  The clear desk and clear screen policy should take into account the information classifications (see 7.2), legal and contractual requirements (see 15.1), and the corresponding risks and cultural aspects of the organization.

See also §11.5.5 Session time-out
Council On CyberSecurity Critical Security Controls v5.1

  CSC 16-6 Configure screen locks on systems to limit access to
          unattended workstations.

CERT Knowledge and Information Management (KIM)
KIM:SG4.SP2 Control Access to Information Assets

  [...] The organization must decide upon the right mix of controls to
  address the various forms of the information asset and any special
  considerations of the asset.

There's absolutely nothing wrong with using your own values once you have properly defined your risks and requirements, and documented the decisions. You may even decide on session lock exemptions (e.g. in the case of air traffic control, or locations with enhanced physical security), or mandate proximity devices.


Cracking less than 4 letter linux password using john

John will default to its internal wordlist. Sounds like you need to use mask mode:

./john --mask=?1?1?1?1 -1=[A-Z] file.txt -min-len=4

This example will attempt all permutations of 4 character, upper case A-Z letters.

Other options:

   ?l lower-case ASCII letters
   ?u upper-case ASCII letters
   ?d digits
   ?a full printable ascii

There are a lot of ways to configure mask mode including combining masking with a wordlist if thats what you want, read the documentation here: https://fossies.org/linux/john/doc/MASK

Also are you sure your password is not salted?


Why does an nmap -sT scan show ports filtered but -sS shows ports closed

If you saved Nmap's XML output, there is an attribute of the <state> tag called reason, which will give you the reason Nmap chose to label a port closed, open, or filtered. This is usually something like "reset", "conn-refused", "syn-ack", or "port-unreach", depending on the kind of scan and the state of the port. This information can also be viewed in "normal" output by using the --reason flag or setting -d for debugging.

A common misconception is that the SYN scan (-sS) is "more stealthy" than the TCP Connect scan (-sT). At one time, and from one point of view, this was true: that is, from the perspective of the application running on the host. Back in the day, before IDS and stateful firewalls, your best indication of a port scan was application logs showing connections that were opened and immediately closed. The SYN scan, because it tears down the connection before it leaves the kernel, never crosses into the application, so these logs are not written. From the point of view of the network, however, the behavior of a half-open SYN scan (SYN, SYN-ACK, RST) is quite unusual, and can be a significant indicator of a port scan, even if only one, open port is scanned. In this case (scanning a small number of ports likely to be open, protected by IDS), the TCP Connect scan may actually be "stealthier."

-Pn (formerly known as -P0 and -PN) instructs Nmap to skip the host discovery phase, and instead assume that all hosts are up. The details of host discovery are well-documented, but it is possible that this behavior is triggering an adaptive firewall on the host. Adaptive firewalls can be tricky, since you get a variety of responses depending on your behavior and the speed of the scan. I would recommend slowing the scan with any of the timing options and reducing the number of ports scanned to a handful, until you get consistent results.


Is LastPass' Formfill inherently compromised?

Aren't you kind of already at a worst case scenario level with security when there is a keylogger installed?

It would be very dangerous to assume that LastPass (or any program) can protect plaintext from being read on a compromised machine.

This question/answer might help guide your security practices:
LastPass - Best practices on foreign devices


Is it possible for specific event logs to have been deleted?

As far as I know, there is no way to delete/alter individual events from an event log (Application, System, Security, etc.) under Windows. The "most" you can do is delete them, but even that would generate an event in the case where the Security log is cleared (Event ID 1102).

https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=1102

Apparently, Shadow Brokers released a tool called EventLogEdit that allows to edit events on the fly, even when the system is running.

https://threatpost.com/shadowbrokers-selling-windows-exploits-attack-tools/123027/

Though I have yet to read about it being used in any attacks so far.


Will webshells forever be a challenge for organizations?

Webshells is an attack payload, not a vulnerability. If you don't have a vulnerability that allowed the attacker to install a webshell in the first place, then you don't really need to worry about webshells.

Webshell detectors may be useful to catch an attack that already happens. But if the attacker already manage to install a webshell, then the attacker are already in too deep for you to trust the machine.

Another use of webshell is for sysadmin using a webshell to administer their machines, these shells must be run over HTTPS and must be authenticated to prevent abuse by attackers. If an attacker manage to get into one of this legitimately installed webshells, then it's a vulnerability in the authentication mechanism surrounding the webshell, not due to the webshell itself.


PCI scope for credit card forms that talk to Stripe, Braintree, etc

There are three FAQs on the PCI SSC website that will help you to answer this question.

https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/Why-is-SAQ-A-EP-used-for-Direct-Post-while-SAQ-A-is-used-for-iFrame-or-URL-redirect

https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/Why-is-there-a-different-approach-for-Direct-Post-implementations-than-for-iFrame-and-URL-redirect-what-are-the-technical-differences-and-how-do-they-impact-the-security-of-e-commerce-transactions

https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/How-is-the-payment-page-determined-for-SAQ-A-merchants-using-iframe

And also a helpful guidance document "Best Practices in Securing eCommerce -
https://www.pcisecuritystandards.org/pdfs/best_practices_securing_ecommerce.pdf

Simply it is harder for a criminal to attack an IFRAME'd payment page than it is to skim cardholder data out of the DOM if you host all the payment form fields yourself. Securing your website to A-EP is harder and will cost more than if you redirect or IFRAME. If that cost and risk is worth the benefit you’d get from hosting your own form fields then that's a reason to change. Personally unless your business is payment card data security, I'd always recommend giving the problem to someone else.


Automated secure code review can be done at anytime, it just might fail on incomplete or broken code.

I like my code reviews like I like my vulnerability scans from Qualys.  As often as possible without disrupting the business (everyday high risk assets, entire business on weekends). Every commit should drive an automated review IMO, and a failure should be an immediate feedback to the developer.

A code review doesn't require compilation of said code. In fact, from a security perspective code can pass a security review even if it can't compile.

It's better to find a problem earlier in the dev cycle and fix it, rather than build on it.


How is TDS authentication data protected?

It sounds like (§2.2.6.4) the password is obfuscated with some simple bit flipping:

Before submitting a password from the client to the server, for every
byte in the password buffer starting with the position pointed to by
ibPassword or ibChangePassword, the client SHOULD first swap the four
high bits with the four low bits and then do a bit-XOR with 0xA5
(10100101).

If you can pull the password bytes out of the TDS stream - which presumes TLS is not in use, and I don't know how well Wireshark's parser highlights the password data - just reverse the process to get the password:

After reading a submitted password, for every byte in the password
buffer starting with the position pointed to by ibPassword or
ibChangePassword, the server SHOULD first do a bit-XOR with 0xA5
(10100101) and then swap the four high bits with the four low bits.


How should I configure OS for fuzz testing?

ASLR is a broad term that encompases many different protections and techniques.
In general, basic forms of ASLR (eg stack randomisation) are used to make development of exploits harder or impossible - but do not prevent the triggering of the bug and a crash of an application. Fuzzing should work the same with aslr enabled or not.


From Wikipedia:

  A 2013 attack by Xie Tao, Fanbao Liu, and Dengguo Feng breaks MD5 collision resistance in 2^18 time. This attack runs in less than a second on a regular computer.[2]

This means that there's a weakness in MD5's ability to distinguish between different input data - that two arbitrary inputs may calculate the same hash.

  In April 2009, a preimage attack against MD5 was published that breaks MD5's preimage resistance. This attack is only theoretical, with a computational complexity of 2^123.4 for full preimage.[40][41]

This means that there is a theoretical weakness in MD5, allowing you to locate a preimage from the result value. If your MD5 is 508e01033ebe14c9c339b9928d7ce4bd, someone may in the future (given enough computational power) use the preimage attack to find that the original password was hfghfhghfhgf.


loadbalancer, 2 webserver, 1 webserver hacked , how to tunnel out?

The short answer is YES  an attacker can still pop a shell despite these conditions.

Using iptables you can deny all incoming but tcp 80 and 443 for http and https respectively.   In addition you can deny all outgoing traffic (but you'd want to still allow for updates). But this can only do so much. You want to protect your web application and it would be more beneficial to use a Web Application Firewall (WAF) like mod_security.

In a web application platform you should be more worried about the owasp top 10 and web application exploits.  A major concern is that an attacker exploits your system and then installs a backdoor like the C99 shell.   In this case iptables doesn't mean anything, you have to allow http/https and that's all the attacker needs.

Blocking access with iptables does make the system more difficult to compromise with a buffer overflow.  For instance download+exec shellocde is very common because it's a straightforward attack where the victim downloads and executes a backdoor.    However the attacker doesn't need a connection to upload and execute a file.  By using an egg-hunter as staging a buffer overflow exploit then the attacker can include a fair amount of complexity in the payload.   For instance this would allow the attacker to load his executable in memory and then write it to a file.

The bottom line is Defense in Depth  and security in layers.  Use the most restrictive firewall rulesets you can.


The solution for grepping airodump for specific mac:

airodump-ng mon0 2>&1 | grep "de:ad:be:ef:de:ad"

Thanks Kolanich. airodump prints to stderr, which had to be redirected to stdout to be greppable.


openssl - difference between passphrase (-k) and key (-K)?

A quick look at either the enc man page or the enc wiki page tells you the answer:

-k password
The password to derive the key from. This is for compatibility with previous versions of OpenSSL. Superseded by the
-pass argument.
-K key
The actual key to use: this must be represented as a string comprised only of hex digits. If only the key is specified, the IV
must additionally specified using the -iv option. When both a key and
a password are specified, the key given with the -K option will be
used and the IV generated from the password will be taken. It does not
make much sense to specify both key and password.

The key is the raw key used for encryption and should be combined with the -iv flag to specify the IV as well.
On the other hand, a password is used to derive the key and IV. How it does so can also be configured through various flags (see -iter, -pbkdf2, -salt). You should also read the Notes section of the man page for more details and recommendations.
The default digest used to generate the key is sha256 as of openssl 1.1.0 (see history section of the man page) but used to be md5.


Using OAuth2 with JWT, should a client pass along unused refresh tokens on a logout call?

I would suggest alternative - that I encountered in one OAuth server implementation.

Instead of requiring clients to provide all refresh tokens for invalidation simply store logout record for some time.

The logout record would contain user identification, client identification and logout timestamp.

Your server do not need to know all invalid tokens, because it can assume that any presented token - that was issued before last logout - is invalid.

You need only one logout record for user-client pair - as later logout would also invalidate earlier tokens. You also need to store it no longer than the longest token time to live.


Yes, easily. Removable devices (such as USB, or CD-ROM disks) have "AutoPlay" support on Windows. This is designed to auto-run installation CD-ROMs; just insert the CD and the installer starts.

It works like this: if in the root of the newly inserted device an "AUTORUN.INF" file is found, then its instructions are executed; they may tell the system to display a special, cooler icon for the device, but also to execute a program from the device. Both the autorun file and the program may be hidden so that you don't see them on the device, and it appears empty.

This executable could then do anything the logged-in user can do: it could run a search on the hard disk, and copy matching files on a hidden folder in the USB key. Or install a virus (that's how USB viruses such as Conficker propagate) that could then trasmit files at leisure through the Internet, if the computer was online.

It is easy to write such an autorun INF file using Notepad, and the executable can be built with any of several tools such as AutoIt, or it could even be a .CMD or .BAT file, which too can be created with just Notepad.

There are even "ready made" tools out there, such as, if memory serves, Slurper:

install the program
insert the USB key
choose the file search parameters (e.g. "Files newer than one week")
click "OK"
and the utility saves on the USB key an autorun file and executable that...

...

...when you insert the USB key in a computer, will search matching files and "slurp" them on the USB key, optionally even deleting them.

UPDATE: There also happens to be a howto on Superuser.

Workarounds: on Windows XP, keep the "SHIFT" key pressed while inserting the flash drive. This disables autorun execution. Also works on Seven, haven't tried on Windows 8.

And of course, you can disable the autoplay functionality (also here), which is always a good idea. You never know where those USB keys have been, after all.

(IPQ sells a write-protectable USB key that allows you to let someone copy a file on his untrusted-by-you computer, without said computer being able to infect the USB key with malware. Other WP keys are available e.g. on Amazon).


Is there a best practice regarding PDF files on website?

It's generally safer to force-download files, than to view them directly in the browser. However, in the case of PDFs, the PDF viewers in Firefox and Chrome are probably safer and more up-to-date than the ones from Adobe or Foxit

Assuming you let users upload PDFs:

Store them in a database, and not on the file system, unless you know exactly what you're doing (see Path Traversal attacks)
Serve them from a different domain name (like googleusercontent.com vs google.com), to avoid cookie theft/clobbering on your main domain
Validate on upload. Check that size is the same as reported size. Check that filename looks ok. Virus scan. Use a PDF library to strip embedded JavaScript (you could try Apache PDFBox)


Meaning of mod_ssl cipher suite put together and order of preference

Don't write, generate.
Use the Mozilla SSL Configuration Generator
Gory details
You get 20 lines of cipher suites. On my version of OpenSSL I get far more cipher suites.
As of today, I've got a total of 139 to pick from:
$ openssl version
OpenSSL 1.0.2d 9 Jul 2015

$ openssl ciphers -V 'ALL' | wc -l
131

$ openssl ciphers -V 'ALL:COMPLEMENTOFALL' | wc -l
139

Yeah. ALL does not in fact mean "All".
Now let's build the cipher list one option after the other and see how the numbers change:
$ openssl ciphers -V 'ALL' | wc -l
131

$ openssl ciphers -V 'ALL:!ADH' | wc -l
117

$ openssl ciphers -V 'ALL:!ADH:!EXPORT' | wc -l
110

$ openssl ciphers -V 'ALL:!ADH:!EXPORT:!SSLv2' | wc -l
106

$ openssl ciphers -V 'ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA' | wc -l
106

$ openssl ciphers -V 'ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH' | wc -l
106

$ openssl ciphers -V 'ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM' | wc -l
106

$ openssl ciphers -V 'ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW' | wc -l
106

The numbers didn't change at all for the last 5 options. So this suggests to me that that cipher string has been constructed for a different version than mine. And/or is just wrong/pointless.
EDIT2015-08-19: Wrong. As @dave-thompson-085 helpfully pointed out: the cipher suite count is not supposed to change for any keyword with the + sign in front. It only sorts what's already there. (I mistakenly thought that it both added and then sorted.)
But then again I've got no idea what the original author of the cipher suite string intended to do.
OpenSSL Cookbook
Ivan Ristic of SSL Labs publishes a free chapter of his "Bulletproof SSL and TLS" online. This is called the OpenSSL Cookbook (archived here) and does a good job of explaining the dreaded cipher suite string in the Cipher Suite Selection section.
TLS_RSA_WITH_RC4_128_SHA

If I try this can it blow something on my Apache?

Yeah. You'll lock out anybody who has blocked RC4 client side. (Such as Google Chrome. And Firefox is also moving in that direction.) Not a good idea. But easily fixed. Just put the old string back and restart Apache.
By the way: OpenSSL command line option parsing is terrible.
$ openssl ciphers 'RC4'
ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:AECDH-RC4-SHA:ADH-RC4-MD5:ECDH-RSA-RC4-SHA:ECDH-ECDSA-RC4-SHA:RC4-SHA:RC4-MD5:RC4-MD5:PSK-RC4-SHA:EXP-ADH-RC4-MD5:EXP-RC4-MD5:EXP-RC4-MD5

$ openssl ciphers 'RC4:!OPENSSL:+OPTION:PARSING:!MAKES:+ME:A:!BIT:+SAD:SOMETIMES'
ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:AECDH-RC4-SHA:ADH-RC4-MD5:ECDH-RSA-RC4-SHA:ECDH-ECDSA-RC4-SHA:RC4-SHA:RC4-MD5:RC4-MD5:PSK-RC4-SHA:EXP-ADH-RC4-MD5:EXP-RC4-MD5:EXP-RC4-MD5

Yes, that's the same output both times. And no error messages.
EDIT 2015-08-19: How to get Cipher Suite names
You listed some cipher suite names that don't actually exist.
Here's the general recipe on how to get the OpenSSL names: You list everything and then grep for the bits that you want. Like so:

SSL3-RSA-RSA-NONE-0-MD5

$ openssl ciphers -V ALL:COMPLEMENTOFALL | grep -i 'kx=rsa' | grep -i 'au=rsa' | grep -i 'Enc=None' | grep -i 'mac=md5'
      0x00,0x01 - NULL-MD5                SSLv3 Kx=RSA      Au=RSA  Enc=None      Mac=MD5

So the only cipher suite that satisfies these criteria is NULL-MD5. (That's the OpenSSL name. The official IANA name of this would have been TLS_RSA_WITH_NULL_MD5.)
Here's another example:

SSL3-RSA-RSA-NONE-0-SHA

$ openssl ciphers -V ALL:COMPLEMENTOFALL | grep -i 'kx=rsa' | grep -i 'au=rsa' | grep -i 'Enc=None' | grep -i 'mac=sha1'
      0x00,0x02 - NULL-SHA                SSLv3 Kx=RSA      Au=RSA  Enc=None      Mac=SHA1

And so on.


I wrote a basic SQL Injection for my simple login php, but doesn't work

Try:

1' or 1=1 --+

After injecting this query, your PHP code will work like this:

empID='1' or 1=1 --+


Take a look at the OWASP ASVS, the application security verification standard. It is focused on web applications and provides a guideline for the security tests you should perform during a penetration test. Especially chapter V1.2 and chapter V2 cover a broad range of tests that should be done in regard to authentication. Keep in mind that some of them cannot be performed black box.

If you are actually stuck on the login form, I recommend asking your client to provide you with valid user accounts. Doing a penetration test on a login form, which you cannot bypass, will not add much value for your client, so he should be glad to supply you with accounts.


Is a website published in an obscure directory comparably secure to being placed behind a login?

I'll extend on one point at a slightly more abstract level about why public authenticated spaces are preferable to hidden unprotected spaces. The other answers are all perfectly good and list multiple attacks one should know better to avoid.

Everyone with formal training should've heard at some point of the Open Design security principle. It states that systems must not rely on details of their design and implementation being secret for their functioning. What does that tell us about secret passwords vs. secret URLs?

Passwords are authentication secrets. They are known by a challenged entity that provides them to a challenging entity in order to authenticate. Both parties need a form of storage, and a communication channel. Stealing the password requires compromising either of the three. Typically:

The user must be trapped or forced into revealing the password
The server must be hacked into so that it reveals a hashed version of the password
The confidentiality of the channel between the user and the server must be compromised

Note that there are plenty of ways for authentication to be toughened, starting by adding an additional authentication factor with different storage requirements and transmission channels, and therefore with different attack channels (Separation of Privileges principle).

We can already conclude that obscure URLs cannot be better than passwords because in all attack vectors on passwords, the URL is either known (2 and 3) or obtainable (1).

Obscure URLs on the other hand are manipulated much more commonly. This is in large part due to the fact that multiple automated and manual entities in the Internet ecosystem process URLs routinely. The secrecy of the URL relies on it being hidden in plain sight, meaning it must be processed by all these third-parties just as if it were a public, already-known commodity, exposing it to the eyes of all. This leads to multiple issues:

The vectors through which these obscure URLs can be stored, transmitted and copied are much more numerous
Transmission channels are not required to be confidentiality-protected
Storage spaces are not required to be confidentiality or integrity protected, or monitored for data leakage
The lifetime of the copied URLs is by and large out of the control of the original client and server principals

In short, all possibilities of control are immediately lost when you need that a secret be treated openly. You should only hide something in plain sight if it is impossible for third-parties to make sense of that thing. In the case of URLs, the URL can only be functional in the whole Internet ecosystem (including your client's browser, a variety of DNS servers and your own Web server) if it can be made sense of, so it must be kept in a format where your adversaries can use it to address your server.

In conclusion, respect the open design principle.


Third party analytics/tracking javascript tags and PCI DSS

There is no specific PCI requirement about having 3rd party Javascript on your site or not.
Personally, I would not consider an analytics provider to be a PCI Service Provider under PCI DSS.
There are requirements however for your custom website to be securely developed (6.5), and for it to reviewed via security assessments or to be run under the protection of a WAF (6.6).
Additionally there are requirements for vulnerability scans (11.2) and external penetration testing (11.3.1).
A third party library hosting your website should be flagged as a vulnerability under one of these requirements. During a normal, non PCI security test, this would usually be worded that there is a third party library present and this risk should be reviewed to ensure that the library is trusted, and the domain it is hosted on is also trusted, should this is an external domain. If the third party domain is untrusted, or if it is compromised then it would be a risk to your environment and to your PCI compliance. That is, something hosted on google.com would probably be OK, but something hosted elsewhere may not.
During a security test, this is usually initially ranked by a pentester as a low risk vulnerability. However, it should be reviewed by the business. If your business accepts this risk, then simply document it as such. If you consider it a risk that cannot be accepted, then you should document the steps taken to mitigate such a risk. For example by putting the third party script through a code review, and then hosting the script locally rather than this being fetched from a third party domain. Also, browser subresource integrity is now widely supported, in which the browser rejects remote scripts should they be altered: https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity
PCI DSS is mostly about documenting how you have dealt with the spirit of each requirement, rather than a black or white list of cans and cannots. Then, should you be audited you can take the QSA through your business decision process to demonstrate how you are meeting the requirements above.
Disclaimer: I'm not a QSA, nor, more importantly, your QSA. Only your qualified QSA can accurately assess your responsibilities under PCI DSS, as they will have full knowledge of your business and how it relates to your card processing activities.


Can I tell if my USB flash drive has been plugged into other computers?

Unless your USB drive has some special features for this (I'm not aware of any drives doing so), there is an easy answer: you can't know whether it was connected to another computer, unless the operating system wrote to it. For example, Mac OS X likes to write some meta information for Finder, their file system explorer, to any disks it gets hold of.

There are special forensic tools and hardware solutions to fully prevent this, though; and simply read-only mounting the drive also will not leave any traces (eg. using Linux).


How does a private OpenPGP key's passphrase add to its security?

If you have an encrypted private key, this means a private key was generated from random numbers and then symmetrically encrypted using your passphrase. With other words, the private key is not generated by the passphrase, but only protected through it.

  When I create a key-pair, the password I enter is a passphrase that encrypts my private key only on my machine, and it is NOT a passphrase that is needed to decrypt encoded messages, correct?

The private key is encrypted using your passphrase, that's right. But this also means if you want to decrypt a message (which requires your unencrypted private key), you have to enter your passphrase to decrypt it.

  If the above statement is correct, does it mean that the password I use to decrypt a message is actually just the passphrase that unlocks my private key: therefore if I loose my private key (let us say, drop my computer in the Pacific), so even if I reveal my passcode, nothing can be done since it is used only to unlock a specific file?

Then again, of course the passphrase alone is not sufficient to decrypt the message, so your "dropped into the sea" metaphor works out. The passphrase is of no use without the encrypted private key.

  The brute-force technique breaks an OpenPGP encrypted text only via the private key (which is usually very long); consequently the brute-force technique used to break the private PGP key is done via the passphrase (known to the owner of the key) when the key was created for 'storage purpose'. Is that correct?

Of course, the encrypted private key might be revealed by brute-forcing the passphrase (but with reasonable/default settings of GnuPG and an adequate complex passphrase, this is no practical attack surface as long as the algorithms used are not proved insecure). But at the same time, an attacker might of course also try to guess/brute force the (unencrypted) copy of your private key. Given you had vast and sufficient computational resources, you could brute force any of them; brute-forcing the passphrase is likely less expensive but require knowledge of the encrypted private key, while brute-forcing the key requires nothing but an encrypted message.


Use subject key identifier for certificate pinning

Can we use the Subject Key Identifier for "certificate" pinning ? Is it secure to rely only on the SKI?

The Subject Key Identifier (SKI) is a field (X509v3 extension) contained in the certificate. Even though it is typically derived from the subject and public key it does not need to be.

This means that an attacker could easily create a certificate which contains a specific SKI which would get accepted if pinning is done against the SKI. This of course makes it unusable for secure certificate pinning.

  Are there other fields that we could use for pinning securely (e.g. Certificate hash) ?

The certificate hash is no field of the certificate but it is simply a hash over the certificate. Provided that a secure hash is used (i.e. SHA-256) it is usable for certificate pinning. One could of course also store the full certificate for comparison instead of only a hash of it.

Useful for pinning is also the public key or a secure hash of the public key. This makes it possible to accept multiple variants of the same certificate with different expiration times as long as the public key stays the same when reissueing the certificate. But this is usually called public key pinning, not certificate pinning.


AWS serverless architecture compliance with PCI DSS 11.3 penetration testing segmentation

Very interesting question.

In theory you could deploy your lambda into a VPC, and then your lambda exists on a network segment with other lambdas that are sensitive. But where are you storing your data, backing it up, logging your data? So many questions!

So yes, you'd probably need a pentest, or at least someone to take a long hard look at your serverless environment to ensure no data is leaking out.

Things like:

Is the lambda writing sensitive data out to cloudwatch logs?
Is Cloudfront caching any sensitive cardholder data? Do you have lambda@edge running there that might come in contact with sensitive cardholder data?
Are you backing up the data to S3 -- who has access to that S3 bucket?
Where are you storing data? In RDS, or DynamoDB or a traditional DB. Is that DB on the same network as the lambdas?
Are there any EC2 that are directly connected to/from the lambdas?

In order to run a penetration test on AWS, you need to first explicitly get their permission. Link here


Door locks & deadbolt appropriate for exterior office door with decorative glass next to it

The window pane in your example photograph is wide enough to allow entry for more than a gloved hand; an entire intruder body could fit in the hole, should the pane be wholly removed. At that point, the lock becomes irrelevant.

Moreover, for safety reasons, chances are that the unlock mechanism from the inside must remain operable without a key; otherwise, someone could be trapped and unable to exit in a swift manner should a fire occur in the room. Under these conditions, there is probably no lock which will ensure security (or even simple improve security by a non-negligible amount) as long as there is a breakable window large enough to allow the "gloved hand". Also, note that an intruder who is ready to break a window could also have a crowbar; a wooden frame won't last long.

Therefore, I suggest that you do not look for a lock but for some way to reinforce the window itself, or for a deterrent (motion detectors and alarm in the office; armed guard and/or fierce dog on the inside or on the outside; additional protection layers, e.g. a safe or strongbox, for important assets in the office; and so on).


How to identify the sender of a message in asymmetric encryption?

In typical public-key cryptography, a user generates locally his public/private key pair. The private key is generally chosen at random and the public key is easily computed given the private. The problem in this approach is that you have no guarantee that the public key of a specific user is indeed associated to his private key; an man-in-the-middle can intercept the communication and substitute the public key with his public key so he can later decrypt the messages with his private key. To overcome this problem, usually a trusted third party issues certificates to prove the ownership of a public key. The certificate includes information about the key, information about the identity of its owner (called the subject), and the digital signature of the third party that has verified the certificate's contents. X.509 is a standard defining the format of public key certificates. Another solution to overcome this problem is to use identity-based cryptography. It was introduced in 1984 by Shamir (the 'S' guy is 'RSA') but his scheme was only working for signatures. In 2001, Boneh and Franklin proposed an encryption scheme using bilinear pairings over elliptic curves.


Would it be possible to overload a large part of the internet, and if so then how?

First we need to understand what exactly you're asking. Every time someone sends a packet on the Internet it consumes some of the potential bandwidth of the Internet. Just like when a car drives down a road, no other car can drive in that same spot, so you have one less available spot on the road.

If we continue that comparison, a single site sending out many cars can easily jam the roads around it, watch the madness after any sports game is over and all the fans are leaving at the same time. But this only causes very localized disruptions, the same is generally true of the Internet. But the attacker used an amplification technique to do more congestion damage than they could have done alone. This employed unwilling 3rd parties, who had specific vulnerabilities. This allowed the attacker to generate much more congestion than they could have alone.

So there are two more important questions, which you will never find in the news as they're technical. The news is almost exclusively concerned with dire predictions that average people can understand, and the more sensational the better, regardless of accuracy.

The questions:

Could an attack be constructed with such scale as to affect a large portion of Internet traffic in a noticeably detrimental way?
Are there vulnerabilities in key systems of the Internet which can allow relatively little attacker effort to result in the average users' experience being disrupted meaningfully.?

As to the first question, it's highly unlikely. As you've seen attacks can be constructed which will disrupt certain very localized portions of the Internet. Spamhaus represents a very small portion of the overall Internet, and the attack was mitigated largely by a single other Internet entity. The attacker had significant resources compared to most potential attackers and was still not able to fully overcome Spamhaus and Cloudfare collaborating. As fun as it might be to theorize what might be possible, it's more than one giant leap from taking out Spamhaus to afflicting the Internet as a whole.

To the second question, this is somewhat more plausible. The Internet relies on a variety of key infrastructure. Many times security takes a back seat to functionality, especially where there are strong economic forces (ie, cheaping out). A great first example is BGP, which is what helps connect the many individual networks that make up the Internet. BGP was accidentally "hacked" by a Syrian ISP in 2012, which ended up disturbing a large portion of IP Routing. This wasn't malicious, was quickly fixed (quickly considering the scope), but illustrates how a small corruption can cause massive problems if systems aren't secured against such.

If I could predict the next such occurrence, I would be a millionaire. The best defense we have now is thoroughly analyzing systems for vulnerabilities, understanding them, developing best practices to guard against them, and vigilantly implementing appropriate measures.


Turing-completeness impact on system security

An exploit that provides a turing-complete execution environment allows the attacker to run any algorithm they wish. They will not be limited by the number of available instructions.

A system of data manipulation rules (script, program, instruction set, etc) is considered turing-complete if it can be used to simulate a Turing machine. Turing equivalence states that two turing-complete constructs are identical in their capabilities. In other words, if someone can execute turing-complete code on a vulnerable computer, they can compute anything, barring resource limitations. The Church-Turing thesis conjectures that a Turing machine can compute any value that can also be computed by an algorithm. From the Wikipedia article:

  To show that something is Turing complete, it is enough to show that it can be used to simulate some Turing complete system. For example, an imperative language is Turing complete if it has conditional branching (e.g., "if" and "goto" statements, or a "branch if zero" instruction; see one instruction set computer) and the ability to change an arbitrary amount of memory (e.g., the ability to maintain an arbitrary number of variables). Since this is almost always the case, most if not all imperative languages are Turing complete if the limitations of finite memory are ignored.

This is particularly relevant in the case of ROP, an exploitation technique where existing code is executed out-of-order. A sufficiently complex vulnerable program can make for turing-complete ROP, which means that the attacker is not limited to only certain types of computation.

So, why does something as abstract as computation matter, rather than just the capabilities of the exploited program? Imagine if you had access to a shell, running as root. Obviously root can do pretty much everything, but what if the only things you can do on the shell is run echo, id, and cd? No if statements, no mv, no sed... You'd be pretty limited in what you can do. That scenario would not be turing-complete because you do not have enough commands to make it turing-complete. A turing-complete ROP chain is a similar concept, but rather than utilizing shell commands, it utilizes machine code. If you can only run a few instructions, you can't do much.


SSL Breach - Does the latest BEAST vulnerability mean SSL Issuers now have to worry about integrity?

There are two parts to SSL/TLS: ensuring the confidentiality and the integrity of the communication, and knowing who each participant is. Most of the issues related to SSL have to do with the second part, which is rather more complicated. You can read some explanations on this topic in the question when is it safe to click through an SSL warning message?

Consider what would happen if you took certificate authorities out of the picture. Certificate authorities provide a public-key infrastructure. Without them, servers would all have self-signed certificates, and each client would have to figure out whether the server is the one they intended to talk to somehow (for example, by having been given the server's public key over some trusted medium such as meeting with the server administrator in person).

The SSL flaw uncovered in the BEAST exploit concerns the first part of SSL, the one that is unrelated to the PKI. It concerns the way the cryptographic primitives are used to build a secure channel, not the way for the two ends of the channel to authenticate each other. Therefore certificate authorities are cannot be responsible for the flaw. It is not their fault if any keys are discovered through this attack (though as I understand it the attack allows the attacker to decrypt the content of one transmission, but not recover the server the server's private key anyway).

This doesn't mean that there isn't a CA somewhere that has contracted to pay a hefty sum if such a vulnerability in SSL was found. But it would not be paying for something that it was responsible for, it would be acting as an insurer. For that matter, there may well be professional insurers who end up reimbursing damages caused by this vulnerability — but I don't think any CA is in this market.


What is the disadvantage of using spoofing protected version of ARP protocol

Question is : why the ARP modified versions hasn't been used on large scale yet ?

What is the cost of addressing this versus the risk?  ARP is a local subnet issue. If someone is already successfully on your LAN you probably have a much bigger problem because they can still do attacks at higher layers of the communications stack. Is this where you want to spend your dollars versus other problems?

Port level authentication such as 802.1x, TLS, VPNs, and other protocols may provide adequate protection in the view of a risk assessment or you may be implementing protections at the switch/bridge. There is also likely the cost and complexity of management versus the return on investment. Then again, there may also be a marketing issues where no one has commercialized and convinced the people with the check book to spend on this, especially when things like DLP and SIEM are just so much sexier, costly, and fun.


You cannot reasonably prevent "sequence passwords" unless you have a human administrator inspect them (which would have its own set of security issues, not even considering the expensiveness of human labour). You can try to automatically detect such patterns, but you cannot hope to find them all; besides, if you only keep hashes of the previous passwords, then pattern detection will have to be a guess-and-try process, which will be expensive.

Moreover, your users will find the pattern detection system inconvenient (since it prevents sequence passwords that they are quite fond of), so they will fight against it: they will be angry (not a good idea when users are customers), and they will be creative, finding new sequences that you did not thought of.

Benefit to changing passwords is not invalidated by sequence passwords. Benefit to changing passwords is invalidated by regular password changes being bloody useless (see this question for more discussions on that subject). The flaw is not in the "sequence passwords"; it is in the policies that mandate regular password changes for the sake of misunderstood very old traditions that don't make sense when the users wield computers and try to buy stuff from Web sites, instead of wielding rifles and trying to send enemy soldiers to the afterworld. These policies are the reason why users resort to sequence passwords in the first place.


CAPTCHA Bypassing with Captcha Clipping Attack is Like MiTM between servers, Is that even Possible?

This can only be done if somehow you intercept the server traffic to the CAPTCHA provider. It can be done by compromising the server itself, its network, or the DNS server it is using. Every method requires the invasion of the server or one of the systems it rely on, you cannot simply detour a server's traffic from your PC home without achieving something like that first.


I ran the code through your links, and they are all unable to translate the encoded text like &#39 and %3C.

Decode those parts first, then look for any left over encoded text (there is some) run the result through a deobfuscator, taking care of line breaks.

The first part is the code to decrypt the dF() text.

To help the deobfuscators, try running the decoded code through a "beautifier". It can resolve any remaining line break and other syntax issues. And if you haven't already, remove the <script code etc. so that the javascript deobfuscators are only dealing with the javascript and not the PHP code.

I have been successful in decoding it and recovering the URL using the steps above.


Should I be thinking about security at the database row/document level?

Generally, what you are describing is the responsibility of the application layer and not the database layer. Your application needs to make sure that only mutually accepted friends are added to the list, and that proper authorization is required to access data.

This responsibility can not really be moved over to the database in any simple way, as Pascal explains. In the end, you will always need some mechanism by which the app tells the database that two people are friends. If the app can be tricked to to "lie" to the database, you have problems no matter what.

What you could do is block the app from updating tables, and instead rely on procedures that enforces your security contraints. But now you have just moved the problem to a new place. And probably to a programming language and development environment that is worse to work in. Trying to put application logic in the database isn't a hit.

So the application layer is the relevant one here. Focus your energy at securing that.


A new exploit in town: SWAPGS. How and why did it happen?

The issue with the SWAPGS instruction and its malicious use was that it was not known to be malicious. We've got to remember that we're talking about extremely complex systems and very few people know these structures in depth. Quite a few of these types of vulnerabilities has been discovered by private entities and not the chip manufacturers. This issue was discovered back in August 2018 - which is about half a year after Spectre and Meltdown. But Intel didn't want to address until the disclosing party insisted and presented further evidence. So another answer to your question is - politics.

Bitdefender(I have no affiliation or interest in promotion of them) has released a whitepaper on the topic which explains the entire issue in high detail which I can highly recommend: https://businessresources.bitdefender.com/hubfs/noindex/Bitdefender-WhitePaper-SWAPGS.pdf


ret2libc calling function arguments order

It can be confusing indeed. What you have to consider is that you are not interacting with the stack in the same way you would if you were writing code. The stack grows down, but your data in the buffer goes from bottom to top. Also, items are popped off the stack from the bottom.

Your buffer overflow allows you to populate the stack in one shot. You will overwrite the stack starting at the bottom. So, when a ret is reached, the program pops the next thing on the stack, which is the address of system() in your case. It then pops the next thing, which is the return address for that function. Finally, the last thing to be popped off the stack is the argument to system().

In summary, it just has to do with the ordering of the stack. It may help to watch the stack while stepping through the program after overflowing the buffer (using GDB or debugger of choice).


CSRF Encrypted-Token pattern protection implementation

Here is a very condensed breakdown on the differences between the Encrypted and Synchronizer Token patterns:

The Encrypted Token Patterns does not require server-state
It does not require cookies It does not require two tokens
It does not require any effort on the client-side other than including the token
in HTTP requests
It does not require any other application in a subdomain to be XSS-proof

Essentially, the main difference from an implementation-perspective is that the Synchronizer Token Pattern requires 2 tokens, whereas the Encrypted Token Pattern leverages a single token. Michael's answer covers your questions in terms of timeout and UI-refresh. For more information on the subject, I've just posted this entry on how to leverage the Encrypted Token Pattern in ASP.NET. I'm happy to answer any questions you may have on the subject (I designed the Encrypted Token Pattern).


How can I verify the certificates when connecting to an FTP server with Filezilla?

FileZilla never automatically trusts certificates.

You mention a chain of trust, but not much about the root certificate. Does it seem like one that should be trusted? You could compare the fingerprint of the provided root certificate to one in the certificate trust store on your local machine. This would emulate the basic/default behavior for most TLS clients, to trust the client because you trust the CA.

To be particularly fastidious you could contact the owner of the FTP server and ask what the fingerprint of their certificate is. When connecting, if the presented certificate has the correct fingerprint and you trust it, your future connections will henceforth be secure from MITM attacks.

Supposing the FTP owner is not particularly helpful, another way to increase trust would be to observe the certificate fingerprint over an extended period of time using several different internet connections and devices. If you only ever see a single key fingerprint it would indicate that either nobody is attempting an MITM attack or that they are successfully doing so every time you connect. Supposing you are an optimist, trust the key with this fingerprint.


What can I do with a radius shared secret?

The RADIUS client and server use the shared secret to encrypt the password.  If you know the shared secret, and you can capture RADIUS packets with encrypted passwords, you can decrypt them and get the user's unencrypted password.

Wireshark includes the ability to do this, of course:

  perhaps dump the database?

No, the shared secret is used to protect things on the wire, not anything on disk or in the database.  You'll note that the shared secret you found was specific to a client IP address; a RADIUS server can use a different shared secret for each system it's extending authentication services to... which implies, in turn, that it's not for the back-end password (else you'd need N copies of the back-end password for N shared secrets).

  this radius server is used together with a krb5 server for authentication

Usually when a RADIUS server is used with KRB5, it's to extend authentication to dumber devices that don't support Kerberos. So you don't have to worry about Kerberos being tunneled over RADIUS; it's merely providing a down-level front-end to the back-end database that's part of Kerberos.  It may do so by speaking RADIUS on one side and Kerberos on the other, but that doesn't change the fact that the RADIUS packets on the wire are vulnerable if you know the shared secret.


Why OWASP considers TouchID as insecure?

I believe what OWASP are referencing is the use of TouchID Local Authentication, which isn't very secure on its own, but is unfortunately the most common implementation. Effectively all it does is check if the fingerprint was correct and return a true/false. The secrets (e.g. session IDs) aren't actually protected by the authentication mechanism. This check can be bypassed by a local attacker as they can just modify the app binary to remove the check, and iOS won't enforce any additional verification or require that the phone is actually unlocked.

OWASP generally suggests that you utilise Keychain for storing app secrets, using an access control list (ACL). This ensures that the data cannot be accessed without iOS itself performing a presence check, as per the specification of the data protection class in use (e.g. kSecAttrAccessibleWhenUnlocked means it'll only allow access to the data if the phone is unlocked). This prevents the check from being bypassed as the sensitive data is stored and protected by the OS. You can read more about this in the Encryption and Data Protection section of the iOS Security Guide [PDF].


This provides zero authentication of the individual calling or the authenticity of the original call making it through to the server.  This may have been intended as a way to verify the request had not been altered, but unless it is actually forming a signature rather than a hash, then this provides no security.

If the hash is signed, it becomes a secure way to authenticate the parameters of the request are authentic as the hash allows verifying that parameters have not changed and the signature prevents an attacker from generating their own hash to match false parameters.


Facebook ads affected by colleague's browsing on different computer

They are using same public ip address I guess. Is quite strange because usually, Google/Facebook shouldn't track your ip for many reasons:

Because Ip addresses cannot reliably identify an individual user, advertising services track visitors through small files on their browsers called cookies.
When you visit a website that is advertising with Google AdSense, it tells your Web browser to create a cookie with data to identify you as a unique visitor

Anyway, Google's advertising services is a "mistery" how it works and Google change its mechanisms constantly, like for SEO. Is like the "Coca Cola's secret". I've been in courses about SEO and they teach to you a lot of techniques to improve it and they work, but nobody knows 100%. There is always a small uncertainty factor.

So, usually the Ip addresses are don't used to track visitors, but if you are pretty sure this is happening, maybe Google changed something. Maybe they do use a visitor's current IP address to help select ads.

EDIT Yes, I can confirm it. I found this link on Google Documentation. Look at the paragraph which say:

  Even if you opt out of Ads Personalization, you may still see ads based on factors such as your general location derived from your IP address, your browser type, and your search terms

EDIT2 Thanks @TTT for your comment. You are right. Anyway, Facebook ads works in similar way like Google ads.


I suppose you need to compile the code disabling the stack protections. For example, try in this way:

gcc -g -fno-stack-protector -zexecstack  -o vuln vuln.c

-g (enable debugging information)

-f no-stack-protector (disable extra code to check buffer overflow)

-z execstack (make the stack executable... where your shellcode will be)


It is very simple wireshark has a feature were you select a packet dump. You can then enter a wpa-psk key the second you enter that all data will be decrypted in packet capture.

Reference/Tutorial: https://wiki.wireshark.org/HowToDecrypt802.11


Is IP whitelisting safe enough for a HTTP Basic protected service available on the internet?

Just some clarifications/assumptions on my part based on your question. You would like to expose a micro-service API running on Kubernetes to the internet. The API in question is running on top of an HTTPS server which allows for TLS encrypted communication. What you want to know is if white listing is sufficient for protecting your API. Let me know if I missed any thing.

My initial answer is no, this is not secure. Or rather, it's not as secure as I think it should be. You have not made any mention of securing the API in anyway other than IP listing. Is this an open API that allows access to sensitive information? How else are you going to establish trust with your remote systems and users? Are you sure that your remote systems will always come from the same IPs? What happens if one of the IPs is compromised?

Going beyond my initial barrage of questions, I think we should look at a couple of key principles that I rely on when trying to design security solutions for companies.

First, I never trust the network unless I absolutely have to. Any chance I can implement a solution that performs verification, I do that. Whitelisted IPs do not pass this measure because an IP address is not a form of identity. IPv6 does have some capability to perform identity through an address, but it's not widely adopted and I don't think the standards are mature enough yet.

Second, identity is the biggest factor to your security. An attacker can come from anywhere, and in some industries the biggest risk for attack is actually from within your own company. Healthcare has the largest internal risk with a whipping 65% chance of being compromised from within. You mustknow who had access, when, and whether or not they should have access. You should know the machine they had access with and whether or not it's known. And if you can afford it, having the behavioral history of actions to check the traffic is a major benefit too. All of these identifiers are what will protect your API.

Third, once you have an identity management system in place, you need to ensure that you can properly authorize and audit user access.

Now, if you have all of these things built into your API already, then all the best to you. Overtime, you may find it beneficial to migrate from a white list to a blacklist which allows you to block the trouble makers. You can even automate this with the right types of scripts/automation and reduce the chance of blocking your clients. This will help to reduce your operational burden and reduce the potential impact to your clients, a win win.


Here is a good resource to get started. The author wrote about 14 articles around WiFi security and hacking. If you are looking for something more like a textbook, I haven't found a great resource that focuses on WiFi hacking.

How to hack WiFi - Getting Started

List of all of the articles in the series


Smartphone motherboard - Does it hold any data?

It really depends on the device itself - without any specifics, I don't think we can really give a definite answer. I'm assuming the phone is Android, as iOS would probably be encrypted. The only real concern is any storage chips that might exist on the device.

It probably contains flash memory. Yes, unless you wiped it, confidential data will still exist on it. Usually, the operating system of the device, along with its core configuration files are stored here. This could contain anything from Wi-Fi SSIDs and passwords to SMS data.

The baseband chip is also rather likely to have cached information from the SIM card. Why? Because basebands (almost always) run proprietary software, which, in theory, could keep a copy of phone logs and SIM card information like IMSI and your phone number. However, because of the design of SIM cards, it is not possible for the baseband software (and hence an attacker) to extract the shared secrets from the SIM and clone it.

Overall, the chance of anything happening as a result is low, but it's probably worth changing your passwords. Ask the repair technician what they did with the old motherboard, and if you can get it back, dispose of it properly using thermite.


I'm not sure what you're comparing SSH with the "very long password".  SSH provides a secure means to send your user login and password to a remote server.  Or you can use a client's public key.  Asymmetric keys are generally harder to break because they're not subject to users creating bad passwords.  Public Key Based Authentication is preferred for that reason.  You can white-list specific public keys for your user (and IP) so that not just anyone can login with your username, and from any computer.  This white list is contained in /home/<user>/.ssh/authorized_keys.

Basics of SSH:

Server presents its RSA public key to the client.  The client
manually verifies that it trusts this key before continuing.
SSH uses Diffie Hellman to establish a shared secret value.
The shared secret along with lots of key exchange data is hashed
together and signed using the server's private key.
The client can verify this signature using the server's previously
trusted public key.
Both sides now have all the information needed to generate session
keys.

From section 7.2 of RFC4253

7.2.  Output from Key Exchange

   The key exchange produces two values: a shared secret K, and an
   exchange hash H.  Encryption and authentication keys are derived from
   these.  The exchange hash H from the first key exchange is
   additionally used as the session identifier, which is a unique
   identifier for this connection.  It is used by authentication methods
   as a part of the data that is signed as a proof of possession of a
   private key.  Once computed, the session identifier is not changed,
   even if keys are later re-exchanged.

   Each key exchange method specifies a hash function that is used in
   the key exchange.  The same hash algorithm MUST be used in key
   derivation.  Here, we'll call it HASH.

   Encryption keys MUST be computed as HASH, of a known value and K, as
   follows:

   o  Initial IV client to server: HASH(K || H || "A" || session_id)
      (Here K is encoded as mpint and "A" as byte and session_id as raw
      data.  "A" means the single character A, ASCII 65).

   o  Initial IV server to client: HASH(K || H || "B" || session_id)

   o  Encryption key client to server: HASH(K || H || "C" || session_id)

   o  Encryption key server to client: HASH(K || H || "D" || session_id)

   o  Integrity key client to server: HASH(K || H || "E" || session_id)

   o  Integrity key server to client: HASH(K || H || "F" || session_id)

   Key data MUST be taken from the beginning of the hash output.  As
   many bytes as needed are taken from the beginning of the hash value.
   If the key length needed is longer than the output of the HASH, the
   key is extended by computing HASH of the concatenation of K and H and
   the entire key so far, and appending the resulting bytes (as many as
   HASH generates) to the key.  This process is repeated until enough
   key material is available; the key is taken from the beginning of
   this value.  In other words:

      K1 = HASH(K || H || X || session_id)   (X is e.g., "A")
      K2 = HASH(K || H || K1)
      K3 = HASH(K || H || K1 || K2)
      ...
      key = K1 || K2 || K3 || ...

   This process will lose entropy if the amount of entropy in K is
   larger than the internal state size of HASH.

Once the encrypted channel is established the SSH protocol begins the client authentication based upon parameters you've given it.  All of this is performed securely through the encrypted channel.


Is it possible to have two SSL certs - one wildcard and the other single sub-domain for a single domain?

Can two of these certs co-exist for a single domain and not cause clash?

As long as both certificates are valid and match the hostname it should be no problem from the client side.


Should I have special emoticon handling for compliance, audit and logging?

This is an interesting question which to be honest, I'd not considered. However, now
that you raise it, I think you may be onto something. While I don't believe there is
anything in any of the regulations which explicitly require you to consider this sort
of information, I suspect this is simply due to the letter of the law sometimes being
behind social evolution/development. In most cases, the intent of regulations is
fairly clear and for some of these, the use of emoji as your examples indicate, would
be considered to be unacceptable and it could be argued that all /reasonable/
attempts should be taken to monitor for such practices and appropriate action
taken. Of course, /reasonable/ is somewhat debatable, but such debates are usually
expensive and come down to the sort of legal arguments companies are reluctant to
pursue unless forced to because of their unpredictability.

With respect to the question of whether you should or should not search for emoji in
audits etc, I think this depends on your position and the level of executive
support. If you are an external auditor, especially a government based auditor who
checks for compliance with legislation etc, then you probably do need to consider
searching for these /patterns/. If a company is using emoji to communicate
information which would be considered illegal due to anti-discrimination etc, what
they are doing is illegal and probably needs to be addressed. As an auditor, knowing
this sort of practice occurs probably creates a moral duty if not a legal
one. Unfortunately, resourcing, budgets and political pressures can come to play in
such situations, so executive support/decision is probably required.

If on the other hand you are an internal auditor, then things may be a lot more
complicated. Executive support would be even more important and a lot will likely
depend on the philosophy or moral position of the company. For example, if you work
for an insurance company and this information is actively used to assess premiums or
if you work in a company which has an 'unofficial' policy against employing people
based on their sexual orientation, drug history, criminal convictions etc and that
company's HR department is using emoji to communicate such information in an attempt
to avoid possible auditing issues, raising this issue will likely be career limiting
and unwelcome. On the other hand, if such use of emoji is unofficial and not
supported by the executive, then you may get a pat on the back for raising the issue
so that the executive is aware of the risks/practices and can make an informed
decision on what to do. Regardless of 'official' or 'unofficial' corporate position,
this also has the potential of opening a can of worms, which is rarely welcomed by
the executive, so there is also the danger of 'shooting the messenger' syndrome. Once
the executive is made aware of something like this, it isn't easy for them to just
ignore it and if it should lead to some sort of legal of regulatory issue, you have
removed their 'we were unaware of the issue, but will now take action to address it'
argument.

Then of course, there is your own personal moral position and
it may be necessary to consider whether this is the sort of company you want to work
for.

From a technical standpoint, I don't think you have much of an argument. Including
the ability to search and analyse for the use of emoji may well be a PITA, but that
is not sufficient reason to not do it. Lets face it, auditing in general is often a
PITA and there are very few people I know who really welcome the growing amount of
compliance we need to meet and monitor for.

  Searching for emoticons is hard: The standard text delimiters (comma,
  bracket, etc) are interpreted by the on demand query engines as AND,
  NOT, OR, a phrase, or order of precedent

Yep, it will likely be harder to define the searches, but most search systems do have
the ability to escape special characters or otherwise encode them to use them in
searches. Hard is usually not sufficient justification for not doing something.

  Parsing emoticons is hard: The backing store may mangle an individual
  emoticon into more than one character, or be ignored completely

Well, I'm not sure it is that hard. Lets face it, the interfaces which display these
emoji are able to deal with them. Character based emoji are not too difficult to
handle, although the lack of standardisation does mean you may need multiple,
possibly per application, encoding sets. Image based emoji are much harder, though it
is likely possible using various image matching algorithms, but this would be a lot
of work. With respect to the backing store, this would be a limiting factor. If the
store ignores or encodes emoji into a form you can process, then you can't do it - it
is a limitation of the technology. However, if it just encodes them into a form which
is more difficult to handle, this may not be sufficient - because it is hard is
probably not a sufficient excuse. .

  Storing emoticons is hard: Spurious Tuples result in invalid joins and
  queries

This one probably doesn't stand up. You don't have to store the actual emoji. Once
you have identified it, you can encode it in any number of ways which work with
whatever store you are using.

This is a good question and should generate some debate. There is probably some real opportunities for research in this area.


Scanning WordPress for security vulnerabilities

You should notice that WordPress is a content management system (CMS). Systems like that are designed for modifying web pages. That includes adding and modifying HTML, JavaScript, HTTP redirects etc. – and even working with databases.
Therefore, your whole security scanning approach is flawed: the findings described as security problems are within the normal operation of WordPress. It would be catastrophic if such functions were publicly available, but they are restricted with a password-based login. That's the area of security you should focus on: whether it's adequate for you or not:

Do you use strong passwords? Are there password requirements for all users?
Would you need multi-factor authentication?
Should the administrative areas be restricted to certain IP addresses?
Could the content be served as static pages e.g. from a proxy or CDN? That would ultimately limit the access to all dynamic content including the administrative tools.

Furthermore, are you responsible for security auditing open source code made by others, or just the source code of your web application project? Because this is about the WordPress core, according to Wordpress Security:

The WordPress Security Team is made up of approximately 50 experts
including lead developers and security researchers — about half are
employees of Automattic (makers of WordPress.com, the earliest and
largest WordPress hosting platform on the web), and a number work in
the web security field. The team consults with well-known and trusted
security researchers and hosting companies.

If you have better resources than that, you could find and fix security problems in the WordPress core. Please contribute the findings to the WordPress project and you'd help in securing 63.6% of the web sites in the world. If Micro Focus Fortify Audit Workbench was the ultimate solution for that, it would have already been used.


phpBB under nginx, htaccess protection is lost – what are the risks?

There is also a config file for NGINX which should protect these files:

https://github.com/phpbb/phpbb/blob/3.1.x/phpBB/docs/nginx.sample.conf

# Deny access to internal phpbb files.
        location ~ /(config\.php|common\.php|includes|cache|files|store|images/avatars/upload) {
            deny all;
            # deny was ignored before 0.8.40 for connections over IPv6.
            # Use internal directive to prohibit access on older versions.
            internal;
        }

If people can access / retrieve the contents of the files, they may get your database credentials and other critical data.


Restrict mobile phones to specific Access Point (WIFI Router)

I know using Apple Configurator it is possible to set a restriction on managed devices to "Join only Wi-Fi networks installed by a Wi-Fi payload" which effectively limits the SSIDs the device can connect to, and the authentication methods to use.

This comes with the obvious health warning that, if the network the device is restricted to goes down or is unavailable/misconfigured, you will be unable to manage the device.

https://help.apple.com/configurator/mac/2.5/#/apdf01626ea7


Website infected with unwanted "redirections", apparently via javascript code

You seem to be asking:

Is it possible to reverse engineer Javascript malware

Yes. And you don't need acces to the server to do that. However it is possible for the malware author to make it more difficult to do so. I won't enumerate the potential methods here - they are (mostly) well described elsewhere. Most attackers don't bother with such sophistication - particularly where its not a targeted attack with significant financial value.

Is it possible to identify where the code is being injected on the server
Yes, but you need a working knowledge of the CMS, competence at programming and access to the server (or an image of it).

The question you should be asking is what is the vulnerability in the service. You have only dealt with the symptoms of this problem - not the cause.


What risks am I taking by using an http site to play a video game that just records mouse events?

Yes, there is a risk.
HTTPS ensures not just confidentiality, but also integrity and authenticity. As such, an attacker could hijack the connection between you and the server and inject malicious JavaScript into your session.
How likely is that to happen?
Depends on how you connect to the server. If you are in your own home, then the likelihood is not very big. It's a risk still, don't get me wrong, but I don't want to cause unnecessary paranoia.
On the other hand, if you connect to a public access point (e.g. "free McDonald's Wifi"), then the chance of this happening is much much higher.
How severe is this?
Since there is no sensitive data there, the "usual" things like credential stealing or session hijacking are not applicable. However, depending on how determined the attacker is, they might redirect you to other malicious domains, exploit browser vulnerabilities, get you to download stuff or even get you to disclose credentials for other services (e.g. "Log in with your Google, Twitter or Facebook account to play").
As Eilon has pointed out in the comments, another potentially unwanted side-effect is that your ISP can tamper with the website you use. Some ISPs do this for arguably benign purposes, such as stripping whitespace off the HTML document before sending it to you, while others do more "intrusive" changes, such as compressing images, or even injecting advertisements into the website. While this is not a security-risk per se, it is unwanted behavior that can most effectively be combatted by using HTTPS.
Does that mean you should stop playing?
That depends completely on your risk appetite and whether or not the upsides outweigh the downsides for you personally.


You might think of reinventing the wheel and rolling your own protocol. Don't.

This is what SSL/TLS is for. SSL/TLS is a surprisingly lightweight protocol that works great on embedded processors. This is especially true if you control both the client and server in which case you can remove the algorithm negotiation phase and stick to a single implementation.


How can I protect my website against bitsquatting?

Is there any standard defense technique against it?

As outlined in the other answers, bit errors when querying domain names may not be a realistic threat to your web application. But assuming they are, then Subresource Integrity (SRI) helps.

With SRI you're specifying a hash of the resource you're loading in an integrity attribute, like so:

<script src="http://www.example.org/script.js"
    integrity="sha256-DEC+zvj7g7TQNHduXs2G7b0IyOcJCTTBhRRzjoGi4Y4="
    crossorigin="anonymous">
</script>

From now on, it doesn't matter whether the script is fetched from a different domain due to a bit error (or modified by a MITM) because your browser will refuse to execute the script if the hash of its content doesn't match the integrity value. So when a bit error, or anything else, made the URL resolve to the attacker-controlled dxample.org instead, the only script they could successfully inject would be one matching the hash (that is, the script you intended to load anyway).

The main use case for SRI is fetching scripts and stylesheets from potentially untrusted CDNs, but it works on any scenario where you want to ensure that the  requested resource is unmodified.

Note that SRI is limited to script and link for now, but support for other  tags may come later:

  Note: A future revision of this specification is likely to include integrity support for all possible subresources, i.e., a, audio, embed, iframe, img, link, object, script, source, track, and video elements.

(From the specification)

(Also see this bug ticket)


How can I test a domain that I don't own for unencrypted communication vulnerabilities?

A browser should do it.   If the login page is HTTP rather than HTTPS, then you already have a problem as even if the credentials are supposed to be passed over HTTPS, an active attacker could modify the login page to change the action, or perform other additional malicious actions.

To determine if even in the designed state credentials are being passed in the clear, just view the source of the login page in the browser.  If the login form action is HTTP://, or if the login page is HTTP and the action is relative or schemeless, (relative looks like action="/process-login" and schemeless looks like action="//insecuresite.com/process-login") then credentials are indeed being passed in the clear.

You can also use the "Network" tab (or equivalent) in your chosen browser's developer tools, often accessed via F12 to examine the actual request to determine if it is HTTP or HTTPS.


How can I encrypt messages sent over AWS PrivateLink?

AWS Privatelink isn't going to provide you anything special (or prevent anything you were already doing) in the way of encryption.  It is a way to directly connect VPCs without having the traffic leave Amazon's network.  This won't prevent you from using TLS since that is negotiated at the endpoints (your partner's server and your client for instance).  The network doesn't care about the packet's payload...just its header/footer info.


If your exploit works but is being stopped by the XSS auditor then you have found a real and reportable XSS vulnerability.  The XSS auditors are very finicky, all of them have workarounds, and they have already been deprecated in the latest versions of Chrome.  Therefore, if you are seeing the XSS auditor take action then you have found an XSS vulnerability that will be causing real world trouble shortly.

If you're doing penetration testing, I would try to figure out how to disable the XSS auditor in your browser.  Just pretend it isn't there, because for the purposes of bug bounties it really shouldn't matter.

Of course it is always possible that a company somewhere may reject a vulnerability report because when they try to reproduce it they are stopped by the XSS Auditor.  However rejecting a vulnerability for that reason would represent a gross misunderstanding of the purpose of the Auditor, and the simple fact that browsers have started removing it because it causes more problems than it solves.  It is certainly a point I would argue.  The Auditors are meant to be a stopgap measure, not an actual line of defense (and will be gone soon enough).  However if a company stands firm in rejecting a vulnerability report because of the Auditor stepping in, then you would obviously have to find a workaround for it.  As I mentioned, all the Auditor's have workarounds, but they are also browser dependent which can make it a bit tricky.


You need to use a USB Drive with some type of firmware control. It's the only way to ensure that the firmware present on the device is identical to the firmware on the device when the vendor created it.

You always need to be able to trust the vendor. Anyone can sell you a USB that has malware on it and you'll never know unless you examine the firmware manually.


How secure are pins on credit / bank cards?

The chip on the card functions as a tiny computer communicating with the card reader. It never reveals the PIN to the reader, but instead use a crypto protocol. This means that the card itself can enforce rate limiting to prevent brute force - i.e. locking after X failed attempts. Not sure this is done everywhere, but I know it is in some countries/by some banks.

However, if you are in physical possession of a credit card, you already have enough information to perform purchases on the internet. All you need to know to max out the card on a bitcoin shopping spree is written on the card. So brute forcing the PIN is not nececarry to perform fraud.


How do I revoke my OpenPGP keys if I do not have access to my private key?

First you import your public key into your keyring, if not already there, then the revokation certificate.

gpg --import my_key.asc
gpg --import my_revocation.txt

Your key is then revoked locally. You just need to push this to the keyservers.

gpg --keyserver pool.sks-keyservers.net --send-keys [YOUR_KEY_ID]


SSH key strength factor besides key length (say ed25519 vs rsa-4096)

Right, welcome to a crypto-nerd battle. Let's try and break this down.

Key length: ed25519 is from a branch of cryptography called "elliptic curve cryptography (ECC)". RSA is based on fairly simple mathematics (multiplication of integers), while ECC is from a much more complicated branch of maths called "group theory". In short: ECC keys can be much shorter and give you the same security level because the mathematical problem they are based on is much more complex. This is far deeper than formatting differences. That's a bit like saying that index cards at the library vs google is a formatting difference.

Security: people tend to like ECC over RSA because the keys are smaller and the computations are faster for the same security level. Below is a table showing the security level comparison of RSA (labeled as Integer Factorization, or IF) vs ECC [source]. You can see that ECC keys really do get the same job done with a smaller key.

So you want to compare RSA-4096 (not in the above table) against ed25519 which has ~ 140 bits of security and is comparable to ~ 3000 bit RSA according to its inventor. Remember that bits is a log scale: 129 bits is twice as secure as 128 bits; 140 bits is 212 = ~4000x as secure as 128, so RSA-4096 might win, but really, anything above 128 bits of security is overkill unless you happen to be a military organisation or a bank.

For putting thumbtacks into your wall, should you use a sledgehammer or a wrecking ball? The correct answer is: whatever.


Is it a good idea to hash a string and use it as a passphrase?

If this means you're effectively using the same passphase everywhere, then: this is a very bad idea.
If you're generating a new password each time anyway (as you should), why not use an actual random string, like in your example?

——

Also, in real world usage, a sha512 hash will be too long for many sites (that is: you can't set a password that long)


Is the unallocated space on my drive also encrypted (full disk encryption)?

The sda3_crypt partition is 118.5G, so does that effectively mean that my entire drive is encrypted, including unallocated space (excluding the boot partition)?

Assuming the drive was randomized before or during the initial encryption, yes. The entirety of your third partition is encrypted. If you started using encryption and just formatted your disk, there may be leftover traces from the previous, unencrypted install. However files that are deleted in the encrypted partition, deallocating their blocks, will remain encrypted.

This is not necessarily the case for solid state drives that support (and use) TRIM, however. TRIM support allows the OS to send a signal to the drive to zero unallocated sectors, because the SSD firmware can make better optimization decisions when it knows what blocks are free and what blocks are not (something it cannot know without the OS telling it, due to the encryption). In that case, unallocated spaces is erased and zeroed. This can allow someone to know which blocks are unallocated on an encrypted drive, by seeing which ones are zeroed. They will not be able to know what the blocks previously contained, both because it was zeroed, and because it was encrypted. There is a great blog post on the issues with SSDs that support TRIM and encryption.

  In terms of the boot partition, am I correct in that it is possible to keep it on a USB stick? What happens when you try to boot the OS without the USB drive, then?

Yes, you can keep the boot partition on any device that the BIOS supports booting from. If you try to boot without the USB drive, the behavior depends on your BIOS settings. It may attempt to boot from other plugged in media, or may say that no bootable medium was found and to press F12 to reboot or something of that sort. The effect would be the same as if you took out all drives.

  Lastly, does the output of lsblk indicate that my swap partition is encrypted?

Yes it does. You are using LVM on top of sda3_crypt, which is a method of, among other things, creating virtual partitions. The output shows that your encrypted device mapping is split into two virtual partitions (called volume groups in LVM terminology): user--vg-root and user--vg-swap_1. This means LVM was set up on the encrypted partition, so all volume groups it creates will also be encrypted.

  My question is directed at guest, who answered this post. You say "Assuming the drive was randomized before or during the initial encryption, yes. The entirety of your third partition is encrypted."

  I assume you mean that the drive was wiped with zeros before the encryption was performed. But my question is, is it okay to wipe an SSD with zeros for "safer" encryption? Won't that reduce the SSD's lifespan?

I mean the drive was wiped with random data before it was used with encryption. Encrypted zeros look random, so if you randomize a device and then encrypt it, no one without the key can tell which sectors have all zeros. If you zero it before encrypting, then you may have gotten rid of previous unencrypted data, but you are revealing exactly what sectors are in use. This is often a necessary evil with SSDs, due to TRIM being important for performance and lifespan.

A single "cell" in an SSD can handle between 2,000 and 10,000 erase cycles. I believe some even get around 100,000. This means you could overwrite the device that many times before severe risks of failure occur. Not to mention, they have some extra, hidden storage to prevent wear, called overprovisioning space.

You do not have to write zeros to the entire SSD. You can zero it by issuing a manual TRIM command, which tells the low-level firmware to zero everything. This can be nearly instant, because it is a separate action from writing. On Linux, you can use the hdparm command. From the manpage:

--trim-sector-ranges
       For Solid State Drives (SSDs).  EXCEPTIONALLY DANGEROUS. DO  NOT
       USE  THIS OPTION!!  Tells the drive firmware to discard unneeded
       data sectors, destroying any data that  may  have  been  present
       within  them.   This makes those sectors available for immediate
       use by the firmware's garbage collection mechanism,  to  improve
       scheduling  for  wear-leveling  of the flash media.  This option
       expects one or more sector range  pairs  immediately  after  the
       option:  an  LBA  starting  address, a colon, and a sector count
       (max 65535), with no intervening spaces.  EXCEPTIONALLY  DANGER‐
       OUS. DO NOT USE THIS OPTION!!

       E.g.  hdparm --trim-sector-ranges 1000:4 7894:16 /dev/sdz

Don't be scared about the apocalyptical warnings that are so common to that one program's documentation. All it is trying to address is the risk of losing data with this flag. You would want to set the starting address to 0, and the sector count to the total size of your drive. This will quickly erase everything without shortening the drive's lifespan as much as if you write directly to it.


User authentication with smart cards or RFID on Mac (OS X) for accessing an encrypted database

I am not sure if your idea about the database encryption will work the best. But just to give you an idea about your need to use a 2nd factor for the encryption.

Devices or Apps like the Google Authenticator use a one time password algorithm. This is based on a symmetric key. Such an algorithm and device can not be used for encryption.

You want to use asymmetric keys (>= RSA2048) to do the following.
Create a key pair of a private and a public key on the smartcard.
The private key does not leave the smartcard. The public key does. As it is public. The private key will be unique in hardware, as it does not leave the hardware.

Encrypt your database with a symmetric AES key.

Now you can encrypt the symmetric AES key with the public key.
Each time the user wants to access the database you can decrypt the encrypted AES key in the smartcard (with the private key) and the AES encryption key can be used to decrypt the database.
Of course you need to take care that the symmetric AES encryption key is not leaked.

But now you can add new users with their own asymmetric key pairs. For each user you can encrypt the AES encryption key with the user's public key. Thus only this user can decrypt the AES encryption key with his private key. And you can manage, which user will be able to decrypt the database.

...if you want to do this all you have a whole long way to go! Have fun ;-)


Is this Windows local code execution bug also a security vulnerability?

Interesting bug you found... Apparently the directory parameter passed to PowerShell isn't properly escaped.

Is this a security vulnerability?

IMHO it is one, but not very dangerous per se. If somebody was to open PowerShell in your crafted folder, there are simpler methods to achieve code execution (e.g. as Windows by default includes the current directory in the PATH). One danger of your bug is that the malicious code hides in the folder name instead of any script file, so it is less likely to be caught by an antivirus solution.

If so, how would it be best classified? (injection, local/remote code execution etc.)

Lack of proper input handling

Is it covered by the Microsoft Bug Bounty program?

Based on the response from the Microsoft Security Response Center you posted, apparently not.

How should one report it given the reactions?

Report it as a "regular" bug with the Windows feedback app.


Mitigation of Spectre and Meltdown affecting host OS from guest OS (Virtualbox)

Most threats assume the presence of an internet connection. It is usually quite challenging to exfiltrate data without the internet.

Spectre and Meltdown vulnerabilities allow attackers to see data that is normally restricted. This may include cryptography keys, authentication tokens, or other highly sensitive data.

If your compromised VM has network connectivity, an attacker could steal any of that information from the underlying OS.

This is particularly dangerous in an enterprise environment, where hypervisor credentials could be stolen and used to compromise all of the guest VMs.


What simple security considerations can I / should I make for a read-only API?

Essentially you just need to run through the standard OWASP Top 10 and focus on getting the access control stuff right.

As far as authentication goes, basic auth should be avoided for a number of reasons. It's ugly, insecure, and isn't universally supported. The standard model is to provide users with a randomly generated API key that is separate from their normal login credentials. This allows for reasonable authentication without the risk of having credentials stolen. Regardless, I still recommend HTTPS across the entire API, and it looks like you're already doing this.


SQL injection can bypass login but not drop table

Answering your question
mysql_query() doesn't support multiple queries as documented:

  mysql_query() sends a unique query (multiple queries are not supported) to the currently active database on the server that's associated with the specified link_identifier.

Which means that DROP TABLE temp; -- is never executed.
It is although possible if you use mysqli::multi_query or using PDO.

Best practice

Warning ?
You see that big red warning box ? The mysql extension is in process of deprecation and will throw warnings as of PHP 5.5.0. There are even plans to drop it completely in PHP 5.6 or PHP 6.0source. Note that mysql_ isn't broken as Ángel González stated:

  The extension is not broken. The problem is the bad usage. It can be used safely, and good developers have been doing so for ages, by creating php wrappers. In magic quotes, the work has been the opposite. The developers had been detecting the feature in php and disabling it.

The new standard
The new standard is MySQLi or PDO. I won't compare the two extensions here but there are really a bunch of good features especially from PHP 5.3+ which will save you time and efforts. Note that by using MySQLi/PDO won't protect you per se from SQL injections. The best option would be to use prepared statements. The data is sent separately from the query thus making it impossible to inject values. This is well explained by Anthony Ferrara in this video.

Be careful
But wait "impossible" ? That sounds just too great :)
Say for example we have two groups: group1 & group2. There is a certain php file deleteUser.php getting an id from $_GET.The prepared statement looks like this: DELETE FROM users WHERE id = ?. When the query is made with $_GET['id'] the user with ID = $_GET['id'] will get deleted. Hey, but that means that users from group1 could delete users from group2 by using that ID which isn't intended. So we may edit the query in something like DELETE FROM users WHERE id = ? AND group = ? and sending the user's group name he's in along with the query.
Short: prepared statements won't protect you from logic flaws.

Multi query ?
You don't need mutli queries. If you want to do two things then do it separately, it will give you more control over your queries and make your code more readable.

On another note:
If you're dynamically making and droping tables you're most likely doing it wrong. You should design your database in such a way that this isn't needed. Of course there may be exceptions but they are mostly busted since you may then look for a NoSQL solution (other db engine).

TL;DR

Stop using mysql_ functions and step over to MySQLi or PDO
Use prepared statements, note that it will not protect you from attacks if you don't secure the logic behind it
Don't use multi queries
Make a good DB design
If you want to train your hacking skills, you may check Vulnerable OS's?