TL;DR: If your users are using 587 to submit email for relay, you need to secure it (by requiring STARTTLS before AUTH) or disable it in favor of an alternative like 465 (SMTPS).  If none of your users is using 587, of course, you can disable it without concern, as all normal mail flows through port 25.

There are three commonly used ports for SMTP email - 25, 465, and 587.

25 is the standard SMTP port which is used by mail transfer agents everywhere.  If that goes away, you will stop getting email from the rest of the world.

465 ("SMTPS" or "SSMTP", where the extra "S" stands for "Security") and 587 ("submission") are alternate ports which speak SMTP, designed for use by a more limited pool of your own trusted users.  To quote RFC 4409:

This separation of function offers a number of benefits, including
the ability to apply specific security or policy requirements.

So, historically, these ports were use for things like allowing Mail User Agents to submit mail for relay, where the main SMTP port does not provide relay services. (In fact, 465 and 587 were introduced as a way of restoring functionality once "open relay" was closed off on port 25, which was itself a security measure.) Some other form of control (network ACLs or SMTP AUTH) are usually used with 465/587 to ensure only legitimate submissions are accepted for relay.

465 (SMTPS) is, like HTTPS, wrapped in SSL/TLS at the network layer.  587 does not require encryption per the RFC, but in common practice, nowadays many configurations will require STARTTLS (spinning up SSL/TLS during the SMTP transaction) before SMTP AUTH is even advertised.  That specifically addresses the concern that your PCI scan is raising.

If your 587 (submission) port is like that, you may apply for an exception to the PCI scan.  You can prove this by telnetting to port 587 and entering the command "EHLO hostname".  If the response you get, like this one, includes STARTTLS but not AUTH, then you are not vulnerable to what the PCI scan thought you were:

EHLO hostname
250-submission.server Hello hostname [192.168.3.4], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE 16777216
250-DSN
250-STARTTLS
250-DELIVERBY
250 HELP

If it does offer AUTH while unencrypted, you will need to either require STARTTLS before AUTH or disable 587 and use something like 465 over SSL/TLS instead.

If you don't have Mail User Agents which belong to your domain submitting mail over the network for relay, you don't need 587 or 465 in any case.


Yes, it can be tracked.

There is a high possibility of getting traced from a work system. but it is not just that easy to determine. It is based on the company policies that includes privacy and security. Employees might not be made aware of it though. There are certain protocols followed in every company regarding the security.

So it is almost legal to track every operations in your (Actually their) system.

But that doesn't mean that they can get all your passwords when using banking sites or others unless they have installed some key logger or screen recorder software. But only few of them are really hard to find where it resides in our system. Others can be found out with some effort.

So if you are wise, do not do personal stuffs in their system that will spoil your privacy or reputation. After all it is not yours anyway.


No, PHAR archives provide no security features in themselves. But you can sign updates using GPG like literally every other project does.

Some package management systems (rpm, deb, etc) allow for signature verification built-in. You can use one of those and get security for free, or you can implement it yourself.


Are there any Security Concerns to using Python F Strings with User Input

Python's f-strings are actually safer. Use them!

String formatting may be dangerous when a format string depends on untrusted data. So, when using  str.format() or %-formatting, it's important to use static format strings, or to sanitize untrusted parts before applying the formatter function. In contrast, f-strings aren't actually plain strings, but more like syntactic sugar for concatenating strings and expressions. As such, an f-string's format is predetermined and doesn't allow dynamic (potentially untrusted) parts in the first place.
Old-style formatting with str.format()
>>> data_str = 'bob'
>>> format_str = 'hello {name}!'
>>> format_str.format(name=data_str)
'hello bob!'

Here, your Python interpreter doesn't know the difference between a data string and a format string. It just calls a function, str.format(), which runs a replacement algorithm on the format string value at the moment of execution. So, expectedly, the format is just a plain string with curly braces in it:
>>> import dis
>>> dis.dis("'hello {name}!'")
  1           0 LOAD_CONST               0 ('hello {name}!')
              2 RETURN_VALUE

New-style formatting with f-strings
>>> data_str = 'bob'
>>> f'hello {data_str}!'
'hello bob!'

Here, f'hello {data_str}!' may look like a string constant, but it's not. The interpreter doesn't parse the part between {...} as part of the string that may be expanded later, but as a separate expression:
>>> dis.dis("f'hello {name}!'")
  1           0 LOAD_CONST               0 ('hello ')
              2 LOAD_NAME                0 (name)
              4 FORMAT_VALUE             0
              6 LOAD_CONST               1 ('!')
              8 BUILD_STRING             3
             10 RETURN_VALUE

So, think of "hi {sys.argv[1]}" as (approximately) syntactical sugar for "hi " + sys.argv[1]. At run time, the interpreter doesn't even really know or care that you used an f-string. It just sees instructions to build a string from a the constant "hi " and the formatted value of sys.argv[1].
Vulnerable example
Here is a sample web app which uses str.format() in a vulnerable way:
from http.server import HTTPServer, BaseHTTPRequestHandler

secret = 'abc123'

class Handler(BaseHTTPRequestHandler):
    name = 'funtimes'
    msg = 'welcome to {site.name}'
    def do_GET(self):
        res = ('<title>' + self.path + '</title>\n' + self.msg).format(site=self)
        self.send_response(200)
        self.send_header('content-type', 'text/html')
        self.end_headers()
        self.wfile.write(res.encode())

HTTPServer(('localhost', 8888), Handler).serve_forever()

$ python3 example.py

$ curl 'http://localhost:8888/test'
<title>/test</title>
welcome to funtimes

Attack
When the res string is built, it usesself.path as part of the format string. Since self.path is user-controlled, we can use it to alter the format string and e.g. exfiltrate the global variable secret:
$ curl -g 'http://localhost:8888/XXX{site.do_GET.__globals__[secret]}'
<title>/XXXabc123</title>
welcome to funtimes


Network intrusion security warning in router logs

This can be just something like a system inside your network doing auto-update. You already have the clue.

PROTO=TCP SPT=1940 DPT=49152

Searching source port will give you the agent which is jetVision client.

http://www.adminsub.net/tcp-udp-port-finder/1940

If still you really feel that it is some form of intrusion or its not the jetVision client then try to isolate this source agent to identify where its from your home network by doing the following.

Isolate your router, disconnect all devices to your router and see if this intrusion log is still reflecting. If there is then your router is the culprit, check manuals for any references to this source port.
If the intrusion log is no longer reflecting after you disconnect all devices to your router, then connect one device at a time and check for the intrusion log again.
At the end congrats yourself, you just did a forensic investigation.


Where can I find sample DMARC failure reports?

I'm attaching a few articles where the format of the reports are shown.

For example this image shows the image of Aggregate reports:

Articles:
 - https://mxtoolbox.com/dmarc/details/what-do-dmarc-reports-look-like
 - https://www.validity.com/blog/how-to-read-your-first-dmarc-reports-part-1/
 - https://www.validity.com/blog/how-to-read-your-first-dmarc-reports-part-2/


You should test your code in a real world scenario with a web application scanner like skipfish.    You could also try manually exploiting Damn Vulnerable Web App.

Tamperdata can be used to build and modify requests.  Or just plain old html.


HKDF is a key derivation function: it turns a symmetric key (a bunch of bytes) into another symmetric key, which can be longer (that's the point of the exercise).

Doing multiple inner iterations, to make the function slow, is a defence mechanism which makes sense when the input key is of inherently low entropy -- e.g. when it is a password (that's an unavoidable biological fact: as a storage medium for random-looking data, human brains suck). Deriving a key from a password is a task which is more complex than simply deriving a key from another key. HKDF does not pretend to handle the "password" bit. For that you need PBKDF2, which is password-based (that's the "PB" part) and also uses HMAC, this time with a configurable (and potentially huge) number of iterations.

HKDF is a building block for some cryptographic protocols, not something to use directly.


Entropy, expressed in bits, is a logarithmic scale, so it adds up. If A offers 10 bits of entropy (meaning: an attacker would have to try about 29 values on average to guess it) and B offers 11 bits of entropy (210 guesses), then AB has entropy 21 bits (10 + 11). Similarly for "random stuff" as X. This holds as long as all the A and B and X elements are selected independently of each other (this is important).

Of course, user's reluctance to use the password also adds up, proportionally to the password length. The user has to remember it and type it, so he prefers short passwords, all other things being equal.


Does client Authentication needs the server to have intermediate certificate?

To validate the certificate of the client the server must be able to build the trust chain. That means that either the server needs to know all intermediate certificates already or the client has to include these together with its own certificate. This is no different from checking the server certificate at the client.


Can Snort inline/blocking mode block traffic from one host to another on internal LAN?

It depends GREATLY on the configuration of your network. To simplify this, I'll assume you're running on a flat network.

To have Snort inspect all LAN>LAN traffic inline, you would need to ensure that there are no L2 devices interconnected below the Snort device,which I'm not sure is practical.

In a normal network configuration, all inter-LAN traffic would take place at layer 2, and would never reach the Snort box, as it would never leave the layer 2 switching infrastructure.

I don't know that there is a practical way to have Snort act as an IPS on entirely LAN-based traffic unless it's in-line at layer 3 between two different LAN networks.

Probably the best solution if it is a flat network you would like to monitor would be to mirror a port on an L2 switch and send all of the traffic to Snort there, acting as an IDS. Note that it must act as an IDS in this scenario because while it can SEE the traffic because it is being mirrored to it, it cannot act on this because it is not responsible for forwarding the traffic as it would be in an L3 inline configuration.


Does HTTPS encryption on a site prevent the NSA from knowing you visited its domain / the URL?

Does the GET request for this cross-site request pass on the URL for the encrypted page I am visiting to the unencrypted ysite.com's server

No. ysite.com will not know the URL for the page you are visiting. xsite.com will not show up on any requests you make to ysite.com.

  if I block such a cross-site request using a browser add-on like RequestPolicy, I will prevent the NSA from knowing that my IP address visited https://xsite.com/page.html (or even the domain xsite.com entirely)?

Everyone will know that you have visited xsite.com since HTTPS does not encrypt the hostname. This is because you need the hostname to set up the connection. However, it will not be possible to tell if you visited page.html or page2.html since the path will be encrypted.

However, if NSA knows that http://ysite.com/image.jpg is embedded only on page.html and you have recently made a DNS query and connected to xsite.com, they can guess that you have probably visited https://xsite.com/page.html.

Edit: The approximate length of the URL path is visible to all eavesdroppers. Thus, if xsite.com has only a few pages, it might also be possible for an attacker to guess which page you are visiting.

Additional resource on HTTP traffic analysis: Are URLs viewed during HTTPS transactions to one or more websites from a single IP distinguishable?


Does it make sense to have something similar to IPSec at the data link layer?

There are good reasons to add security to the lower layers and it has been done in practice (see WLAN protocols). Providing data confidentiality and authentication services at the data link layer is a simple solution. It is attractive because the wireless link is typically the most vulnerable part of the connection and one has to deal with only network technology. Moreover, when a lower layer is secured, all upper layers are also secured. So it protects all protocol information from the higher layers. It also doesn't suffer from the interoperability problems that protection at the network or transport layer bring with them.

It does have the (rather big) disadvantage that the information is not protected in the intermediate network nodes. This makes it impossible to realize end-to-end protection.

For sensitive applications, protection at the data link layer can be combined with protection at a higher layer.


Preventing boot from USB on Dell Inspiron 5559

I recommend you to contact Dell support. It is possible that a firmware update is able to solve your issues (at least, by changing the algorithm if not removing the bypass altogether).

A second option would be to replace the original firmware (BIOS) with a different one (coreboot, OpenBIOS...) which doesn't offer such bypass (you should be well aware of the risks if that firmware doesn't work on your computer, though).


I just realized (with more research) that aircrack-ng needs a management frame containing the ESSID (it can be beacon/probe response/reassociation request) and two data frames containing the EAPOL messages.
so i just captured a beacon frame from the AP and then used the wireshark's mergecap tool to merge the 2 .cap files (beacon.cap and eapol.cap) and that worked perfectly!


You are using a javascript routine (document.cookie) in HTML without breaking out into the javascript context.  It's helpful in these cases, to look at the source of the page that's generated - that often makes it easier to understand.

In order to leverage your cookie stealer, you would need an XSS on the victim's site.  In the most common case, that allows you to break out of the HTML tag, and start writing javascript (i.e. ">

As a side note, you can always just check your access logs for requests coming into your cookie stealer - no need for a separate php program to record these.


Single and double Encoding of parameters to bypass security filters

It depends on particular implementation. The simple ones check one level only. The  normal ones decode the request as many times as it was encoded: Check, decode, check, decode, etc., until the result of decoding is equal to the input of decoding.


Yes they can be represented in plain text. both your assumptions can be true.

Most certificates usually follow the x509 standard based on RFC5280

A x509 Certificate can be represented in a PEM format - which is plaintext. It can include an entire certificate chain including public key, private key, and root certificates.

there are also other formats that exist like PKCS12 which may require a password as they can hold the private key.

If you are a newcomer, then the Link suggested by @BadSkillz is the best place to start.


What is the best Practice / Industry Standard for storing documents with social security numbers, date of birth, financial records, etc?

This is very broad and as such, it's a little hard to exactly cover everything that applies to each. However, I'll try to cover the ones that I know apply.

Credit card information is generally governed by PCI DSS (Payment Card Industry Data Security Standard) as the credit card industry likes to regulate themselves and not be regulated by governmental regulations.
Financial Information is usually covered by SOX (Sarbanes Oxley) which is a governmental regulation.
SSN & DOB is PII (Personally Identifiable Information) which can be handled by PCI DSS, but is probably covered by another set of policies entirely.

SSAE16 is more of a security framework that provides a standard of security, which is very useful and can be used to protect this information and comply with the various regulations.


Mixed Content error in IE11 - HTTPS resource on HTTP page

In the case of an HTTPS iFrame from a different domain, two distinct information sources are accessed. The purpose of Microsoft's error message in the developer console may just be to remind unexperienced developers that the information source in the HTTPS iFrame might need better protection.

In the case of an HTTPS script no additional information source is accessed other than the main HTTP page, because scripts from third party domains are commonly used mostly for loading libraries. In such case there is no secure information source that needs better protection.

On a side note, I believe that loading HTTPS iFrames, scripts and resources from HTTP pages is still adviseable because it prevents attacks at backbone and Internet provider level.


Your little experiment and the inferences are actually inconclusive.

Verify if you are using IPV4 or IPV6. [ You can do this by checking your public IP in any of the websites for that. ]
If you are using IPV6, it is likely that the ports listed open are exposed to public network.
If you are using IPV4, your devices are likely to be behind NAT. In that case your public IP is the IP address of your router. The router will have open ports only if the administrative interfaces of router are configured so, or if port forwarding is enabled for specific services. So it is very likely that the exposure is not because of your phone, but because of a misconfigured router.

To verify this manually, do the following.

Search in shodan.io with your public IP
Note down the results. Do an nmap scan on your own network from another network.
Verify if port forwarding is on.

PS: If you can give information specific to the model of router you have, I might be able to provide some help regarding the configuration.


Is image meta-data copied when taking an iPhone Screenshot?

No, it will not.

Information such as time, date, author, etc. is stored as EXIF metadata. This data is kept separately from the image itself, and as such will not be retained if you take a screenshot of that image.

You may be thinking of steganography, which is the process of hiding information in another piece of information. The Wikipedia article offers an excellent introduction to the topic, along with an example of what it can do.

This can be used to hide information in the image itself, but EXIF metadata isn't stored this way.


Identify emails registered in an online web application

This is a good change that you did to hardening privacy leakage in your app. From a point of an attacker, there is one other way to identify the email is registered in your site or not. But this is depending on how you have implemented your authentication process, performance of your web servers etc..

Normally we store the user password as a hash in the DB along with the salt value(Hope you did the same?). So, if the login process identifies an email is existing in your DB, then it is calculates the hash of given password and try to compare hashes. Calculating the hash of given password takes bit of time. So what attacker can do is, compare the response times from your login page and identify emails which takes longer time to respond.

As a remedy to this kind of an attack. You have to manually control your response time in your login page to a constant.


Does SMIME differ from TLS, PGP, DMARC signature, or a Portal Encrypted email message in terms of legal non-repudiation?

If you are afraid of "snooping" then why would you use signatures ? A "snooper" is a passive eavesdropper, who wants to see the data but certainly not to make you aware that your emails are inspected. They won't alter emails, or send fake emails, which are the kind of things that signatures can help against.

If you want to defeat such sniffing, then you need to use end-to-end encryption. This will indirectly involved signatures, but on the certificates, not on the emails themselves. To prevent a man in the middle attack, you want to make sure that when you encrypt an email, you are using the true public key of the intended recipient -- that is where certificates and, crucially, signatures from CA, enter the mix. But these signatures predate the actual email; none of them makes any guarantee as to the email contents.

Now if you want to defeat active attackers, then indeed signatures become relevant. You will want to sign your emails so that the recipient may reliably detect whether your emails were altered in transit (this works, of course, only if the recipient expects your emails to be signed, and will suspect foul play if he receives an unsigned email allegedly sent by you).

At the legal level (though it depends a lot on the jurisdiction), all the "non-repudiation" thing is about shifting the burden of proof. An email, like any piece of data, can be used as proof during litigation; whether it is acceptable in that role depends on the context, and arguments which are then produced by both claimants. Basically, one party (let's call it A) will claim that the email really originates from the other party (B) and thus its contents "bind" B in some way (e.g. contractually); the other party (B) claims that the email is fake and was forged (by A or some other miscreant). Arguments include analysis of headers and log files on all involved machines (B's desktop system, email servers...) and possibly other elements (such as eye witnesses who saw B type the email, or other things like that).

What the legal framework that some countries are trying to build are ways to define the default interpretation: namely, is the email reputed genuine by default (and then B has to find good arguments showing the forgery), or is the email reputed unreliable by default (in which case A must do all the proof work) ? Digital signatures, in a cryptographic sense, can be a part of a system (both technical and legal) which, in some countries, will put the burden of proof on the forgery claimant ("B" in my example).

(As an illustration, in Hollywood, a handshake is considered a binding "signature" for a contract, without involving any computer or even any piece of paper with some ink on it. Eye witnesses are used if a dispute arises.)

Thus, signing emails incurs a "legal risk" only if you intend to renege on the email contents, and that legal risk is increased (with regards to an unsigned email) only within a context where you feel confident that you could successfully deny having sent an unsigned email. In practice, emails leave traces in many places when they hop from server to server, so reneging on some email is already "risky", regardless of whether the email was signed or not.

SSL/TLS, in the context of emails, is used mostly opportunistically. You may have it when sending the email to your outgoing SMTP server; recipient may use it when reading his mailbox (e.g. IMAPS, or some SSL-powered Webmail); SMTP servers may try to use SSL when talking to another SMTP server. Though SSL includes signatures, these are computed over technical "challenges" related to the SSL mechanisms, and do not cover the exchanged data. In that sense, SSL-level signatures cannot "technically" be used as proof about the data contents (this is authentication, not signature).

However, legal matters do not reduce to mere technical elements. The context rules. Some may argue, for instance, that generalized use of SSL for server-to-server connections makes it more difficult for outsiders to actually intercept the emails and alter them. So one may argue (specifically, may argue in court) that SSL tends to make forgeries harder. In any case, all this SSL happens for data transit only; intervening servers still see the email "as is" and maintain their log files, which appear to be sufficient to convince judges in practice.

The best defence strategy of a claimant who wants to renege on his emails might be to assert that his own computer is under control of some malware, which sent the email without his consent or even awareness. One may note that this defence "works" regardless of whether the email is signed or not, since the malware can use your private key to sign such forged emails.

To sum up: only an analysis of the complete situation can tell you whether your "legal risk" is impacted, in which direction and to what extent, by your signing your outgoing emails with S/MIME. However, one may surmise that, usually, S/MIME signatures don't change things much for the sender. For the recipient, signatures may lower the risk substantially in the following sense: if the recipient expects millions of incoming emails (e.g. the emails are actually registration contracts for some service), then he will realistically expect hundreds or even thousands of attempts at reneging emails. Generalized use of digital signatures may be expected to streamline the litigation process, thus lowering the involved costs.

If your enemy is the NSA, then all these legal talks are completely irrelevant: legal proofs are good only when you can show them to a judge. When you wake up, tied on an interrogation chair in the basement of some secret facility in South Dakota, there is no judge to talk to...


OpenVAS - how does it know if an SQL vulnerability is open?

OpenVAS (now part of GVM) is a Vulnerability Scanner. Scanners of this class are checking applications / systems for "known" vulnerabilities like SQL injections within a CMS / Blog software or similar where e.g. a vendor advisory or a security researcher report exists. The check is then done in one of the following ways:

based on an exposed version
by an active check (e.g. SQL injection) to known vulnerable URL / endpoint. In this case quite often application specific response checks (e.g. checking for a specific text) is done.

Checking for unknown vulnerabilities like the SQL injection mentioned by the OP requires a Web-Application Scanner like Acunetix or Burp which often requires user-interaction a Vulnerability Scanner doesn't offer.

Nevertheless from being a Vulnerability Scanner OpenVAS / GVM has some very basic Web-Application Scanner capabilities which needs to be separately enabled within the default scan configuration. For this clone the "Full and Fast" scan config, search for the following VT:

Name: Global variable settings
Family: Settings
OID: 1.3.6.1.4.1.25623.1.0.12288

and configure the "Enable generic web application scanning" to "yes". While i doubt that the SQL injection of the OP will be found it worth a try.

To sum-up:

Vulnerability scanners are checking mainly for "known" (e.g. publicly documented) vulnerabilities via a version check or an active check to the known affected URL.
Unknown vulnerabilities requires a Web-Application Scanner.

To specially answer the question on how OpenVAS/GVM is checking for this specific vulnerability:

The VT doing this SQL injection request is 2009/GForge_multiple_sql_injection.nasl (can be found in your local installation) and once the application is answering with a response containing the following text a vulnerability is reported:

forum_id=$1$

Disclaimer: VT Dev @ Greenbone


How to listen to all ports (UDP and TCP) or make them all appear open (linux)

A simple and passive solution would be to log all incoming connection attempts to syslog, run your scan, and when you get home look at the logs. With iptables, you can log connections like this:

iptables -A INPUT -p tcp -m state --state new -j LOG --log-prefix "New connection: "

That way, you don't need to run a service that answers all connetion attempts.


Change your default admin password to something secure
Use WPA2 for wifi access with a very long password which should be periodically
   changed.
Set up MAC address filtering to allow only devices you trust.
Disable remote admin tools
Disable secondary SSIDs you are not using if they are supported
Turn off SSID broadcast
Turn off Wifi Protected Setup
Some sources recommend changing the SSID to something to mislead
   attackers, so if your router is Belkin, change your SSID to 'Cisco'
Enable the firewall if available
Keep your firmware up to date
Review logs periodically for suspicious activity

You can use servcies such as Shields Up to run basic testing of your network
https://www.grc.com/shieldsup


GnuPG + Yubikey 4: How to manually check that all keys are where they belong (on the Yubikey only)?

If you put the subkeys on the YubiKey, you still should keep the primary private key around somewhere -- it is the only entity that can be used to revoke the keys, create new subkeys, modify user IDs, certify other's keys, ...

  How do I check that all 3 subkeys and no master-key is on the Yubikey 4?
  How do I check that no sensitive key-material is on the Computer?

To verify what's on the card, run gpg --card-status, which should print several lines of information including three called "Signature key", "Encryption key" and "Authentication key". These should print your subkey's fingerprints, not your primary key's fingerprint. Don't bother for the "General key info", which is a reference to your primary (public) key, and not stored on the card.

To verify the keys are not stored on your computer, run gpg --list-secret-keys. Secret keys stored on your computer are marked with sec or ssb for subkeys, secret keys not available (for example, when your exported only secret subkeys running gpg --export-secret-subkeys are marked with sec#, secret key stubs only available on an OpenPGP smartcard (like the YubiKey also implements) with ssb>. Key stubs are simple references that a key is not available or is stored on a smartcard, and do not include the actual private key.

  How can I use the same Yubikey on my 2nd machine (Linux) - do I have to import any certificates to GnuPG/GPA there?

To use the keys on another computer, you need to export the "secret subkey stubs" to this machine, which you can do running gpg --export-secret-subkeys [key-id] (listing the primary key's ID). After importing on your new machine, you should not see a sec or ssb, but only sec# for the primary private key stub and ssb> for the subkey key stubs.

  I first tried to create the keys with a live-cd as suggested from various sources, but back in Windows Kleopatra didn't let me use my Yubikey. So I used Windows to create the keys and it worked - now I'm worried that secret-keys are on the harddrive somewhere. lol If someone can point me to the right direction how to get it working with key-creation on live-cd and using on normal system, would be awesome.

This reads like you didn't run --export-secret-subkeys like described above, so the GnuPG setup on the "regular" setup didn't know about the private keys at all. The public keys are not stored on the card, anyway.

When using a live CD, be sure to create some persistent copy of the primary master key stored in a safe place (you'll still need it!) and additionally a revocation certificate easily accessible for you in case you need to revoke the whole key, and lost access to the primary private key.


Can I create an SSL certificate on windows signed with the machine's certificate?

No, you don't have the private key for that root to sign certificates.

However, as Julian suggested you could generate your own self signed certificate and then add it to your trusted store.

Assuming you're running Windows, this is how you add it to the trusted store:
http://blogs.technet.com/b/sbs/archive/2007/04/10/installing-a-self-signed-certificate-as-a-trusted-root-ca-in-windows-vista.aspx

This is how you can generate a self signed cert via IIS7:
http://technet.microsoft.com/en-us/library/cc753127(v=ws.10).aspx

This is how you can generate a self signed cert via OpenSSL:
https://stackoverflow.com/questions/10175812/how-to-build-a-self-signed-certificate-with-openssl

Have you checked with your IT department to inquire about an internal Certificate Authority? If there is one, you can issue an SSL cert signed by your company's CA.


How can you prevent employees of your company from creating valid ssl certs?

It's not just any email address at that domain. I have a valid gmail address, but that's not enough to convince Verisign that I own gmail.com.

Instead, at the very least, you need to control one of a specific set of addresses, including the email address listed in the whois record for the domain, and also often some of the following:

admin@example.com
administrator@example.com
hostmaster@example.com
root@example.com
webmaster@example.com
postmaster@example.com

In addition to that, depending on the domain in question and often triggered an by automatic flagging system, they may require additional manual validation by an employee of the CA. If you were to try to get a certificate for microsoft.com, for example, it probably wouldn't work even if you did control one of the email addresses listed above.


How to report "cryptographic bad practice" to vendor?

I would start looking for a company email address that is provided so third parties can report vulnerabilities, e.g. security@, secure@, psirt@.  Maybe Google the vendor's site and look for "responsible disclosure" or "vulnerabilities".  If you find that address email them there.  While it's not necessarily a vulnerability, if the vendor has something like that in place they're the best people to work with as they're likely understand the issue and have the proper contacts to get it fixed.

Failing that, you can always try front line Support.  They probably won't understand the issue, but if they escalate to back line (or development, depending on how big the support org is) then hopefully it'll be recognized as an issue and fixed at some point.


Looking for Information security / risk management table top or card games

I haven't played anything like this myself, but I found this on Google: http://www.itgovernance.co.uk/products/3831 - Is this similar to what you are looking for?


As Ammar mentioned, in this specific situation I don't think that XSS is possible.  However if visiting test.php?p=test rendered the following HTML:

Some other stuff

A malicious user could potentially use a URL like this:

test.php?p=test" onmouseover="alert('xss')

rendering:

Some other stuff

to execute an XSS attack.  Doesn't work in your situation, but should illustrate the fact that stripping brackets is not sufficient to prevent XSS.


Connecting to VPN send login credentials encrypted or unencrypted?

Technically, the answer to your question depends on the VPN software used and possibly on how it's configured - there are many different network authentication protocols out there, and many VPN programs support more than one - but in practice you can reasonably assume that your credentials are not sent in clear text. No VPN client worth the bytes used to store it would send plain-text credentials by default, and most aren't even configurable to do so.

Of course, not all non-plain-text authentication methods are equivalently secure. MS-CHAPv2, for example, is pretty easy to break. It'd still take more than just looking at the network traffic in a packet capture to extract the credentials, though.


Earning CPE for SANS/GIAC certification renewal through online courses

I sent this question to SANS support, and got the following reply:

  Passing a ISO-17024 certification qualifies for CPE credits. Once submitted a member of our team will review your supporting documentation and award the proper amount of CPEs.

In other words, neither the training length nor even the training itself are relevant here. What is relevant is passing a certification exam by IAPP, which grants me 36 CPEs.

I eventually went through the training, registered for a certification exam, and when I passed it, I got the possibility to claim 36 CPEs with SANS. Once claimed, I successfully used them to renew my GIAC certification for another four years.


If you don't need CSRF protection because the request is idempotent then you don't need a CSRF token.

Reading request.GET in the view, with or without a form, does not affect security.

Using function based views or class based views does not affect security.

I believe simplicity is good, so I would recommend to always use function based views because they are simpler to reason about.

Using a form to validate query params is a matter of convenience. If you need to write a validator, if it's more organized to write it as a custom FormField or as def clean of a form (logic concerning multiple fields at once) then you should use a form. If you validate the same kind of data in multiple places, it makes sense to use a form for the Do not Repeat Yourself principle.


Difference between public key and private key validity period

But then why would the public key lose validity after some time?

One reason is that the way certificates are signed might become outdated.

For example because either the hashing algorithm or the signature algorithm/key length is too old.

Take the hashing algorithm for example. At the moment SHA-1 signed certificates are on the way out. Because that hash no longer seems secure.

And before SHA-1 was used there was MD5 in certificates. And that has been phased out as well. (And people had to ask their CA to please resign their public keys with some other, stronger parameters. MD5 -> SHA1, SHA1->SHA2, etc.)


How to close or block remote access backdoors?

Short answer: possible, but not doable.
Long answer: not possible.
It's relatively easy to create a backdoor. Anyone with a minimal programming knowledge can search around and create another backdoor. Most of them will be easily detected, but some can evade detection. Add that to the almost unlimited ways to communicate with the command and control servers, and you see how is impossible to detect and block every backdoor.
I once saw a report on the Turla family of malware that used comments on a Britney Spears post to send the C&C server address to the agents. As usually Instagram is not blocked, and Britney looks like a famous person, nobody would suspect it was used as a malware communications channel. And sending data back is easy too: they can use Domain Fronting, DNS-over-TLS, DNS-over-HTTPS requests, even plain DNS queries.
That's why is impossible to a common user to detect backdoors by himself: too many possible infection vectors (Word macros, browser exploits, infected PDF files, phishing), too many C&C communication paths, and too many exfiltration paths too.
Backdoors targeting normal users (any user, not a specific individual) can be detected and stopped by anti-malware, antivirus and firewalls. Most of them are not sophisticated enough to bypass basic defenses. Keeping your defenses up to date is enough to protect you from most of them.
But backdoors aimed at large corporations, governments, high profile law firms and specific individuals are a different kind. They use undocumented features, abuse normal OS components to disguise their actions, mix with expected traffic, and are tested against the target defenses. Their owners research the environment first, and create a specific backdoor to bypass the target defenses. They are not the normal, off-the-shelf malware, and employ a lot of effort to remain hidden for as long as possible.
So it's useless to try? No. Employing strong defenses makes you not be a sitting duck and the lowest hanging fruit, so the attackers will look elsewhere. But if the attackers have plenty of time, skills, and strong financial/political motivation (and external funding), they can break any defense.


FileVault 2 FDE and BoxCryptor are safe to use together or they have conficts?

As Boxcryptor operates on the file level, it is totally fine to run it on top of an already encrypted file system (e.g. FDE, FileVault, BitLocker, True|VeraCrypt, etc.). A Boxcryptor encrypted file (with .bc extension) is just a regular file which can reside on any file system.


Do any web browsers create cached copies of local HTML files?

Local files are not treated any differently from Internet sourced files in terms of caching, temp files, etc.

If you use a system file change tool and open a local *.html file you will see that all sorts of files across the system are modified or at least opened. I tried a test file on a local drive in both IE and FireFox and it looks like a few files were modified. I would recommend you do further testing, but I see not reason why local files wouldn't be cached, etc. Just because they are local does not mean the browser does not need to store data or information from the page temporarily, in history, etc.

You can try a few different file/folder change monitoring tools:

Track Folder Changes

I would generally not think HTML is the best thing to use for secure documents. The documents are not going to be secured at rest and there could be malicious plugins or other software within the browser. I would recommend using PDF with strong encryption/passwords. A lot of virtual printers (e.g. will print to PDF) include the ability to add AES level security, one such program is PDFCreator. In that way the file is secure at rest as well. I do not believe there is any caching in Adobe Acrobat or Adobe Reader, but I will have to double check on that, and could not comment on other PDF readers.


Which extensions to use for a S/MIME certificate?

There are details spelled out in RFC 3850. In practice:

It is highly recommended to include your email address in your certificate, in a Subject Alt Name extension (or possibly as an extra attribute in the subjectDN but this is deprecated). If the certificate does not contain the email address, your correspondents will have to find another way to associate the certificate with your email address, and most software will have trouble with that (this is meant to be supported, but it will make things difficult for other people).
If your certificate usage is restricted with a Key Usage extension, then digitalSignature and/or nonRepudiation must be allowed explicitly in that extension.
If the certificate contains an Extended Key Usage extension, then it must contain either the id-kp-emailProtection OID (1.3.6.1.5.5.7.3.4) or the special all-purpose anyExtendedKeyUsage OID (2.5.29.37.0).
If the certificate is a signature-only certificate (it contains a DSA or (EC)DSA key, or is restricted through Key Usage), then email encryption will be hard. There is (was ?) a mechanism in which your software generates a Diffie-Hellman key pair, and attaches the public key to the signed emails you send, allowing recipients to encrypt their responses. This is, at best, ill-supported in the wild, and it adds some extra issues (such as storage of the extra DH private key). Therefore you'd better use a certificate which is encryption-able (RSA key, and not restricted with a Key Usage extension).
Theoretically you could have two certificates, one for email encryption and one for email signatures; this would be a good idea. But support might be found a bit wanting in that area. Some testing is required.

There were some Netscape-specific extensions in older times, which were needed for proper usage by Netscape Communicator, but who runs that nowadays ?


SSD Wipe to remove known & unknown malware

TLDR: Toss 'em. It's the only option.

You're asking for a way to ensure that the drives haven't been tampered with by a proven motivated and well-funded state actor. But I can see no way to be sure that the firmware is secure.

The best option I can think of is to read the firmware from a potentially-compromised drive and a known-untampered drive of the same model, then do a comparison. The problem with this strategy is that you have to trust the potentially-compromised drive to accurately report what is in its firmware. But the drive is potentially compromised, so you can't trust it. How can you be sure that it doesn't returns different data for diagnostic access v. actual use.

I know that this sounds far-fetched, but you are ascribing great skill and resources to the attackers. Toss the drives and eat the cost. Sorry :(


Directly signing a file with gpg or instead its checksum file?

Imagine you have a 250GB file (a disk image, a Blu-Ray movie, something very large), and you want to sign it. It would be a massive process to calculate the digital signature of it. And to check the signature would be massive too. You would not want that.

Instead, you use a good, fast hash (SHA-family or MD5, for example), calculate the hash of the file, and use the slow, CPU-intensive digital signature only on the very small hash.

If anyone changes the file, the hash will change and invalidate the signature. if someone alters the hash, the verification will fail. Either way you are protected.


Is abc/efg a valid directory? Please check. If it doesn't exists, it might not be able to resolve the path, and that's why those methods are returning false. Just make this small check. May be you could figure out the bug in the directory path somewhere. So I hope 'abc' and 'efg' are valid directories.


What level of vulnerability has this WPA2 system?

I think you need to realise that you have 3 secrets here, from your perspective:

the password
the algorithm, and
the hash length

You assume that the password can remain intact, the algorithm can be exposed as an acceptable risk, but you are afraid that the exposure of the last one might defeat your security and the other two secrets. This is a rookie security design error.

Your system needs to be designed so that it is still secure even if the attacker knows how the system runs. This is known as Kerckhoff's Principle. In your case, even if the attacker knows the algorithm and the hash length (which, by the way, is basically part of your algorithm, but you speak of them separately).

From a security design perspective, your security comes down to just the password. You just made it supremely difficult for the legitimate users to use the system without adding any additional security.

If your intent is simply to protect the password because it does not change often, then you need to shift your perspective and your risk analysis. Your proposed system obfuscates the password by using a salt+hash design pattern. The intent of the salt+hash approach is to increase the time it takes an attacker to crack the hash (even if they know the hash method and the salt, see Kerckhoff's). So, the primary goal here is time. Using this design pattern, the only secret is the password, and the result is a longer time to crack the password. You defeat this approach by shortening the resulting hash, because that dramatically reduces the time it takes to crack (like, from centuries to seconds).

So, to answer your question: it's the length itself that is your vulnerability, and attackers would not have to figure out your algorithm, they can just bruteforce 8 characters blind. They will be able to figure out how often it changes, and simply design a method to crack the hash in that time.

There are so many other approaches to this problem that you should investigate.


The source of the "1032:1" figure is given on the zlib site where it is told that:

  The limit comes from the fact that one length/distance pair can represent at most 258 output bytes. A length requires at least one bit and a distance requires at least one bit, so two bits in can give 258 bytes out, or eight bits in give 1032 bytes out. A dynamic block has no length restriction, so you could get arbitrarily close to the limit of 1032:1.

This is a quote from Mark Adler, one of the two designers of zlib. Having myself implemented a library for Deflate, I can confirm that, given how the algorithm works, this asymptotic limit is indeed true (you cannot go beyond, but you can get as close as you wish). Deflate works by encoding "copies": each element is either a new byte, or a copy of a past sequence; copies can overlap (i.e. you can copy a sequence of length 30 at distance 4, yielding 15 times the past sequence of 4 bytes); Huffman codes are applied on the sequence of elements. To get a minimal length "copy" you need it to overlap a lot, and each copy is worth at most 258 bytes. So the data which is to be compressed will have to be a long string of identical bytes.

As @Steffen says, compressing with gzip a long sequence of zeros will yield a more than 1000:1 compression ratio. It does not have to be zeros; any sequence consisting of the same byte value over and over will do the trick; but a Linux machine has a /dev/zero, not a /dev/fortytwo.

"Compression bombs" were already active quite a long time ago; I saw it employed to kill Netscape back in 1996 (at that time, Netscape handled background pictures, but Mosaic did not; a very small GIF file could encode a huge background, which Netscape allocated as a single big pixmap in the X11 server).


gpg is trying to sign with an old signing sub-key I no longer have

I had similar issues, only specific to Enigmail after upgrading to GnuPG2.1 on Debian via dist-upgrade (Sid user).

I could not send emails that I intended to sign. Enigmail reported:

  Error - encryption command failed `

Debugging GnuPG resulted in several errors:

ERR 67109139 Unknown IPC command <GPG Agent>
ERR 67108949 No pinentry <GPG Agent>
command 'PKSIGN' failed: No secret key

After a bit of reading (answer from Jens Erat as well), turns out indeed that enigmail/gpg-agent were selecting the signing subkey with the newest creation date.

To clarify, I originally created GnuPG keys following a Debian guide for developers, which recommended creating sub-keys for each different machine. However I did away with that practice almost immediately for various reasons, and deleted the signing subkey in question.

Both subkeys; the older that I kept, and the newer I thought I had deleted, were displaying when I'd run gpg --list-keys xxxxx in terminal.

Another hint for me was the 'No secret key bit', indeed there was no matching secret subkey for the public signing subkey that was being selected, perhaps I only deleted that one -- not sure.

So I deleted the public signing subkey that Enigmail kept trying to use:

gpg --edit-key xxxxx
$ key 2
$ delkey

Magically I could send signed emails again.

Not sure if the GnuPG upgrade reloaded the old key keys, if I somehow didn't delete the key right previously or had somehow restored it, or if Enigmail is simply working differently with GnuPG 2.1 (or even just differently in latest Enigmail update for Icedove).


Sashank, That is a good question.

Writing rules is a fun research work. Often it takes lot of research and analysis, and sometimes for some threats its very easy to write a signature.

This is quick very high level overview of writing signatures. The things you should know before hand to perform analysis and to start writing rules -

Very good understanding of Protocols according to their RFCs - This includes all protocols (IP, ICMP, DHCP, TCP, UDP, SMTP, FTP, POP3, ssh, telnet etc.) in OSI layers (datalink, network, transport, session etc). The RFC is the guideline of how a protocol is designed, how it should behave. This is a very important reference in writing rules. RFC define the structure of the protocols, their headers, state, flags/attributes. On the network, any observed deviation from these RFCs standards is the key in writing rules.
Detailed understanding of the vulnerability - What do you want to write a signature for? Do you understand how the vulnerability works? Do you know what are you looking for in the network traffic? Where shall you concentrate on in the application/service? Trying to answer these questions will give you a path to understand the vulnerability. Example - if you are writing a rule for remote buffer overflow on port 80/http on IIS, then you must understand the web server architecture, how data get handled internally in the web server, how does the web server handle the requests and generates responses. This will clarify the vulnerability. If you understand this then it lead you to what exactly you should be looking for. This is applicable for any remote or local service/process/software you want to a vulnerability rule for.
Lot of lab work - Run the exploits over and over in different scenarios, get lot of packet captures or memory dumps. Analyse the timeline, analyse the packet headers and compare that with RFC standards, analyse the payloads. If you run an exploit 10 times, then the packet captures will give you the timeline, size of the payload/data, bit sequence (data) in the payload and most importantly it will clarify the conditions under which the exploitation is most likely to be successful. Putting all this together will bring good accuracy for the signature, then you know the exact bit patter to look for and when to look for, and where to look for.


No, such a breach should not happen as any respectable VPN service will generate separate keys for each client.

Your data is encrypted, so even if someone that compromised the network does look at what you’re sending, they only see encrypted information and not raw data.


Is it appropriate to tie application-level encryption keys to AD profile

Looking at some of the risks/issues/questions:

AD was never designed for online use with issues like what we saw in 2016.
Do the service account meet the Principle of least privilege?
Integrity : What happens when the profile gets corrupted? Do you have backups? Are they encrypted?
Confidentiality : How confidential is the data and how much will a breach cost you?
Availability : How long of an outage can you afford?
Detecting a breach : Are you monitoring for unusual activity?
After a breach : Can you revoke the keys? How do you issue new keys?
Other options designed for distributed systems such as vault or octopus deploy
Knowns

It depends on the industry you are in that will effect your risk. It's rarely a single persons decision and should be communicated to the business.

tl dr Personally I would advise against AD for a distributed system as a glorified key store as MS has Key Store Management Services.


There are a few ways to do this.

You can come down to the following statement:

For authentication you can only use something the user knows, has or is.

As you're in a file-encryption scenario, this should rule out most points concerning "what a user is", because they involve biometrical data, which needs to have tolerances.

A password or passphrase. This is the classical way of authenticating users in this scenario, is widely deployed, well accepted and can provide high levels of security. Please note that PINs also fall into this category. From the above sentence this is "something the user knows".
A (symmetric) keyfile, this is something the user has and is usually implemented as an arbitrary file the user can select or generate and which is strongly required for the key-derivation. This is also widely implemented (most better encryption tools use this). Please note that the keyfile may rest on local memory or on a secured device (i.e. a smartcard or HSM).
An (asymmetric) key(file), this is something the user has as well. Please note the difference to the above keyfile, as this usually isn't input to the key-derivation function directly but used for asymmetric decryption on the user's CPU, smartcard or HSM.
Data stored in the OS. Usually the OS has some way to store data protected and this mechanisms can be used for authentication. Some OS offer secure key storage and some offer encryption of data using the user's credentials. (category: has (PC/OS) / know (credentials))
Cryptographic hardware (smartcards, HSMs, TPMs,...) can be used to securely seal and store keys and integrated cryptographic processors can be used to perform symmetric key transformations (using the stored key), needed for key-derivation. (category: has (hw) / know(PIN))
Custom hardware is probably the most secure way. This hardware can function as the above crypto hardware concerning usage, but authentication can be made highly different than with a standard PIN / password. For example if the hardware is highly trusted (tamper-evident / tamper-resistant) it may be possible to securely implement biometric authentication for the device unlock and hence indirectly for the key derivation (as the crypto processor only operates after valid authentication and it's not software access control but hardware access control). Biometric authentication may include but doesn't have to be restricted to voice recognition, fingerprint sensoring, face recognition, DNA testing, brain-activity recognition, iris scanning and hand scanning.


Is password hashed before saving to CMOS?

Depends on the BIOS.

  Which hash algorithm is used?

Depends on the BIOS.

  How much storage is dedicated for passwords?

Depends on the BIOS.

  What is about passwords of SSD with AES? Does BIOS save it inside drive (just pass it to device for further processing)?

There are a lot of different technologies for SSD encryption with AES, some of which may involve the BIOS. If it is using Real Encryption (TM), as use of the term "AES" implies, then the password should not be "saved inside the drive". Sometimes it's just a lock rather than real encryption, though, in which case the password, or a hash of it, is saved somewhere. It depends on the BIOS and SSD.


Unknown Website Linking to my Local Files?

You are running a web server I assume and although you might be using it locally, you must have either an open port exposing access to it on the public side or your website is a public facing one to being with. In which case, hotlinking to your file is not a virus behavior, its like anyone hotlinking to your resources on the web. There are permissions you can set on your webserver that will prohibit external hotlinking to your files. This will ensure the files are accessible only if they have been delivered through your own webserver/website. To help you fix that, we need to know a few things:

What web server software are you using? (IIS, Apache, etc.)
Are you using LOCALHOST/127.0.0.1 like an intranet only or is it public facing accessible? (meaning you either port forwarded 80/88/8080 to your private IP range or if you are using public facing IP and just have the web port open, so typing http://YOUR_IP brings up your site)

If you are ONLY using it as an intranet and you don't want it to be accessible on the web, then just simply close the web port on your system and it will prevent outside access, simplest solution.

If you want to be able to access it from outside and therefore must have the port open, then you need to use access permissions (or ACL of some kind) to prevent access outside your own website. For this we need to know what web software you are running so specific instructions can be given.

If you are using Apache, then .htaccess is your best friend and you should really read this and get familiar with this beast. Its a well done resource. You can also look through Apache documentation too. Not as friendly, more technical.

On Windows for IIS, its a bit more complicated but definitely doable, especially they have a GUI for it but you are always welcome to go old school CLI if you like. This lays out a pretty good guide and iis.net is a pretty resource to check as well.

Anything more specific and you have to let us know your configuration, I gave you these links so that if you choose not to and know enough to do it on your own, you have some guides.


Are there valid reasons for compressed files (zip, gzip, etc.) to spoof file size?

The uncompressed size of each file is stored in the file metadata for no reason other than allowing an application to know things like the compression ratio. It is not meant to be authoritative in any way. There are no legitimate uses which I can think of for having the reported uncompressed file size differ from the actual uncompressed file size.

What you are describing is a zip bomb, also called a decompression bomb. They do not work by lying about the uncompressed file size, but rather by compressing many archives inside of each other. A single file with a gigabyte of zeros will compress quite small. Duplicating an archive many times and then compressing them together will not result in a significant growth in the final archive due to the high redundancy. A 20 byte zip bomb that extracts to a terabyte can be duplicated a hundred times, then archived together and compressed, resulting in a 25 byte zip bomb. This process can be repeated many times until the total size makes it impractical to extract. This was a common technique in the past used by malware, as malware scanners would attempt to blindly peek into archives. When the archive had a zip bomb, they would either run out of memory and crash, hang, or give up and skip it and not find the malicious payload hidden somewhere inside. Now days, malware scanners will often flag suspected zip bombs to allow the end-user to take appropriate action.

An easy way to mitigate these attacks is to impose a limit on how many levels deep a decompressor will go when extracting a compressed archive. Attempting to verify that the reported and actual uncompressed size match is useless as zip bombs are not dishonest about their size. The confusion stems from the fact that only the size of that one archive is recorded. There is no way for a zip file to know that the 100 files inside it are also zip bombs.


SQL Server does not prevent XSS. XSS would still be possible via issues in the web application code. Proper use of prepared statements with SQL Server can prevent SQLi, but to prevent XSS, you must validate data received from untrusted sources and encode data before returning it in an HTTP response.


How to configure a port as filtered on server

nmap can detect three states for a TCP port:

Open means "SYN" packet got a "SYN/ACK" response ("I hear you, can you hear me?")
Closed means "SYN" packet got a "RST" response ("Firewall REJECT")
Filtered means "SYN" packet got no response at all ("Firewall DROP")

The only way to make an open port seem filtered is to use the firewall to drop packets from the sources you want filtered, and allow packets from the sources you want to allow.  This will make the open port seem filtered to unauthorized sources.  But in order to do that, you need to determine which sources are allowed to connect and configure the firewall rules accordingly.

In other words, you can't have a port be like a "hidden SSID" in wireless, where it's secretly open but you have to know it's there.


Why is 'Bearer' required before the token in 'Authorization' header in a HTTP request?

The
Authorization: <type> <credentials> pattern was introduced by the W3C in HTTP 1.0, and has been reused in many places since. Many web servers support multiple methods of authorization. In those cases sending just the token isn't sufficient.

Sites that use the

Authorization : Bearer cn389ncoiwuencr

format are most likely implementing OAuth 2.0 bearer tokens.The OAuth 2.0 Authorization Framework sets a number of other requirements to keep authorization secure, for instance requiring the use of HTTPS/TLS.

If you're integrating with a service that is using OAuth 2.0 it is a good idea to get familiar with the framework so that the flow you're using is implemented correctly, and avoiding unnecessary vulnerabilities. There are a number of good tutorials available online.


Does antivirus software detect screen grabbing functionality in a running program?

Screengrabs are not malicious in and of themselves. So, there is no need for anti-virus or anti-malware to be suspicious of that behaviour. Every OS has some sort of screenshot program. But unusual screengrabbing can increase the "score" for suspicion.

What anti-virus or anti-malware will do is look at the behaviour in context and comparison to all the other behaviour it has, or if it is a known bad binary, it will detect it.

I used to run a commercial, non-malicious PC spying package that took a screenshot every time someone hit the enter key or clicked the mouse. (This was a very specific use case for a specific threat on a single machine, and the machine had a poster informing users of this). I needed to whitelist the package's processes in the anti-malware software we used because it was the combination of behaviours (screengrab hooked in the background to the keyboard and mouse actions in all processes and not just the screengrab program) that was suspicious.


What happens if incorrect SIM card PUK entered 10 times?

On a modern phone, none of your personal data will (usually) be stored on the SIM. It's true that technically, a SIM card has the ability to store a limited address book, a small collection of text messages, and some call history, and in the old (pre-smartphone) days, this was super handy when moving to a new device.

Today, I would be shocked (and really annoyed) to discover that a phone was storing any personal information on the SIM, because that would allow someone with physical access to my device to be able to (literally) pull that information out of the phone. I should be able to throw a SIM away when it's no longer in use, without fear of any data leakage.

What a SIM does store is a secret key that uniquely identifies your phone to the cellular network, and that your phone company uses to decide if you should be allowed to connect to their towers, what your phone number is, what services you are allowed to use, and how you should be billed. You can think of the SIM as your phone-company-issued ID card: it identifies you, gives you permission to use the phone network, makes your connection through the air from your phone to the nearest tower private, and nothing else.

With that knowledge, your question can be answered fairly easily.

  But when incorrect PUK is entered 10 times, it is no longer possible to unlock it. What happens?

When the PUK is entered incorrectly 10 times, the SIM assumes that someone who shouldn't be holding it is holding it. It disables itself completely. It can never be used to connect to the cellular network again.

So, all you need to do is contact your phone company, tell them what happened, and get a new SIM. They will give you a new SIM, with a new secret key, and mark the old one as dead. Most reputable phone companies won't charge you anything for this, though some will take any excuse to charge you a fee. Since the dead SIM can never be used again, even if someone malicious and skilled were to get their hands on it, it's not useful for any purpose at all, and can't be used to access your information, your account, your phone number, or make calls at your expense.

  Is everything on the SIM card erased or only PUK?

Exactly how the SIM responds to the PUK being entered incorrectly 10 times depends a little on the manufacturer, but basically, you can probably assume that everything on the SIM card is erased. Remember, none of your personal information will be on the SIM unless you intentionally put it there (for example, to move your information to a new phone without using an Apple, Google, or Samsung account, or any other cloud service). If your phone is working the way it was designed, your personal information is safe no matter what happens to your SIM.

If you did put your personal information on the SIM, or you aren't sure, then my advice is simply to cut the card with scissors or melt the card with a lighter before throwing it away. (But don't throw it away before speaking to the phone company; they may want the serial number on the card, or may ask for the card itself to be returned, before issuing you a new one.)

  Is SIM card blocked if user enters incorrect PIN 3 times, then incorrect PUK 10 times when trying to enable PIN SIM card protection.

Actually, the phone company doesn't know if you need to enter the PUK, and doesn't know if you entered it incorrectly 10 times. So, they don't block it, simply because they don't need to; your front door lock doesn't need to know if you lost your front door key, it simply won't let you come inside without it.

If your SIM has PUK-locked and disabled itself, simply tell the phone company, verify that you're really you (either in person by showing ID, or over the phone by proving you are who you say you are as usual), and they'll issue a new SIM for you with the same phone number, account, billing, everything.

  Is it possible to unlock the SIM card?

No. If it were possible for you to unlock it, then it would be possible for someone else to unlock it, and the PUK system is designed to prevent exactly that. But, as said above, there's no need to unlock the SIM, you can just get it replaced by the phone company.

I hope this helps!


The iOS app ID includes a team specific prefix that can not be changed nor set by the developer; it is automatically used when signing a build (which you even have to do when using ad hoc distribution or development builds)

So unless Facebook ignores that part when checking the App ID to be equal, you cannot create an app that passes as another app.

There you go:

  App ID
  A string that identifies one or more apps from a single team. An App ID consists of a bundle ID search string preceded by the Team ID, a 10-character string generated by Apple to uniquely identify a team.


Trying to learn bug-bounties, how do I use the practice sites like hackthissite and hacmebank?

The answer to this generally depends on the tool. There are some practice targets that can be deployed and attacked locally and there are some that are hosted in the cloud. By and large, these tools aren’t exactly giving a sterile environment (especially the cloud-based ones). This is actually a good thing, as targets in the wild aren’t sterile either. A lot of systems and applications can be assumed to be attacked by multiple agents at once all time anyway, so practicing with that sort of environment is all part of the training.


Why does Google require a phone number for using their 2FA service?

It all burns down to solving just one problem: spam protection.
Ensuring that the people who sign up for services are real people.

Before that, thanks for bring this up, and yes, it is  indeed annoying.

From what I have perceived, services that deal with "real people" often want some sort of "real world" token that a person would have on them. Like a biometric scan, something unique or nearly unique to a person.

And since we don't expect every person to have special hardware like biometric scanners, our phone numbers happen to be the next most unique (I cringe) and convenient way of having almost that.

Facebook, Twitter, Gmail, every people-to-people service wants (and are often criticised) for requiring it. Although in the case of messaging service it makes some sense to have that, because "that is how WhatsApp routes chat messages between you and your contacts" But no one seems to be arriving at a better solution for it. And from what all I have read, not a lot of investments are being done to fix this either. Yes, it does require fixing IMO.

Edit: Case in point is Google, and in their case, they also use it as a recovery option in case you lose access to your credentials. Which is not very secure, so they pad it up with additional checks like security question, or recovery Email addresses.


Determining a reasonable session timeout limit

I think it's very related to the task being performed in the session.

How to determine it: verify what the session / program / software would be used to. Measure how long it takes to a regular user perform such activity. The more measures you have, the better. Calculate the average time and standard deviation. Make the timeout limit be average + 2 std dev, and I think that almost every user will be able to use the session before a timeout occurs.


IPTables DDoS protection working with per client IP address counter AND UDP

You can put a cap on number of request from an IP by using mod_security, as explained here:

https://secure.jwall.org/blog/2009/07/19/1248004300834.html

Having said that, this solution is far from perfect as, in case of application level DDoS attack it can lead to:

A.) Blockage of legal requests that come from the same IP range (i.e. trojan botnet)

B.) Success of a large multi-node attack in which each IP supplies only a small amount of request (under set threshold) and thus will not be blocked.

Also, this will do nothing at all against network DDoS (i.e. SYN Flood) that uses spoofed IPs as, in this case, you don't even need to establish a full 2-way connection for the DDoS to work.

More about IP spoofing and IP DDoS Protection

To stop this you`ll need to have some kind of front-gate reverse proxy in place, to prevent access until full 2-connection is established (ACK received).


Tracing MAC addresses found in router logs

MAC addresses are only locally unique and it could be a spoofed address (if it an attack) as well. Therefore if you are referring to an attack, the best thing is to look at MAC addresses later.
If you have a chance to analyze ARP packets from your router you will be able to find the related IP addresses.
Or
If you suspect an inside attacker, you can check your ARP/RARPtable.
Or block these MAC addresses using MAC filtering. Users will complain when they are not able to use the internet. Before that, make sure all critical users are not using these MAC addresses.
In addition to that, try to identify the product vendor using a MAC lookup tool to look for the devices.
But It is really hard to find your network devices if they are connecting through multiple ways.


How to avoid to lose data encrypted because it was encrypted by no longer supported software?

When dealing with encrypted data, you must be careful to pay attention to the systems and software that will be necessary to decrypt it.  If at any point it becomes foreseeable that the systems or software necessary to decrypt your data will no longer be available, you then must consider alternative methods of encrypting/decrypting the data.

When an alternative encryption/decryption method is available, and deemed necessary, use your current methods to decrypt the data and then immediately re-encrypt it with the new method.

Of course, it should go without saying that you should always keep good backups of your data - in fact, the backups might be the best option for testing your new encryption/decryption method before performing it on your live data.


implementing an authentication mechanism for understanding the basics of client authetication

For example, hashing the password and the challenge together and sending it back to the server. The server would do the same with the user's stored password and check if both values are the same.

In this scenario, the server would need to have the user's complete password, stored in plaintext or encrypted form. This introduces a security risk - if your database becomes compromised then the passwords are given to the attacker. It's better to store the passwords as hashes, 'salted' with a random value to prevent rainbow table attacks. This way the server cannot accidentally leak the passwords because it doesn't have them to start with.

  Also, OpenID seems to me equally vulnerable to man in the middle attacks, but it must be something I don't understand or I'm missing.

OpenID is only effective if it's over HTTPs. Otherwise it is indeed vulnerable to a man in the middle attack.

  However, how can this authenticate a user A to a server B if, let's say user C can intercept A's response to the server and send it to the server as if it was C? Then the server would authorize C to the resource A was supposed to gain access to.

Again, HTTPs deals with this. In the initial handshake between Client A and Server B, messages are encrypted using public/private key encryption. This public/private key is stored in an X509 certificate kept on Server B, and Client A can validate the public key by ensuring it's signed by a recognized certification authority.

Server C might attempt a man in the middle attack by substituting its own public/private key pair, but Client A will recognize that Server C's certificate is not signed appropriately.


What tools exist to help me monitor OCSP certificate validation failures?

Most of my experience lately has been with the Tumbleweed Desktop Validator (now Axway?)- it'll plug into browsers as well as work standalone with a bunch of configuration options.  It checks OCSP and pops up a warning when something bad has happened.  I think you can configure it to deny access as well.

It's not the only product, just the one I've worked with most recently and most heavily.  Many of the OCSP server makers have a client side offering, since it's just the other half of the equation.  I'm afraid I don't know of any free ones.


The inherent contradiction of security questions

For a security question ot be good, it must:

Have one definitive unambigious answer that the user would never forget...
...but is secret and hard to guess for everybody else.

The problem is that the higher you score on #1, the lower you score on #2. So you have to walk a tight rope here. If you lean to far towards #1, users will forget the answer and brick their accounts. If you lean to far towards #2, anyone can guess the answer and the question becomes essentially useless.

There probably is no sweet spot here. So should we just ditch the whole concept?

Well, it depends.

When and how to use them

Security questions can be used in many ways.

Let's start with a very bad way to use them - as the only protection for account recovery and password reset. The answer to the question basically becomes a second password that is both easier to crack and guess than the first. That's just spectacularly bad. If you don't believe me, ask Sarah Palin.

That usage pattern is probably what have given security quesitons their bad name. But is there actually some other legitimate use case for them? Maybe. How about this:

As a poor mans 2FA for login or sensitive actions.
As a check before sending password reset emails.

In both cases, a determined attacker could find the right answers. But not all attackers are determined. A simple security question could make large scale automated attacks after big data breaches impractical. If I have a million passwords from site A, I can't just test them on site B if B also requires a security question. Or if I breach an email provider, I can't send a million password reset links from all sorts of sites, because I don't know the answer to the security questions.

The backside here is the contradiciton discussed above - the less obvious the answer to the security question is, the more likely users are to brick their account by mistake. There are better solutions here, like real 2FA or account recovery codes. But implementing 2FA can be hard, and so is getting your users to actually print and store those pesky recovery codes. So sometimes, for pragmatic reasons, a security question might a good compromise.

That is the best case I can make for them. I'm not sure if it's a good enough case to actually ever use them.

TL;DR

It's hard to construct good security questions, because the harder the answer is to guess, the harder it is to remember.
Still, security questions could be a useful complement to other efforts to protect against dumb automated attacks if you don't have the resources to implement better solutions, such as 2FA.


How to properly anonymize data, if hashing isn't enough?

You can use tokenization. Meaning you create a seperate database with randomly generated IDs mapping to 3 numbers and 3 letters. You then insert the token instead of the real identity.

Another option, if you don't need to map the data back, you can use, for instance, a  HMAC (hashing algorithm) with an long random generated secret.  Without the secret you can't bruteforce the original IDs, even when they even only consist of 1 single character.

Using a HMAC is actually the correct way of using a "secret salt" (a salt is actually never considered secret in cryptohraphy).


It depends on how the learning is done by the biometrics system.

If the system is distributed to you with prior knowledge of what a human face is, and if you're only teaching it the faces it should accept, it would be enough to just enrol the authorised users.

If the system is merely a computer vision learning model without any prior knowledge, you'd need to build a dataset of human faces representative of the human population, label the faces of the authorised users as authorised and the others as denied, and train the system.

I've never used the system you're asking about, so if you cannot figure out in which of those two categories it falls, I suggest you contact the customer support of the manufacturer.


Which Authentication mechanism to choose for PCI-DSS system

The only requirement that directly relates to session management is 6.5.10 which is very general:

6.5.10 Broken authentication and session management.
Secure authentication and session management prevents unauthorized
individuals from compromising legitimate account credentials, keys, or
session tokens that would otherwise enable the intruder to assume the
identity of an authorized user.

The best PCI-type resource is the new Software Security Standard.
https://www.pcisecuritystandards.org/documents/PCI-Secure-Software-Standard-v1_0.pdf
which recommends threat modelling and then selecting your authentication and session management based on this.


Generate cryptographically strong pseudorandom numbers in Javascript?

There is an experimental API for this: window.crypto.getRandomValues.

It's supported in

Chrome 11.0
Firefox 21
Internet Explore 11.0
Chrome with Opera skin 15.0

Opera 12 does not support this API, but its Math.Random is secure.

  Opera has not yet implemented window.crypto.getRandomValues(). However,
  our Math.Random() is using a cryptographically secure random generator.
  If used carefully (noting that it only returns 53 bits of entropy for
  each call) it is possible to use it to implement a javascript version of
  window.crypto.getRandomValues(). Just make sure to only do this in
  Opera, along with some good comments in the code.

http://lists.w3.org/Archives/Public/public-webcrypto/2013Jan/0063.html


In Mongo JSON objects (I will call here them this way, in fact they are a restricted subset of JS objects and correspond more to python dicts. Also note that in Mongo Wire Protocol BSON is used, which is a binary superset of JSON, though not very efficient) are used as a part of query language. In PHP there exists a type array which maps to both JSON objects and arrays. So when you are populating a PHP array with values iteratively, unless special care is taken you can never be sure if it will result into JSON array or an object. In MongoDB JSON objects are used to specify conditions.

It is also often assummed by some webmasters that it is not possible to pass arrays via request parameters in PHP.

In your example an imagionary webmaster assummed that that arrays cannot be passed via request params, so there were no sanitization, the type was not checked. An adversary has managed to pass a PHP array, which has been serialized into a JSON object.. I don't know whether "<some name>":{ $eq: <some value> } is more secure than "<some name>": <some value>, the docs says they are the same, but IDK if they are really the same.

So before processing untrusted data withncore of your system you should always verify and sanitize them.


I might be wrong of course, since I don't know the solution, but here's my analysis.

get.php can be completely ignored, as you can make up a random id cookie value.

We might not have all the necessary information. Does the server run Apache or something else? Which PHP version was used? Is there a description for the challenge (they often contain obscure hints)?

As it stands, I see only two realistic ways of approaching this that: injecting data into that $_SESSION['time'] variable, or making check.php pause after $time=time(); and before $time+20!=$_SESSION['time'].

Looking for injection vulnerabilities in PHP, I only found CVE-2006-3016 (PHP 5.1) but it contains very few details and they'd have to run a very old PHP version anyway. Last year someone also reported a session injection vulnerability, but it seems not to be applicable. This avenue does not seem very feasible.

This leaves the pausing trick. I was thinking of something like this:

Open a lot of connections and let them request eat.php with large $_POST['cookie'] values to make it take a lot of time to write all the sessions.
Request check.php, which will hang until step 1 is complete. Vary the amount of requests done in step 1 until it takes exactly 20 seconds.

This would require the server to do multithreading, since it needs to leave check.php in a sleeping state and perform a bunch of eat.php requests in the background.

The issue with this is that each eat.php needs to write to the same session, or it wouldn't block at all in check.php (since there would be no thread locking the session that check.php tries to read). But if each successive eat.php completion updates the $_SESSION['time'] value to something more recent, it is not going to have an old time value. So this does not work either. (It could perhaps work if PHP blocks on any session still being written to, then another session could be updated in eat.php and still leave check.php hanging, but this seems unlikely so I haven't explored the possibility.)

In short, we need more information and perhaps even access to a challenge environment. From my perspective, it seems impossible without another vulnerability (e.g. sending false NTP updates).

To answer your question

Yes, your proposed solution would probably work. Just one issue: how would you actually manage to make it do this? ;)


Shellshock plus sudo/su environment whitelist bypass - big problem?

Sudo blocks environment variables that might be bash function definitions (2004-11-11 env.c: strip exported bash functions from the environment), even if the variable name is whitelisted. That's why sudo isn't included in the list of common attack vectors for Shellshock.

A bash script invoked by su to a restricted account can be an attack vector. But there are other problems with a shell script invoked via su. su doesn't strip environment variables such as IFS or PATH (bash doesn't import IFS from the environment, but some other shells do) — or BASH_ENV, which is the name of a file where bash reads commands when it starts up. A shell script invoked via su to a restricted account would need an intermediate wrapper. This wrapper should take care what variables and values it lets through.


Securely Storing Access Tokens for Azure Key Vault

I am not sure whether the access_token that you have received from Azure Authentication has permanent lifetime. I am assuming it is not. Either way, you still need to have client_id and client_secret to get the access_token, and that means you should instead focus on securing the client_secret or finding the alternatives.

Instead of using client_secret to authenticate, you can use client certificate authentication as explained in this documentation: Authenticate with a Certificate instead of a Client Secret.

In the picture above, the developer does not need to know the private key value of the certificate in order for their app to be successfully authenticated to Azure Active Directory. Instead, they only need to know the location of the imported pfx in the Certificate Store.

At least on Windows, you as secret administrator can convert the private key and the certificate into pfx format which is password protected, and then deploy it into the Windows Certificate store. This way no one could know the private key unless they know the password of the pfx file.

The other approach specifics for Azure Compute, is to use Azure Managed Service Identity. Using Azure MSI, Azure will automatically assign your resources such as VM with an identity / Service Principal, and you can fire requests at a specific endpoint that are only accessible by your resource to get the access_token. But be wary that Azure MSI are still under public preview, so please review the known issues before using it.

The picture above explain how Azure Resource Manager assign a Service Principal identity to your VM.

When you enable MSI in a VM, Azure will create a service principal in your AAD.
Azure will then deploy a new MSI VM extension to your VM. This provides an endpoint at http://localhost:50432/oauth2/token to be used to get the access_token for the service principal.
You can then use the access_token to access the resources such as Key Vault which authorize the service principal access.


In general, yes this is a safe configuration.

The VirtualBox host only network appears as a network adapter on your host operating system. You should make sure the firewall rules are applied to that network. For example, on Windows you can do this from "Windows firewall with advanced security". The screenshot below shows that VirtualBox Host-Only Network, and confirms that it is firewalled.

There are still some risks. There may be vulnerabilities in VirtualBox that allow a malicious guest to compromise the host. If you have drive or clipboard sharing enabled, then these carry some risk too. But in general this configuration is fine.


How do cryptographic algorithms help hackers to bypass Antivirus software?

Executable file encryption is rather obfuscation than real encryption, since encrypted file still have to execute. So "decryptor" part has to know the decryption algorithm and/or key.

Antivirus software has:

various emulators, for x86 code, x64 code, normalized JavaScript code etc.
various decryptors/unpackers for all "crypters" and archives known to antivirus vendor (eg. ESET has 1228 decryptors/unpackers as for now)

As for your question: basically signature matching is done after unpacking, decrypting etc., when antivirus engine finds out, that there are no more known archive/encryption/obfuscation levels for current file.

However there are 2 exceptions:

There are modular viruses, eg. Flame, in which only one module has decryption key for another module, which has decryption key for another module and so on. Catching such viruses require writing dedicated code in antivirus engine.
There are ransomware viruses, that, while not being encrypted themselves, can encrypt random files on infected computer in a way that nobody but virus author has decryption key. Files encrypted by such viruses are not recoverable by antivirus software.


Why is writing zeros (or random data) over a hard drive multiple times better than just doing it once?

Summary: it was marginally better on older drives, but doesn't matter now. Multiple passes erase a tree with overkill but miss the rest of the forest. Use encryption.

The origin lies in work by Peter Gutmann, who showed that there is some memory in a disk bit: a zero that's been overwritten with a zero can be distinguished from a one that's been overwritten with a zero, with a probability higher than 1/2. However, Gutmann's work has been somewhat overhyped, and does not extend to modern disks. “The urban legend of multipass hard disk overwrite and DoD 5220-22-M” by Brian Smithson has a good overview of the topic.

The article that started it is “Secure Deletion of Data from Magnetic and Solid-State Memory” by Peter Gutmann, presented at USENIX in 1996. He measured data remanence after repeated wipes, and saw that after 31 passes, he was unable (with expensive equipment) to distinguish a multiply-overwritten one from a multiply-overwritten zero. Hence he proposed a 35-pass wipe as an overkill measure.

Note that this attack assumes an attacker with physical access to the disk and somewhat expensive equipment. It is rather unrealistic to assume that an attacker with such means will choose this method of attack rather than, say, lead pipe cryptography.

Gutmann's findings do not extend to modern disk technologies, which pack data more and more. “Overwriting Hard Drive Data: The Great Wiping Controversy” by Craig Wright, Dave Kleiman and Shyaam Sundhar is a recent article on the topic; they were unable to replicate Gutmann's recovery with recent drives. They also note that the probability of recovering successive bits does not have a strong correlation, meaning that an attacker is very unlikely to recover, say, a full secret key or even a byte. Overwriting with zeroes is slightly less destructive than overwriting with random data, but even a single pass with zeroes makes the probability of any useful recovery very low. Gutmann somewhat contests the article; however, he agrees with the conclusion that his recovery techniques are not applicable to modern disks:

  Any modern drive will most likely be a hopeless task, what with ultra-high densities and use of perpendicular recording I don't see how MFM would even get a usable image, and then the use of EPRML will mean that even if you could magically transfer some sort of image into a file, the ability to decode that to recover the original data would be quite challenging.

Gutmann later studied flash technologies, which show more remanence.

If you're worried about an attacker with physical possession of the disk and expensive equipment, the quality of the overwrite is not what you should worry about. Disks reallocate sectors: if a sector is detected as defective, then the disk will not make it accessible to software ever again, but the data that was stored there may be recovered by the attacker. This phenomenon is worse on SSD due to their wear leveling.

Some storage media have a secure erase command (ATA Secure Erase). UCSD CMRR provides a DOS utility to perform this command; under Linux you can use hdparm --security-erase. Note that this command may not have gone through extensive testing, and you will not be able to perform it if the disk died because of fried electronics, a failed motor, or crashed heads (unless you repair the damage, which would cost more than a new disk).

If you're concerned about an attacker getting hold of the disk, don't put any confidential data on it. Or if you do, encrypt it. Encryption is cheap and reliable (well, as reliable as your password choice and system integrity).


Where can I find documented details of virus so that I might be able to find out why I am infected?

Google's your best bet. Sality is/was a pretty large botnet, so there's loads of info out there:

Sality on Wikipedia
Microsoft Malware Protection Center
Symantec's knowledge base

You likely got it from a shared drive or an infected USB stick, which is its main propagation method.


Is using an free and anonymous VPN service safe?

There's no way to be 100% certain, but bear in mind that it's entirely possible for your VPN provider to see ALL of your traffic. Personally I do not sign into any personal account when using a VPN, particularly a free one.

I'm guessing that you want something to bypass country specific law? The safest way is to purchase your own VPS (which you can find for a few dollars a month) and route your traffic through that, then you are in charge of your data.


The biggest concern is obviously that malicious users will upload things that are not images to your server. Specifically they might upload executable files or scripts which they will attempt to trick your server into executing.

One way to protect against this is to make sure that the files are not executable after you move_uploaded_file in PHP. This is as simple as using chmod() to set 644 permissions.

Note that a user can still upload PHP scripts or other scripts and trick Apache into executing them depending on your configuration.

To avoid this, call getimagesize() on the files after they are uploaded and determine what file type they are. Rename the files to a unique filename and use your own extension. That way, if a user uploads evil.jpg.php, your script will save that as 12345.jpg and it won't be executable. Better yet, your script will not even touch it as it will be an invalid JPEG.

I personally always rename uploaded images to either the current timestamp from time() or a UUID. This also helps prevent against very evil filenames (like someone trying to upload a file they've named ../../../../../../../../etc/passwd)

As further protection you can use what's sometimes known as an "Image Firewall". Basically this involves saving uploaded images to a directory which is outside the Document Root and displaying them via a PHP script which calls readfile() to display them. This might be a lot of work but is the safest option.

A secondary concern is users uploading too many files or files which are too large, consuming all the disk space available or filling the hosting user's quota. This can be managed within your software, including limiting the size of individual files, the amount of data one user can upload, the total size of all uploads, etc. Make sure the website admin user has a way to manage and delete these files.

Do not rely on any of the data in $_FILES. Many sites tell you to check the mime type of the file, either from $_FILES[0]['type'] or by checking the filename's extension. Do not do this. Everything under $_FILES with the exception of tmp_name can be manipulated by a malicious user. If you know you want images only call getimagesize as it actually reads image data and will know if the file is really an image.

Do not rely on checking the HTTP Referrer for any security. Many sites advise you to check to make sure that the referrer is your own site to ensure that the file is legitimate. This can easily be faked.

For further information, here are some good articles:

http://software-security.sans.org/blog/2009/12/28/8-basic-rules-to-implement-secure-file-uploads/
http://nullcandy.com/php-image-upload-security-how-not-to-do-it/
http://www.acunetix.com/websitesecurity/upload-forms-threat/
http://josephkeeler.com/2009/04/php-upload-security-the-1x1-jpeg-hack/