Hashcat - separator unmatched running pmkid 16800 crack

How about reading changelog or help menu:

02.04.2019
==========
Due to hashcat changes:
"WPA/WPA2 cracking: In the potfile, replace password with PMK in order
to detect already cracked networks across all WPA modes"
https://github.com/hashcat/hashcat/commit/b8d609ba1604f4fed62198ae5000e205dcc87f70

hcxpcaptool: added new option -k to convert dumpfile to new hashcat PMKID format

-k <file> : output PMKID file (hashcat hashmode -m 16800 new format)
-z <file> : output PMKID file (hashcat hashmode -m 16800 old format and john)

use hcxhashcattool to convert old 2500 and old 16800 potfile to new hashcat potfile Format:
-p <file> : input old hashcat potfile
            accepted potfiles: 2500 or 16800
-P <file> : output new potfile file (PMK:ESSID:PSK)

hcxhashcattool -p oldhashcat.2500.pot -P newhashcat.potfile
hcxhashcattool -p oldhashcat.16800.pot -P newhashcat.potfile


sql injection mitigation by signed db entries?

Yes sounds reasonable. Especially to put salt and pepper in different parts of database and code.
But do not forget:
If the attacker has access to the web server, he can read out all described things using the code and, if necessary, adjust them to his needs. He can determine the algorithms used and use the found hashes to create a customized dictionary attack using a wordlist and the  algorithms on the server.
If SQLi already exists and database and code are on the same system, this can mean:

That the code is read out
Executable code can be uploaded and executed to gain access to the server

A good example of this offers
https://www.youtube.com/watch?v=oI_ZhFCS3AQ
So probably you want to double-check that the 3rd party sqli's found are not accessable from outside.


How to pass parameters with a Buffer Overflow?

When you overwrite the return address with the address of your  shell function, try to think of this as a call instruction for shell.

As shown below, when a function is called a stack frame is formed and the parameters for it are pushed onto the stack, followed by the return address(EIP) of your previous function along with your Stack Pointers(ebp, esp). with you Stack Pointer being on top of the frame.

Essentially, after you overwrite the return pointer with "\x8D\x55\x55\x56" you are going to need to add on another address, being return pointer for the new function, as well as the address of your  exec_string pointer, that being a parameter for your new function.

To understand how to exploit  this I would recommend learning more about Return Oriented Programming, this is a good source for understanding that as well as how the stack looks when a function is called.


Bitdefender showing lot of Getting Suspicious Connection Blocked from Chrome extension Toby

Nearly all free apps and extensions have a trade off of privacy for free cost. Apps may log various things like your browsing history, system information, etc. and the use them to target ads for you later or to sell to other 3rd parties for profit.


What are the recommended directory ownership & permissions for hosted websites?

Giving the information you have provided:

I would always suggest that the user for your web application is www-data:www-data and the file permissions be NO HIGHER than 755.

if you are creating split hosting then yes of course you can user different users, www-data is just a common user to use, though set up correctly you can user basic users. never use root. if you need special privileges give your user specific powers (sudoers), not let that user have all the power.

With anything below your document root, in this case this would include your www folder (unless you have web assets stored there), I would keep the file permissions to another user, I would always advise against root but it wouldn't be so bad at this level.

You need to remember anything executed as root is dangerous regardless if you think you server is safe. your server isn't safe.

My tip is to keep root out of the picture as much as possible. I hope this helps.


Authorization on OAuth2 application that is both Client and Resource Server

I believable your application have an architecture similar what I have show by below image,

Application have front end which runs in the browser and have a back-end. Authorization server is externalised (out of application's boundary). Hence your app have a back-end you can make application a confidential client. The login to application happens through OIDC flow. Browser redirect user to login page of authorization server. He/she provide credentials, server sends back an authorization code and this is passed to back-end which allows back-end to make the token request.

One option I see here is to create an authenticated session between browser and resource server. The green connection in my diagram stands for this session. This session being authenticate means that it is bound to access token. Session timeout is defined by access token expiration. This will require some logic from front end as well resource server end.

Another option is to pass access token to front end. With this, you does not require to maintain a session but front end requires to protect access token and send it with every request make to the back-end. So the green connection line now stands for bearer token trust connection (refer RFC6750 to see the standard way to transmit access token over headers)

Regarding access rights (consents), this will depend solely on context of your application. If you want OIDC to externalise user logins, user directories and authentication mechanisms, then I don't see the requirement to worry much about this. What you need an access token (and ID token).


What is a good risk assessment for different types of online file references?

Is hotlinking to external file (like described above) dangerous or can
  it be a potential risk to your website or website visitors?

If any of your users are unpatched and you are including content from an externally linked domain, it would be possible for the external domain to switch the content to a malicious image, Flash file or Word document.

  Can you face a risk yourself when people are hotlinking to self-hosted
  files, other then a availability risk?

Yes, mainly just an availability risk, although as they are making a cross domain request to your server, they could be exploiting any CSRF vulnerabilities or injection vulnerabilities and using their end-users to do it. This argument however is weak, as these vulnerabilities are vulnerabilities themselves and can be mitigated in isolation.

  When question number 2 is a risk: What are the best practices to
  protect your files from being hotlinked by others?

An option would be checking referer header, although this can have its own problems. Some users turn off referer to increase privacy, and some referer checks suffer from logic bugs (e.g. http://example.com/example.org may pass the referer check for example.org if not coded correctly). Another option would be to check the user has a valid session on your site. This would easily be bypassed by a site requesting a HTTP page cross domain to set the session. You might have to validate them via a CAPTCHA check before showing them site content. Not a very good user experience.

Another idea would be to randomise URLs. So image.jpg would only be shown if the query string ?validationCheck=123321 was appended to it. Your website would dyamically generate the code:

<img src="/image.jpg?validationCheck=123321" />

and the handler for the jpg file type would check that the validationCheck value is correct. This value could change every few minutes. They could implement a bot to check this, however it would be more work and they might as well copy and save the image to their own server (although it would be subject to copyright infringement). Also, this approach does not sit well with caching.


I think the requirement from ISMS point of view should be fulfilled if "logs are available all the time and their integrity isn't questionable". If they are adamant on logs availability on-premise, you can write a program/script (selenium code) to download and save the file regularly using below steps documented at http://www.dell.com/support/article/in/en/inbsdt1/SLN288529/en

To access Chrome logs:

Type chrome:net-internals and select Export in the drop down box.
Open second tab and reproduce the steps that generate the issue.
Go back to the tab running chrome:net-internals, type a description of the issue in the box, and click the button to save the log file. The file will be saved in the downloads folder on the Chromebook.


Can any asymmetric algorithms work with only a key-sized amount of randomness?

Assuming your dice is fair, each dice roll yields around 2.585 bits of entropy. You could use this to generate strong key-material.

Generating asymmetric keys is however a mathematical process. Both RSA and DSA key generation involve selecting primes. So you can't approach the process with a huge random number in hand and expect to be able to use it as-is.

There are opportunities to 'mix in' your high-entropy dice-material during the key generation process, namely when selecting your primes and encryption exponent in RSA, or when selecting the primes or private secret in  DSA.

You would not need to generate so much however, a 1024 bit RSA key holds around 80 bits of entropy;

  the security available with a 1024-bit key using asymmetric RSA is considered approximately equal in security to an 80-bit key in a symmetric algorithm

So you would only need 80 bits of entropy to generate a 1024 bit RSA key. That is to say, that if you consumed as much randomness as possible during every stage of key generation, you would find that you had used up around 80 bits of dice-material by the time you had finished generation.


Is using Cloudflare, and other services that proxy your site, a security hazard?

Your understanding is a little confused, but to address the central question first: Sure, but so is running your server on hardware owned by Amazon or Microsoft or Google, much less ever running apt install or pulling something from NPM or whatever. Just using an operating system you didn't write (or at least audit) yourself, on hardware you didn't personally create, introduces some risk... heck, I bet you even trust Let's Encrypt to have actually verified that the site you sent your password to was owned by StackExchange, rather than just issuing a cert for StackExchange to anybody who wanted one!

People trust Cloudflare for a few reasons:

The people behind Cloudflare have a reputation. It's a lot harder to get started in a field like that but once you are known to be trustworthy it's your company's most valuable asset.
It would be devastating to them, as individuals and as a business, if they were ever caught abusing that trust. The amount of money it would take to be worth more than the business as a whole or even any individual stakeholder's share is a lot.
They make a lot of legally-enforceable guarantees about how they use the access they have to your connections. Again, any breach of that would have to be tremendously valuable to make up for everything they'd lose.

At the end of the day, you have to choose who you trust. Using Cloudflare is definitely exposing yourself to some risks, but they also provide benefits (including security ones).

Not really the topic of the post, but you've got some things wrong about the risks.

If you don't use Cloudflare's proxies to any site with sensitive content (and just use them for DNS configuration and as a caching layer for your static content, with the option of quickly enabling DDOS protection if needed), Cloudflare can't see any of your requests or responses.
If you enable their proxy for a site, they can see requests and responses involving that site, regardless of whether TLS (HTTPS) is used between the user and the proxy, the proxy and your server, or both. Their proxies have to decrypt the user's request to provide the services you want (like caching responses or dealing with some kinds of attacks), and that means they also need to encrypt the response and could read or edit it before doing so (the user's TLS session is negotiated with Cloudflare, not with your server).
Putting Cloudflare in charge of your DNS in general, and particularly pointing your DNS entries at their servers and providing them with a valid TLS server cert for your domain names (which is how the proxy works), means Cloudflare is "same-origin" as your actual domain as far as the browser is concerned, and that means Cloudflare could make arbitrary requests against your server and see the responses (even if they somehow weren't visible to the proxy anyhow) just by injecting a script that makes XHR/fetch calls.

Also, Cloudflare has competition. Many cloud providers offer at least some of what Cloudflare does (though often only for back-end server hosted on their cloud), and there exist other companies that provide cloud-hosted reverse proxies for security, reliability, metrics, and/or performance benefits.


Do .crt and .key files contain sensitive information?

The .crt file embeds the public key and could theoretically be published. The .key is the private key and should not be published.

Ideally, you don't want to publish any certificates at all, and add a notice for users of the project on how to generate/get their own certificates.


Safely converting untrusted files with Microsoft Word in a web service

Why not simply run a good virus checker against all files on the server?

Also, by default, when accessing Office documents from a network location, Office applications treat them as untrusted so continue with that. You could probably go further and write something to strip any embedded macros but this seems like a lot of effort when the basics are pretty straight-forward. Do you even have any macro enabled Office documents that you use? If not, turn off macros alltogether in Office and then you will be fine apart from the occasional, more sophisticated nastyness you might come across. For that, you need to make sure that your client PC is well protected. Avast or similar along with Microsoft EMET, if you can, configure your client PC to only run whitelisted applications.


Is prototype pollution only exploitable on the back end?

Prototype pollution can be exploited at the front end. Payloads can be sent in similar fashion to reflected and stored XSS, and affect the behaviour of the front end for the victim recieving them. So this is a real issue that you should deal with. The most famous example of prototype pollution vulnerabilities is probably from jQuery - a client side library.

However, prototype pollution attacks can be quite complicated to pull off as they need to be tailored to your specific application. And just because you are using a vulnerable library doesn't mean your application is also vulnerable. Figuring out if you are is probably considerably harder than just fixing the issue, though.

So update lodash! Don't deprioritize it!

If for some reason  an update is complicated, have a look at the no-pollution package that mitigate the issue without solving it completely. (On second thought, that library doesn't look like it solves anything.) If you want to learn more, I found this Medium article very helpful. This question could also be good reading.


How to use information from GHDB and FSDB (Google-Dorks)?

Google Hacking refers to the practice of using search engines, like Google and Bing, in order to discover vulnerable web pages and critical information. It's based on the idea that search engines index a lot of public pages and files, making their discovery a simple matter of building the correct query.

For example, it's trivial to look for a specific type of file (filetype:), on a specific domain (site:), with a specific name (inurl:), containing a certain string (intext:).

The Google Hacking Database (GHDB) was started by Johnny Long, who also published books on the matter, but is now mantained and updated at Exploit Database. I suggest taking a look at some real examples to better understand GH.

As an ending note, the origin of the term google dork, as stated by Johnny himself:

  We call them 'googledorks': Inept or foolish people as revealed by Google.


NetRange and Router Sharing for Pentesting

It generally depends on network setup. Some commercial switches can separate the network out into different subnets, with special routing tables between them. That way you'll have a single physical switch connecting all the machines, but you'll still have several subnets.

They may also be using technologies like ipsec to encrypt and authenticate network communications, which can make a MITM attack difficult, if not impossible.

But, if it's all on the same switch, the switch isn't doing anything "clever", and they're not using a protection technology such as ipsec, then you should be able to perform a MITM attack using a single comprimised host.


Clickjacking is an old problem of the HTML world. There isn't a really good way to "fix" it from the standards point of view without breaking a lot of existing pages.

But I don't think Flash-based clickjacking works anymore in Chrome (nor is it really necessary) because Chrome now requires you to right click on a blocked plug-in to activate it and the context menu clearly says you're enabling a plug-in.

What you saw is more likely just a normal iframe doing clickjacking. This is allowed by all browsers by default and is way more damaging as it also bypasses the same origin policy that Flash would follow.

Installing NoScript can help you defend against them.


What is the risk and mitigation of accidentally typing a YubiKey password in an open forum?

There are some explanations on what YubiKey does here. Basically, the password which the YubiKey "types" (from the point of view of the computer, it is a keyboard) can be either a static password, or a one-time password. If it is a static password, then you just revealed it, and it is time to be very sorry (and promptly change that password).

The one-time passwords, what YubiKey produces follows HOTP. The cryptography in HOTP is such that it is not computationally feasible to recompute the "master secret" from one or several one-time passwords produced with HOTP. Moreover, each password is internally computed from a counter. The YubiKey and the server both maintain the same counter, and the server allows for some limited lack of synchronization. Namely, when the server's current counter has value n and receives a password as authentication attempt, it will internally generate the passwords for values n+1, n+2,... up to, say, n+100 (that's configurable). If a match is found with (say) password n+17, then access is granted and the server's counter is set to n+17; otherwise, connection is rejected and the server's counter is not changed.

Therefore, what you inadvertently published "on the Internet" is a password which will grant access to the corresponding server, until your own next authentication on that server, because that authentication will update the server's counter to a further counter value. In a way, using OTP with counter value k invalidates all OTP values with values j < k. Which leads to the following recovery procedure: if you published an OTP value, quickly connect to the server so as to invalidate that published value. Afterwards, you can just ignore it; once invalidated, it is harmless.

(Note: if you repeatedly generate a lot of "blank" passwords with your key without authenticating to the server, your YubiKey may go out of synch with that of the server -- the key using counter values way beyond what the server would currently accept. Don't let your 3-year-old play with your YubiKey ! In a similar situation, for infrared car keys, counter synchronization is forced through RFID when you start the engine.)


Can an ethernet device plugged into a switch block all the other ethernet devices?

If you want to block devices on a local network with your malicious device connected, you could do something called ARP Spoofing. It can be used to do a man in the middle attack. But you can also just redirect all the packets coming from other devices to you and drop them.
You do that by using the ARP protocol and telling that your malicious device MAC address is associated with the IP address of another host (the gateway for example).

There are host-based solution to prevent this attack whoch are also available on the previous link.


Will the cookies crumble when it comes to proxy servers?

You're not missing anything -- cookies absolutely can identify you when behind a proxy, and you absolutely can link proxy and non-proxy IPs. The catch is that proxies can have many users, so linking the IPs may not be correct -- not all connections from the proxy are from the person with that non-proxy IP address. But if you don't want a site to be able to identify you, merely using a proxy isn't enough (as they can also use cookies to trace you).


What you're seeing is an "open proxy" test: your webserver is being scanned to see if it can be used as a general-purpose HTTP proxy.

The requests are not something to worry about in and of themselves, but they reveal a weakness in your server: you're not logging what response the server makes to the request.  It should be a "404 not found", but you don't have the log entries to prove it.


Secure File Encryption/Decryption Capabilities

You are talking about security in layers, which is great.

The first issue is how to secure the data at rest and in transit, which you are doing with PGP. Your next issue is securing the system on which the data is stored.

It sounds like you are talking about the following issue: You are encrypting the information right before you transfer, but normally its sitting on the system unsecured.

The issue here is that while you are securing data in transit, its not secured on your system necessarily. To combat this, you make sure that your hard drive is encrypted and that you have good logical security and access controls - require strong/complex passwords, set appropriate file permissions, don't share passwords, don't share root or Administrator passwords, etc. You should not be allowing too many users onto the system, and furthermore should enforce role based access (e.g., only certain group or specific users can access where the file is stored).

You may also be concerned that since your private key is stored on the system, if the system is compromised then so is your private key. You can store the private key on a removable media to combat this or implement hardware encryption techniques.

If data is highly sensitive, it should only be decrypted when necessary and the private key should not be easily accessible.

Is there another issue you are concerned about that you can clarify?

Update
I guess the real issue is why does Joe user have system privileges that allow him to access the secure part of the file system? If you are using this server for this automated process, it sounds like very few people, if any should have access to this server. If they do, their group permissions should not allow them to access the secure files when encrypted or not encrypted.

You have to think about security in layers. First, let's do full disk encryption in case the disk is physically stolen at a point when the file is unencrypted at the logical level. Next, lets ensure the file is only decrypted when it needs to be. The decryption keys are stored someplace secure that only root or predetermined users can have access. The files when unencrypted can only be accessed by root and the batch processing user-account using file system level permissions. The only issue you have is if Joe User is also root or Administrator. To address this issue, you need to implement some expensive software or build a home brew solution for password checkin and check  out, also known as privileged identity management (PIM).

A PIM system is secured and stores shared secrets. It usually changes the passwords frequently on a time basis and everytime someone wants to log in or log out. For example, you want to log into a system: The PIM system uses scripts or other functionality to change the password on the remote system you want to access, then it gives you the password and prevents others from logging in while you have the password checked out. Once you are done or your session times out, the PIM system changes the password again so you can't get back in without making another log entry showing you checked out the password. These products are a bit pricey and might be overkill for your situation if you can properly restrict root access or limit root to physical console and use some physical security to prevent unauthorized access to the physical console.


Does running a virtual machine provide a small layer of protection against an infected host in practice

Anything which is different from the attackers expectation increases the efforts needed by the attacker and thus slows down attacks. And if the additional costs are high enough it might also prevent attacks since they are no longer worth the efforts.  Running a VM inside a compromised host is no different to this.
But, if others are using the same kind of setup for added protection it will be no longer different from the attackers expectation: Attackers will catch up and consider this kind of setup too and invest time to efficiently handle this setup, since it would be worth the efforts. Thus, it might help in the short run but it will not help in the long run if others are doing this too.


How did Instagram know the content of my WhatsApp conversation and Google searches?

I'm figuring that the foundational knowledge about this topic is slowly being lost to time, and there are new course modules in schools around the world to cover this type of thing, so I think it's appropriate to cover it here.

There is a separation between the content of a site and the advertisements shown on the site. Sites like Instagram (or newspapers, blogs, or any content providing site) show their own content, but then leave blank spaces to be used by advertising networks. Ad networks then fill these blank spots on the pages that you see, but the content provider (Instagram) may not ever see this information (nor do they care). Ads are not the content of the content provider.

So, what happened has nothing to do with what was in your WhatsApp conversation, but everything to do with the Google search you did.

You searched for the business using Google while you were logged into Google on your desktop and your phone. This created an entry in the Google ad networks that you are interested, right now, about this business. When you opened Instagram, the ad network knew what you were interested in, and showed you an ad based on your recent search.

So, nothing was leaked or shared. A blank field in a template was filled by the ad network based on your activity seen by the ad network. You could go to a variety of other content sites and see the same ad.

This is very relevant to the topic of "security" due to the growing public understanding of "information warfare". Ads can be used to target people's beliefs and ideologies and show specific ads to specific people and can make it look like that it is content from a trusted source (like a newspaper (yes, I am speaking idealistically that journalists can be trusted at a meta level, but let's not get sidetracked by a debate around that)). But the newspaper/blog did not create the content, and it is created, specifically, to engage the person on a specific issue to shift the person's thinking in a specific way that benefits the paying content provider.

So, it is important to understand and identify when content is from an outside 3rd party and how it gets into your feeds so that you can evaluate the trustworthiness and bias of the source.


Zip files can be malicious

Just as most other types of files, zip files may be maliciously designed to exploit some security vulnerability in the application that will be opening them. For example, some 'unzipping' programs had directory traversal vulnerabilities that could allow an attacker to overwrite arbitrary system files in order to gain futher access or core execution; there have been buffer overflow vulnerabilities in these programs allowing the attacker to gain arbitrary code execution when the zip file is opened, etc.

Of course, this requires either that you're running known vulnerable software, or that the attacker is exploiting a currently unknown vulnerability i.e. a zero-day exploit; as far as I am aware, there are no currently known unzipping vulnerabilities that aren't fixed in the latest software versions.

Websites don't (usually) get to modify your files

The stated risk of 'a drive-by-download infecting my important ZIP files on my machine' works a bit differently. A malicious website might trick the user into downloading some file - and possibly opening it. However, the attack would not start with infecting 'your important ZIP files'; if you don't intentionally overwrite them with whatever you're downloading, your 'clean' files won't get modified. The risk there is in opening a different, new zip (or other) malicious file downloaded from that website, not the website magically modifying some of your existing files.

There have been some exploits that allow a malicious website to break out of the browser sandbox and get unrestricted code execution on your machine, however, at that point there's still no extra risk in opening your important zip files because the attack has already happened and does not need user involvement in opening some file.


Is it sufficient to use a hard disk magnet to corrupt/erase floppy data?

Yes, a HDD magnet is fine or any neodymium one and will destroy the data by sweeping such a powerful magnet across the surface of a disk. However, the reliability of such a procedure may vary.

You can also build your eraser in a similar manner to making a head demagnetizer for tapes (which is pretty simple: insulated wire, nail and an input voltage source).

If you erase your floppy disk (completely or partially) using a magnet, the track sector markers are destroyed. A quick format won't find them and therefore the format and/or any write to the disk will fail. A normal format may also fail due to not finding 1st sector marker information. However, special MS-DOS era programs may be able to re-format the disk and rebuild all track sector markers, therefore making the disk reusable.


Virtualization / Cloud-Stack fingerprinting from running VM

About trying to identify the virtualization stack, a KVM host can be identified by issuing a combination of some commands like these:
dmesg |grep KVM
lscpu |grep Hypervisor (it should return Hypervisor vendor: KVM)

You can even try to fingerprint the host with nmap with OS detection option (nmap -O host_to_check_ip), it can give you some information about the MAC address.

I think the same can be done to try to identify VMware hosts and other kind of hypervisors too.


Effect of "decrypting" clear-text then "re-encrypting" it

Always encrypting the same text to the same value leads to data leakage, violating semantic security. To prevent this, CBC mode uses an initialization vector (IV). The IV is just a random string of bits equal to the block size of the cipher. This is XORed with the first block of clear-text to be encrypted. This makes the first encrypted block random. Each successive clear-text block is XORed with the cipher text of the previous block so that each block after the first is also random. From the Wikipedia:

The IV is then stored beside the encrypted text to allow decryption when the process is reversed:

This use of the IV ensures that encrypting the same message twice will not produce the same encrypted text. CBC mode even protects against repetition in a single cipher string. So repeating bytes in the clear-text message will not encrypt to the same byte sequence.

Note that a poorly implemented CBC encryption might reuse IVs and therefore produce the same encrypted text for the same message. See this answer for more information.


What are the potential vulnerabilities of allowing a large http body size?

I'm going to go for an answer but I'm also not an expert on this particular topic, so I'll be curious to read any other answers that might come in.

I believe that the short answer is this: allowing large HTTP post bodies certainly provides an avenue for DOS attacks, but it isn't necessarily the most attractive avenue for DOS attacks.  As a result, I certainly wouldn't set a max body size substantially larger than what I need, but if I needed a large post body I would allow it and not worry to much about it.  In detail:

Preferred DDOS attack vectors

There are lots of ways to DOS a website.  These days the largest DDOS attacks come from amplified DDOS attacks.  These are attacks that (typically) hit UDP protocols that can receive a small amount of traffic and respond with a much larger amount of traffic which can be directed to arbitrary IP addresses on the internet.  For instance, the current (March 2018) record for largest DDOS attack hit github using such an attack vector (https://githubengineering.com/ddos-incident-report/).  These sorts of attacks seek to completely overwhelm the network capacity of the target servers, taking them down for as long as the attack lasts.

The vector used in the github incident had an amplification factor of ~51,000, which means that for each byte of network traffic the originating botnet created, 51,000 bytes hit github.  At the peak of the attack github's network (or their DDOS mitigation provider's network) saw roughly 1.35Tbs of traffic.  Assuming an amplification factor of 51000x, this means the actual botnet that triggered the attack could push out roughly 26Mbs of traffic.  If that same botnet had been used to simply upload large amounts of data to an endpoint that accepted large uploads, there would have been no amplification and githhub would have been hit with a DDOS attack that consumed roughly 26Mbs of github's traffic.  I doubt they would have noticed.

Above I focused on amplification-based DDOS attacks, but they obviously aren't the only option.  The amplification part is what made this one so successful (in terms of network traffic - it didn't actually take down github), but you also need to find a suitable amplification vector that you can exploit to perform such an attack.  Otherwise though, there are many other ways to DDOS a service: you can overrun its CPU capabilities (imagine repeatedly hitting a poorly performing endpoint that sucks up substantial CPU or database resources per request), you can overrun its network by simply throwing lots of data at it, you can hold open TCP/IP connections until the server empties its connection pool, etc...

Disadvantages of attacking a file upload

All this to say: overrunning a file upload endpoint is certainly one way to try to DOS a system, but probably not the best.  The trouble is that it leaves the attacker and defender on equal territory.  You can only overwhelm the target with as much data as you are able to send.  Using up open connection pools, hitting high-resource endpoints, amplification attacks, etc, are all ways to attack a resource that give your resources extra leverage, and make it easier to DDOS people.  As a result, you certainly can DOS someone by overwhelming a file upload endpoint, but there are probably more effective ways to do it.  Moreover, as long as you have enough network traffic at your disposal, I don't think that hitting a file upload endpoint will have any particular advantages: I believe that you can send the data regardless of whether or not the server on the other end feels like receiving it.  The only possible advantage I can see about hitting a file upload endpoint (although again, not an expert in this area), is that the file ends up actually stored on a server somewhere, and you may be able to fill up a hard-drive with large temporary files.  Even this though is probably not the most effective DOS strategy.

All this brings us back to what I originally said: be smart and don't configure your server to allow substantially larger uploads than you need, but in terms of security concerns there are likely larger ones than this.

Securing a file upload endpoint

While a file upload endpoint may not be the first choice of places to hit with a DDOS attack, that doesn't mean that security concerns should go out the window.  As you mention in comments, requiring user access doesn't help much: PHP will accept the upload regardless and store it in a temporary location.  It will get immediately deleted when you don't do anything with the upload, but it will still get written to disk temporarily.

Your other suggestion of setting the /tmp directory size large enough that you can't run out of free space (as determined by your available bandwidth) will certainly make sure your hard-drive won't fill up (although overflowing a /tmp directory wouldn't necessarily kill a server, especially if it is on its own partition). That then shows the next weak point in your chain - if all your bandwidth is being used up in an attempt to overwhelm a file upload endpoint, then your service is going to be down regardless of whether or not your machine has space on its hard-drive (because your network bandwidth is all used up).  Which pretty much answers your question because at that point in time a DDOS via file upload is no longer possible. If your file upload endpoint can't be DDOS'd except by completely overwhelming your network bandwidth, then no one will bother trying to DDOS your file upload endpoint: they'll just aim enough traffic at you to try to overwhelm your network connection.  At that point in time, I'd say that your file upload is secure!

I'm not sure how much it would cost to purchase that much hard-drive space.  It would depend on your hosting provider (although hard-drive space is usually cheap) and your available bandwidth.  That being said, there is also a pretty simple solution to protect such a system: put your file upload system on a separate server on a separate network, (uploads.example.com) and make sure all your systems have some DDOS protection (i.e. cloudflare).  Then a DDOS against your file upload endpoint can take it down, but the rest of your systems would continue on their merry way.  Of course in that case, I can't imagine someone would try to DDOS your file upload.  They would just try to find a more appealing attack vector that impacts your main systems.


Is there a good way to store credentials outside of a password manager?

Install a password manager. A good password manager is much, much better than anything you can do by yourself.

They are software created by security professionals, follow strict development rules, and are tested by a lot of people, and attacked by a lot of people. They have better chance of protecting your passwords than anything invented by the average, even the above average user.


Why are credit card companies generally limiting themselves to 16-digit data infrastructure?

ISO/IEC 7812 is a very old standard that has a relatively large address space even taking into account the Luhn algorithm used and the agreed upon Issuer Identification Numbers. Modern analytics to detect fraud can also easily deal with the card numbers being reused over time which allows number reuse to be fairly easy.

That said, more than anything it's just an older standard that probably takes a lot of effort to upgrade.

Sometimes when updating standards if there is no rush to deploy the change the standards bodies will also wait and watch what is happening in the industry in case they need to change their design before a new update is released. Given the large amount of software that would have to be updated I suspect they won't recommend a change unless it's absolutely required.


At what length does a password stop making sense?

Armed with the knowledge that a search space of 128 bits is more than sufficient for the foreseeable future; with 192 bits being ridiculously high; and 256 bits being something that is unimaginably impossible to cycle through, and assuming that your character set is alphanumeric upper and lower case English, randomly-generated, then we can say that:

A password of 22 characters is more than sufficient for the foreseeable future.
A password of 33 characters is ridiculously long .
A password of 46 characters is just... I don't know what to say.

So, to put it in one line: With an alphanumeric upper/lower character set, it starts making less sense after 22 characters. When does it stop making sense? Somewhere between that and 33 characters, very early.


Best practice for securing encrypted content on Android app

You want to protect them in environment, which has more trust than your app's storage (which can get eventually exposed in one way or another).

Frequently, OS vendors implement secure key storage for such purposes. Not knowing a lot about Android, I've heard Android Keystore System (https://developer.android.com/training/articles/keystore.html) is such storage you can use to protect the keys and it is not directly accessible from userland, as much as I can judge from the docs, so it follows your demands.


If your goal is to mitigate the risks of compromise of the server's database or data store, then encrypting the data on the client side (before it ever reaches the server) can be useful.

If a copy of the server's database falls into enemy hands, probably the enemy won't be able to decrypt all of it (the best the enemy can do is password cracking, which may reveal some of the data but not all).
If an enemy compromises the server, the enemy won't learn too much about previously stored data (the enemy can get a copy of the server's database, but this won't reveal too much about previously stored data).  However the enemy can still spy on all subsequent data, by putting a backdoor in the Javascript that is sent to clients.

If your goal is to protect against a malicious server, or to ensure that if someone compromises the server they cannot do any harm, then "host-proof hosting" (encrypting the data on the client side) cannot live up to those goals.  It cannot prevent a compromised server from sending backdoored Javascript code to the client.  If the Javascript is backdoored, then you cannot rely upon it to encrypt your data properly.

See also Javascript Cryptography Considered Harmful and the questions that @Andrey Botalov linked to, for futher information.


With ZAP Fuzzing you can specify any number of locations to fuzz in a request.

However if you want to apply specific attacks and know what results you're looking for you might be better off with writing an active scan rule. We have various examples here: https://github.com/zaproxy/community-scripts/tree/master/active


Why do I need to add intermediate CA certificates to JVM's cacerts file?

The problem you describe happens usually if the server only sends its leaf certificate and does not add all the chain certificates needed to build the trust chain to the root CA. Unfortunately this is a common misconfiguration of servers.

Many desktop browser work around this problem if they already know the missing chain certificate from earlier visits or maybe download the missing certificate if the leaf certificate contains a URL for CA issuers in authority information access. But this behavior is usually restricted to desktop browsers and other tools simply fail because they cannot build the trust chain.


IR Jump Bag - What kind of bag/container to use?

Depending on the amount of kit you require in your jump bag, you may want a wheeled trolley case or a rucksack, to avoid injury (speaking from experience, I once had to implement a wireless honeypot as part of incident response and the kit included 5 laptops (running simulations, logging etc) and my back ached for weeks)

In any case the only real restriction I would advise is keeping it below airline maximum size and weight considerations - putting forensic kit in hold luggage on the return effectively breaks the chain of custody, and if you do have to fly, leave your screwdrivers/multitool at home in case you aren't allowed to fly with it.


Email clients and POODLE vulnerabilities

Have a look at https://ssl-tools.net/mailservers. There you can get information about the mail server, including the support for SSL 3.0. But, please note that POODLE is about a specific attack pattern which uses a design flaw in SSL 3.0 and which works fine with HTTP to steal session cookies. But, while it is good to disable SSL 3.0 completely, the idea of POODLE can not be easily applied to attack IMAP, POP3 or SMTP protocol to steal the login credentials. This does not mean that these protocols are safe with SSL 3.0, but only that you need to develop a different approach to exploit the flaws in SSL 3.0.


what happens if browser doesn't support X-FRAME-OPTIONS

A browser that supports frames but not the X-Frame-Options header (or the corresponding CSP policies) will simply render any frame content, regardless of the origin. It can't implement a security mechanism that it doesn't know about.

X-Frame-Options was implemented by most major browser around 2010 (and only later specified in RFC 7034 in year 2013) - at that time, frames have already long been around. Introducing the header was a reaction to the clickjacking problem that arised due to  cross-origin frame embedding which couldn't be fully remediated with framebusting techniques.


Is physical security less important with disks on a server being encrypted?

Physical access, in many, likely most, situations means a total loss of security - for a variety of reasons (this all assumes encrypted disks):

Theft - An attacker could steal the server or disks, to attack at their pace. This allows an attacker to take their time, and you have no idea if they've actually gained access to data.
Physical Modification - If I can access a server, I could add hardware, this could be anything from USB or keyboard logging to adding a wireless interface to allow remote access.
Cold Boot Attack - There are attacks that can be used to extract encryption keys, allowing decryption of the disks.
etc.

There are others of course, but this is just a sample of what can happen if an attacker has physical access. There are possible attacks that are still somewhat theoretical, such as applying backdoored UEFI images and the like.

Possibly the worst part of a physical attack, is that you may not even know what exactly was done, so there's a real problem with being able to trust the hardware afterwards.


Is it insecure to reveal if a password is being used for another account after a set period of time?

Yes. It should be considered a breach in security to reveal this information. It deliberately the weakens security of the service. And timing is of no concern here.

It is a false premise that two users having the same password pose a security problem that should be avoided. It does not.
However revealing this very fact is a security concern which shall be mitigated by applying proper salting and hashing passwords. These precautions are meant to hide the fact that two users use the same password.
To illustrate the risk: just think what you could very well write in such an email:

Hey, we have just found that the password you registered yesterday is actually used by one of our users.
Please update your dictionaries for password crackers. And don't forget to immediately check it against our and other companies' leaked account databases.


There is the IEEE 802.1x standard that defines port-based, authenticated network access control for Ethernet local area networks (LANs). With 802.1X, the user or device (eg printer) must pass network access control by successfully authenticating with credentials, such as a name and password, or network access is denied.

The 802.1x uses the Extensible Authentication Protocol (EAP) to relay port access requests between LAN endpoints and the clients being authenticated, Ethernet switches or wireless access points and RADIUS authentication servers.

The 802.1x with AES encryption is considered a secure solution for wireless networks but requires that each device is configured with the correct EAP method and authentication credentials.

These are optional standards and also not used in most networks and printers.


Standards for hiring trusted personnel - American or Canadian Government?

Common Criteria is a system level standard used by both counties (along with many others depending on the accreditation plan) but that does not address your question.  If the issue is related to hiring foreign coders there may be a problem if the project touches International Traffic in Arms Regulations (ITAR) and Export Administration Regulations controls in the US.  This PDF may help http://www.bis.doc.gov/seminarsandtraining/training-modules/essentials_of_export_controls_modules_1_6.pdf   The technology used, if controlled, could present an issue even if the product is not for export as the knowledge is controlled from export as well.


VLANS as a concept remains stable and constant with the implementation of a technology or a solution. The core concept is to define logical set of boundary between networks; a line of trust as to say. Its the implementation that varies and this is where the risk lies.

If you know about ubuntu running under a vmware platform you can define vlans using command such as vconfig. Depending upon the use; your virtual machine is dual homed have (2) NIC cards sitting in DMZ's it may need two vlans to connect to and transfer data.

Just like in physical switch ; you want to filter or define the vlan id that a trunk link can carry; e.g you don't want the ftp server vlan to carry just traffic for ftp servers not anything else.

For inter-vlan routing you need to define intelligent policy at layer 3 router to filter / drop packets based upon security requirement. For e.g non-ftp users accessing ftp farm. Incoming traffic to non-standard ftp ports be dropped as well.

No matter how much virtualized environment you may have ultimately it has to go through physical switches / routers of your organization environment. This is where true control / checks should apply.

Securing vlan is fairly common and well reversed in case of cisco academia (e.g ccna classes). You can start from here.. This link discusses attacks to vlan protocol e.g vlan hopping and what can be done to mitigate the risk.


Is it possible to still perform click-jacking with if a website has SSL?

You should read about what SSL (HTTPS) really is. SSL has no connection to click-jacking, and it is still possible regardless. As dandavis stated in comments, proffesional pages nowadays are custom-scaled to browser resolution, so Click-Jacking is really not often used tactic. Modern websites also use headers to prevent click-jacking by telling browser not to load them in <frame> or <iframe> from other sites.


Modern mobile OSes rely on services provided by the OS's developer like notifications, maps/location services, app stores, iMessage (for iOS), etc.

Activation registers your device with those services - in the background the device gets a token or client certificate it then reuses when talking to those services.


Does the terms stream and block ciphers apply to both symmetric and asymmetric ciphers?

Stream and block ciphers are usually used with symmetric keys. This is for performance reasons as public-key cryptography is much more expensive.

That said, public key encryption also encrypts blocks of data (block sizes in RSA are based on the key size), so it technically uses block ciphers, we just don't usually focus on that.

In short, it's more about the cost of encryption/decryption than anything else. It would be prohibitively expensive to do public-key encryption for large amounts of data.

Symmetric keys give you cheap computation but the problem of a shared secret. Public keys give you expensive computation but easily shared information needed to communicate securely.

This is why the common approach is a hybrid one:

Key encryption key: use public key cryptography to encrypt a symmetric key generated on the fly
Data encryption key: use the symmetric key to encrypt/decrypt the actual data


Is it still possible to run an online dictionary attack from a single machine, without anonymisation?

The security of a web site is not related to the size of the company. Large companies like Sony were hacked and they used poor security practices (clear text passwords). On the other hand, an individual site that would have a security specialist as admin would probably use up to date security protection. The only rule is that the security of a web site is limited by the capacity of its security admin. It includes both raw competences but also financial resources, because physical security only comes at a cost.

Now the remaining part of your question is mainly a question of resource and knowledge between the attacker and the defender: best of the two will win. For the attacker it means a successful exploit, for the defenser it means at least a unsuccessful attack, but the goal is often the identification of the attacker. This is a constant whatever you use as anonymization tools: nothing at all is enough if the target is not interested in knowing who you are, but I would not rely even on TOR to attack the NSA...

That means that if you attack a site, all depends on what you are attacking:

if they have little interest in security, your attack is likely to be unnoticed, and could even be successful
if the use average security, your address will be banned before having a chance to be successful, but things will not go further
if they protect highly sensitive informations, chances are that you find some policemen knocking at your door - or even more drastic action if the site was owned by a criminal organization...

TL/DR: it makes sense to explain how to use tools to attack sites, because this is useful knowledge for pentesters, you can also find some guides on how to protect your anonymity from average sites, because many people do not like to be excessively tracked. But it is unlikely that you find a security specialist to explain how to build an attack from the beginning, because 1/ they are not interested in teaching that and 2/ they know that there is no fit all way.


You are reinventing the wheel. I don't think the state of art really warrants creating a new app from scratch (OTOH if you want to do so for other reasons, like practising creating an app, then go for it).

Note that with secure encryption, the third-party server wouldn't be able to snoop on the conversations (albeit it would be able to record metadata). And if it is open-source, you could replace the server quite easily with your own one.

It would be interesting that you detailed the apps you evaluated along the reasons you had for  discarding them, as I suspect the panorama is not so bad.

  I'm hoping that by using a plugin system, users are free to choose which algorithm to use and that the plugins themselves will be facing serious scrutiny by the general security community.

You need a baseline. You can easily end up with users split by their election of incompatible plugins. It is also generally accepted that most layman people make poor security decisions.

What you propose is right as a design, but you could simply offer a single secure algorithm, then upgrad the app with a stronger one when needed.

If the user can point the apps to a server of their choice, how are they going to communicate? Does everyone need to set the same server? What if I have several contacts in disjoint ones? Are you going to design a federated service?

Working on top of SMS has some nice properties, but it also means you have to fit everything at the sms, keep track of the contacts that have the program installed and thus should have the communication encrypted. And that they did not uninstall it or change the terminal. This was a problem for TextSecure (which ended up removing encrypted sms) or even Blackberry when people change terminals.

  the custom server implementation mentioned above could be used for remote authentications

I don't see a mention of that custom server implementation for remote authentication in your question, but I should note that remote authentication is IMHO the weakest part on most of these messaging apps (unlike their encryption itself -when they do have end-to-end encryption-) as the server could quite easily vouch for someone completely different.

Using ids other than telephone numbers (like a key fingerprint) would be slightly more annoying, but preferable in both security and privacy terms.


Information gathering before deploying a Network IPS

In the ideal situation you would put together a list of all assets and threat vectors on your network, including but not limited to:

Operating system flavors and versions
Applications
Network infrastructure
Anything else plugged into the network

With that you could plow through all of the signatures that are available and include only the ones that apply to you. For instance, if Solaris does not exist on your network, then there is probably no reason to include a signature for CVE-2007-0882 (the telnet auth bypass). In this case you can determine, within some degree of accuracy, which classes of rules need to be enabled before you even insert your first sensor. Keeping in mind that these signatures are constantly being updated and added to, you are better off thinking in terms of types of signature instead of specific signatures.

If you have a tightly regulated network, then go through your CMDB to build out this information. If you don't have a CMDB this might be a good time to get one started. If you are not in a tightly controlled network then you can get started by doing flow analysis or review packet captures. A good vulnerability assessment tool might also help give you a list of what's out there.

In either case, you should assume that whatever picture you develop is incomplete. I would recommend erring on the side of enabling too many rules, and just plan for a pretty intense initial tuning.

Never forget that an IPS/IDS system does have a fair amount of on-going maintenance. As signatures are updated and systems/applications are added/subtracted you will need to evaluate what you're looking for.


Is my server vulnerable to a perl exploit?

Notice the magic string () { :; };. They are trying to poke around and see if your server is vulnerable to the ShellShock exploit. Perl is used here to print and see if the attack succeeded. Make sure to patch and update your server. You should be safe from these kind of attacks.


Continuous integration SaaS security considerations

It's going to depend on the SaaS, but you might be asking the wrong question.  Are the problems mitigated by you self-hosting?  They probably become drastically worse.

CI is inherently problematic only when you forget what it is doing and fail to protect it correctly, regardless of whether or not it's SaaS or self-hosted.  If you are the target, and you have malicious code build procedures on an SaaS, you're probably lucky.  On success, they get pwned.  Not you.  If you have malicious code which was committed to your source repositories undetected, and you deploy that, you're probably in for some hurt.  Services are not going to detect that.

What are you protecting?  Your source code or your servers?  Define risk and determine watchguard procedures for source code to prevent malicious code from being introduced.


Is there a list of open mail relays I can use for a pentest?

There are Domain Name System-based Blackhole List (DNSBL) like SORBS, but they all work the other way around, allowing to test reputation for known IP address. There's a good reason for that.

While you may have permission to test your client's systems, but you don't have permission to use 3rd party servers for your penetration testing! The open relay servers are typically in this condition by accident.

You are confusing two different things: technological term open relay and Mailgun’s service, which isn't really open as it needs registration. The latter is not illegal, but for the same reason it's not any good for your penetration testing, as it's not necessarily blocked by a DNSBL even if your client has one or more configured.

Instead, you should be testing if your client's servers works as an open relay or a partly open relay due to misconfiguration. Recommendations regarding inbound spam filtering can be given without testing, based on the mail server configuration.


How is it possible that this spam mail came from Google Forms without revealing their sender address?

The spammer in question is abusing a Google Forms feature called Response Receipts. If you create a Google form and turn on response receipts, then whenever anybody fills in and submits the form, a copy of the filled form is sent to the email address they provide in the form. This response receipt is sent from the Google service account forms-receipts-noreply@google.com and since it is sent by Google itself, it is also signed by google.com.
So all the spammer has to do is create a Google form with the body of the form containing the content of their spam email. Then they simply submit the form with the victims' email addresses and sit back as Google delivers their spam for them. Note, however, that when I tried replicating this, the response receipt email landed in my spam folder, which means Google does attempt to detect such spam emails. The spammers must have figured out a way to bypass gmail's spam filters for the email to land in your main inbox.


How to make Sqlmap obtain administrator rights for database?

1) If you are inserting into a SELECT/UPDATE/DELETE query you can only issue INSERT statements if stacked queries are available (you have to close the original query and start a new SQL statement). This is a limitation of the SQL language.

2) Privilege escalation would require a vulnerability in the database server or one of the stored procedures. Check the server version and look for stored procedures that execute as privileged user (e.g. EXECUTE AS statement in case of SQL Server). After you find a vulnerability you should execute the trigger instructions, which can be problematic if you don't have stacked queries.


Computer decryption algorithms and knowing the solution

Taking your two questions:

If the expected plaintext is ordinary text, then the computer will look at letter frequencies for the expected language.  If the plaintext is some sort of file, say a spreadsheet, then the computer will look to match the format of such a file, usually the header.  Again, frequency statistics may help; a bitmap file with lots of white space will contain many more 0x00 bytes than a random file would.
It doesn't.  It finds a decryption that seems to fit the expected pattern, or one that deviates significantly from random.  It would be up to a human to determine if this was correct, or just a false positive.


What does "probabilistic algorithm with random tape" mean?

When computer science papers speak about tape, it usually concerns some form of Turing machine. A Turing machine is a fictional machine which can read and write binary values from positions on an infinite string of tape.

However, if this is the case the paper would definitely mention this or provide certain properties of the machine.


Deliberate Vulnerable Openstack images for penetration testing/training or research

After searching across the internet, it seems there are really no "ready made" vulnerable OpenStack images similar to web applications like OWASP DVWA. However, I think a starting point is to install old OpenStack releases  and also install some vulnerable software on it. I have found icehouse easy install here. I will like to start working on this...any one interested in this topic is welcome.


Can my ISP see MAC address of devices which are behind router?

Do your network segments look like this?

                                                             _    ____
                  +-------------+       +------------+      / \__/    \
Internal LAN------+ Your Router +-------+ ISP Router +-----+ Internet /
                  +-------------+       +------------+      \________/

If so, your inner router must be misconfigured. You're right, MAC addresses are not passing a correctly set up router because ethernet is not routable.

So it doesn't matter whether that portal sits on the ISP's router or somewhere in the internet; in both cases, it shouldn't have access to your internal MAC addresses unless you somehow actively provide them.

If your ISP's Router (located at your home) provided WiFi to your internal clients, then obviously that would explain where it got their MAC addresses. Or if your router acted as a bridge (and especially if the ISP's router then offered DHCP to your internal LAN), that might explain it. Or if you installed a special app on each of your devices that sent the device mac to your ISP, that would also explain it. I think that in all other cases, your router is configured wrong; it's passing information it shouldn't.

If you're not sure whether your router is acting as a bridge, tell us the network addresses of your internal lan and the lan segment between your router and the ISP's router.


The thing about security is that it's never a one-size-fits-all sort of deal. Because of that you always have to adapt designs to apply to the threats you're willing to counter. A good security design pattern is just a good software design pattern.

If you take a look at Wikipedia it lists a few: http://en.wikipedia.org/wiki/Security_Patterns

There is also an interesting website I came across while Googling: http://www.securitypatterns.org/patterns.html

Or if you take a look at CERT ( http://www.cert.org/archive/pdf/09tr010.pdf ) it lists a few. Here are some just from it's list of figures:

Defer to Kernel Pattern
Secure Factory Pattern Structure
Secure Strategy Factory Pattern Structure
Secure Builder Factory Pattern Structure
Secure Chain of Responsibility Pattern Example
Secure Chain of Responsibility Pattern Structure
Secure State Machine Pattern Structure
Secure State Machine Example Code Collaboration Diagram
Secure Visitor Pattern Structure
Secure Visitor Example Code Collaboration Diagram
Secure Logger Pattern Structure
Clear Sensitive Information Pattern Structure
Structure of the Input Validation Pattern


Besides OpenVas and Nessus, what are my other options for vulnerability detection?

There are quite a few (read loads) in this space. Some examples:

nmap - can run on *Nix'es and Windows

The following offer internal or external vulnerability scanning and management

Core Impact - may be outside your budget
Microsoft Baseline Analyzer - free (but obviously focused on Microsoft)
Retina
Nexpose
Qualys
Randomstorm
Accunetix
GFI
Outpost
Appscan
etc.

Then you have web vulnerability scanners like nikto and code assessment tools like Fortify

Have a read of Fyodor's sectools list


Openflow and SDN is in no way different from other control mechanisms for network equipment. It's up to the administrator of a network how he decides to secure the equipment. The connection between the Openflow capable switch and the controller can run over TLS, and can even be authenticated by SSL certificates. Thats gives you the same level of security as you have with e.g. key based SSH connections. From this perspective the level of security is comparable.

But keep in mind that if the trust relationship between the controller and the switch is established, the control capabilities the controller has will be much broader and more granular than a manual or automatic configuration of existing switch features can be. Therefore there is some room for bugs and failures in your SDN application.


RSA is an algorithm (actually, two algorithms: one for asymmetric encryption, and one for digital signatures -- with several variants). PGP is originally a piece of software, now a standard protocol, usually known as OpenPGP. OpenPGP defines formats for data elements which support secure messaging, with encryption and signatures, and various related operations such as key distribution. As a protocol, OpenPGP relies on a wide range of cryptographic algorithms, which it assembles together (which is not as easy as it seems, if you want the result to be secure). Among the algorithms that OpenPGP can use is RSA.

So, to keep with the car analogy, your question is like: "What is the difference between a combustion engine and a Honda Accord ? Why would one choose one over the other ?" The question makes no sense per se: the Accord comes with a combustion engine under its lid. It also comes with a bunch of other useful features, such as wheels; you cannot do much with a combustion engine alone.

Still in that analogy, you can imagine cars without a combustion engine, e.g. electric cars. Translated into the OpenPGP world, the question becomes: can OpenPGP perform its work without using RSA ? And the answer is yes: there are other asymmetric encryption and digital signature algorithms that OpenPGP can use, which will provide the same functionality than what OpenPGP uses RSA for. Historically, when OpenPGP was first defined, there were still a few unsolved questions about the RSA patent, so implementations were encouraged to use El Gamal and DSA (for asymmetric encryption and digital signatures, respectively), instead of RSA. (The RSA patent expired in 2000)


Spoofing POST/GET requests in a RESTful service

My question is what prevents users from intercepting their regular post form the app (getting the token) and then possibly sending bunch of POST requests (using something like postman or fiddler) to create a large number of fake posts or articles or whatever else the app does.

Nothing

  Does the fact that the traffic to the service will eventually go via TLS make this a non-issue?

This makes no difference at all.

  What are some possible ways from protecting from this?

The most common one is rate limiting. I.e. if someone posts at a much higher level than anticipated reject the post. There are several approaches to this - when did they last post, rolling average over N minutes etc. If you don't want false positives resulting in users losing post content then make them re-authenticate to continue.

Another approach is captchas. I.e trying to make the user prove they are human.

Another is attempting to detect automatically generated content using spam filters or AI.


Is it possible to configure TLS/SSL in Nginx without persisting the private keys on disk?

I'm unclear if the goal is to have a fixed set of certificates that are repeatedly used or if the intent is to have an NGINX server where the keys cannot be exploited if the server is compromised.

One alternative approach might be to use letsencrypt.org to automate certificate generation and with the correct set of scripts continuously refresh them.

A walkthrough for Ubuntu 16.04: https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-16-04


Can my isp see what I legitimately download?

The reason it's hard to find a quick and easy answer to your question is that there really isn't one.  The closest thing to a quick and easy answer that is right is:

  Your ISP can see every byte of data you transmit on the internet, and every byte any server sends to you across the internet.

They have the physical wires you're sending bits over.  They not only can read this data, they are obliged to read it, in a sense, because they need to route it to the right places.

However, what that doesn't account for is the readability of those bits.  Some protocols, like http, send everything "in the clear," meaning anyone who can read the data on the wire can get access to everything you transmitted.  Other protocols, like https, encrypt the data so that the ISP can see bits were transferred, but they can't glean any meaning out of the data.

This is all very protocol specific, so there is no one answer.  For example, with HTTPS, the ISP can know the IP address of the server you are talking to (because it has to be sent "in the clear" for the internet to work), but they don't get to know the hostname.  In most cases, they can do a reverse IP lookup and figure out the host name, but a single server may serve many host names.  For all we know, the servers that service www.google.com also respond to https queries where the host name is yahoo.com, and provide a different (secret) API to people to access it that way.  All the ISP knows is that you accessed 216.58.219.14.

Digging deeper requires a very careful threat model.  If your adversaries are Three Letter Agencies or major nations, you may find that you leak information in timing or file sizes, and they may be able to do something with that.  Regardless, the amount of information that can be gathered is 100% dependent on the protocol you are using.

As for your email, the answer is "it depends on how you access your email."  Email goes over different protocols.  GMail, for instance, goes over https.  Many ISP provided emails use POP.  Their behaviors are very different.


The cryptography in existing apps is usually strong enough. This means that the focus of attackers (including law enforcement) is not to break the cryptography but to compromise the endpoints to get access to the messages before encryption or after decryption.
Your approach does not actually protect against this main attack vector. Instead you add some obfuscation by using an image and some noise. But this isn't actually sufficient to hide the message against someone who compromised the endpoint - especially if the message is intercepted already before obfuscation or after deobfuscation.
The only other obfuscation is to use an atypical application for communication. But if you are the target of an attacker who was able to compromise your endpoint, then this does not help much either. It is simple to check what applications are installed and then have a closer look at suspicious applications and their activity. This is assuming that your device was compromised since you were an explicit target, this means the attacker is actively looking for something interesting on your device.
In other words: it is probably not a good idea. At least it does not really help you to achieve your ultimate goal, which is to protect your communication from a highly capable attacker like law enforcement.


DISA STIGs are always good:

http://iase.disa.mil/stigs/os/mac/mac.html

DISA is the Defense Information Systems Agency, the IT shop for the US Department of Defense. STIGs are the configuration guides that they publish for security networking and computing devices.


Is biometric passport safer than old-fashioned passport

This very much depends on implementation and the data stored.  For instance if the passport has a chip with your DNA information then it is relatively secure since it is really something someone else cannot fake, well they can if you reference Gataca, so it would not matter if the db was hacked or not assuming the implementation is by physically taking a DNA sample.  As others have mentioned fingerprints and facial scans can be duplicated but mostly because they can be digitized and analyzed easily, DNA samples cannot without very expensive machinery.  In other words, at this point in time no one will use a blood sample to access your bank account online, if they did then it would be more susceptible, however I can see governments using DNA analyses to verify the identity on a passport.

The problem with a lot of common bio-metrics is that there are fairly easy ways to fake it, like rubber finger prints or makeup which can be faked without ever physically accessing the person, taking blood or skin samples requires access to the source of the material and is harder to trick people with.

Of course the alternative is a password or a signature which can have it's own issues, I would say if there was a choice fingerprints would be more secure, if for nothing else it would be a lot more trouble for someone to obtain then a password.

Hope that helps


Is it feasible/possible to have encrypted data that looks unencrypted/innocuous?

I would guess what you want is actually steganography.

The drawbacks of this approach includes:

Some kind of shared secrete is needed between the sender and the receiver;
The "encrypted data" will be much bigger than the secret message itself.


Subkeys are bound to the primary key and exported together with it when calling gpg --export or gpg --send-keys. Same applies to signatures and user ID packages.


Secure communication between two REST apis

There are many possibilities to enhance the security:

use HTTPS for transport encryption
authenticate with an API key
only allow connections from specific IP addresses
use certificate pinning (store the server's public key fingerprint and compare it when connecting to prevent MITM)
isolate the two servers from the rest of the network or the internet

As always, there won't be perfect security and you have to decide on how much effort you want to put into securing your data depending on your threat assessment.


Is it recommended to patch announced vulnerability for unused services or features?

This is a risk assessment and threat modelling style question - rather than a hard yes or no.

Do you want to accept the risk of not patching the service, which could be exploited in the future -  may be someone runs it later on. Or do you not accept the risk of updating your OS/software which could cause adverse affects on running services.

Only your individual situation will be able to answer those, and often there will be different answers depending on the threat landscape and importance of the server/application in which you are assessing.


The same tools that they use to build and maintain large complex features: version control, engineering process artifacts (like specs and architecture overviews), and bugs/task/issue tracking.

So let's say Alice does a STRIDE analysis and finds a set of spoofing issues.  As part of doing that, she adds some trust boundaries to an architecture picture, and updates the version in the wiki.

She documents the set of threats and checks it in as a .txt file next to the code for the component.  Some apply to her component and become issues to investigate, some apply to Bob's component, and so she opens bugs for him, and some are unclear, so she shoots off an email which leads to a discussion meeting.

(This is a pretty broad question, so if my answer isn't helpful, let me re-frame your question a little: What tools do your teams use to collaborate across their large projects, and in what ways do those not work for threat models?)


What steps should I take to ensure there are no unpleasant surprises in a recently purchased home?

In terms of surveillance, on a consumer level, most of what you're likely to run into are WiFi-based surveillance devices and cheap baby monitors.

There are two tricks to discovering WiFi surveillance devices in your area. One trick you can sometimes do to find WiFi-based cameras is kill the power (at the breaker), wait 10 seconds, then bring it back online and watch for WiFi APs on your phone. Many of them send out a beacon SSID for configuration during startup.

The other trick, for WiFi-based cameras that connect to a configured network, is to use a WiFi card in promiscuous mode to capture probe packets. These packets are effectively the "are you there?" queries from the client device when they are trying to connect to the network. There'll be some noise from nearby devices, but again you can turn off the power, look to see which devices are sending out queries, turn on the power, then look for new devices (particularly ones that reliably send out a probe packet within the first 10-15 seconds of power being turned on, but never when the power is off).

Baby monitors are trickier. They're mostly running on 2.4GHz band, which puts them outside the range of most cheap RTL-SDRs (usually no more than 2.2GHz), but they're not WiFi devices. Instead most of them transmit using FHSS. If you buy a down-converter for your SDR so that you can receive 2.4GHz, or buy a pricier SDR with a wider tuning range, you can look for FHSS signals in the 2.4GHz band. They look like this:

Note the strong carrier, two sidebands, and characteristic spots over the frequency domain. Unfortunately you'll need to do a lot of manual searching, since the 2.4GHz band is quite expansive, and that still won't tell you where the device is. Again you can cut the power to see if the signals go away so that your neighbour's baby monitor doesn't give you false positives.

For audio-only baby monitors you can scan for narrow FM (NFM) on 40MHz and 49.5-50MHz (protip: get a battery radio and turn it on as a background audio source to make the signals more visible on your SDR) and wideband FM (WFM) on ~860MHz. You can also check the DECT bands (1920–1930MHz) for strong signals, again doing a differential test with power on and off, although you'll need some magic to decode these back into audio as they're not analogue.

On the physical side the locks are the main one. Don't forget sheds and garages, as they often contain valuables and are overlooked when changing locks. Ask your locksmith to install a cylinder lock with protection against snapping, bumping, and drilling, as these are the three most common low-skilled attacks. Not many burglars will SPP or rake a lock but you can get a fancy pick-resistant cylinder if you wish.

You should check to see whether the locks on lockable windows are working - it's easy to grind off the lever on them so that they appear to work (key goes in, turns) but it doesn't actually prevent the window from being opened. Also verify that all exterior doors open inwards, as outward-opening ones will have the hinge pin on the outside and that can easily be knocked out to remove the door (outward-opening fire escape doors have special pinned hinges to prevent this attack). Again, you can ask your locksmith to do a once-over of all the locks and security controls in your property.

Finally, you can install deterrents like an alarm system and motion-sensor floodlights. They make it hard to approach the property without being spotted and make it even harder to break into the door unseen. Back doors are more preferable as they're away from the street, so a wall or fence and a locked gate preventing access helps a lot.


How do a firewall's rules for individual programs work?

Application filtering firewalls are hooked into the operating system at the kernel level and aware of any file access. That file access awareness includes network sockets.

For a visual demonstration of this on:

Linux, use lsof -i
MacOS, use lsof -i
Windows, use Process Explorer

The firewall is aware of the requesting process and associated network information (port, state, address, etc.) just as those applications above are, but it also has the ability to modify, prevent, or close connections.


What are the alternatives to null byte injection attack?

For RFI you don't need null byte, simply match the file extension on the remote file, inject a ? Which turns the extension into query string, use URL rewriting, etc, etc. For LFI however you may be able to pre-pend a number of ././ or /./. to cause the total path to be too long and php will truncate it. This is trickier as it is is length/offset dependent and you will need to brute force the length unless you know the local path and finally as you are padding by two bytes you may need an odd or even number of bytes in the filename for the truncation to align.


A way to prevent non distributed, network-level DoS attacks?

A DoS is different from the other concerns you mention.

With MiTM, zero is the only acceptable number of successful attacks. Zero is the only acceptable number of successful SQL injections. Zero is the only acceptable number of brute forced passwords- and why even subject yourself to password brute forcing, disallow passwords altogether and whitelist IPs.

With DoS...if you are infrastructure supporting commercial customers, then, sure, transient request lossage directly costs money. That's a metric that one can care about.

If the service is best effort, there is probably a level of "successful" DoS that you can ignore. There is a gradation of acceptability for the risk.

To have some insurance, you can apply per-IP rate limits at the network level, e.g. https://making.pusher.com/per-ip-rate-limiting-with-iptables/, and you can apply per-IP rate limits at the application level in nginx, e.g. https://www.nginx.com/blog/rate-limiting-nginx/ or with any rate limit plugin for Wordpress.

But because it's amorphous, distill the concern into a metric that accurately expresses the distinction between caring and not caring for you. This measurement may just be a report from a web ping service giving you an availability score.


Is PCI-DSS Compliance Required with PayPal Donate/Payment Buttons on Websites?

The merchant or charity who accepts only PayPal, and uses a mechanism that redirects the customer/donor to PayPal's site does not handle the credit card at all.  PayPal does that, takes a fee for the service, and remits the rest to the merchant.

So, PayPal has to comply with PCI-DSS, but the merchant who uses only PayPal and does so with redirection to PayPal does not.  The merchant's bank may require them to complete Self Assessment Questionnaire A.  That is applicable as follows "SAQ A merchants may be either e-commerce or mail/telephone-order merchants (card-not-present), and do not store, process, or transmit any cardholder data in electronic format on their systems or premises."  Completing it will mostly require checking "Not Applicable."


SHA & MD5 Collisions for shorter strings

Short answer: collisions don't matter for password verification. The length of the input is irrelevant.

I understand that md5 and sha512, etc... are insecure because they can have collisions.

No, this is wrong. MD5 and SHA-1 are insecure because it is possible in practice to find collisions.
SHA-512 and the other SHA2 variants (SHA-256, SHA-384, etc.) have collisions. We know this by applying a very simple mathematical theorem, the pigeonhole principle. A SHA-512 hash is a 64-byte string. There are strictly more strings of 0 through 64 bytes than strings of exactly 64 bytes. Therefore there exist two distinct strings of at most 64 bytes that have the same SHA-512 hash. This is a non-constructive proof. We have absolutely no clue how to actually find two such strings. SHA-512 is secure because cryptographers have tried to find two such strings for years and haven't gotten any closer. This is the standard for a cryptographic algorithm being “secure”.

This is not for passwords.

Indeed. For passwords, collisions are irrelevant. If there are multiple valid passwords, it doesn't matter. What matters is that an attacker cannot find any of the valid passwords. SHA2 is as insecure as MD5 and SHA-1 for password hashing: password hashing must be slow and salted. It's an unfortunate historical accident that the word “password hashing” includes “hash”: the two have very different properties.

However, is it still possible to have a collision if the string length is less that the hash size. Ie. md5 is a 32 character hash. So if the string is less than 32 characters, is it possible to still have collisions?

Maybe. We don't know. We know that there are collisions among strings that are at most the size of the hash, by the pigeonhole principle, as I wrote above. We don't know whether there are collisions among strings that are exactly the size of the hash: it's possible that all of them map to a different image. Mathematically, that would mean that the hash, with an n-bit output, is a permutation on strings of length n bits. This is extremely unlikely since the proportion of functions on n-bit strings that are permutation is extremely small, but we don't know for sure.
I don't know, without doing more math than I care to at this time, whether it's likely that there are collisions amongst strings that are strictly less than the size of the hash. I won't do the math because it doesn't matter.
By the way, MD5 is actually a 16-byte hash. It's 32 characters long if you write those bytes in hexadecimal, but most 32-character strings are not the hexadecimal representation of anything, so counting 32-character strings is irrelevant.

However, this only works if no other string that is 10 characters long equals the md5 hash of: 1f129c42de5e4f043cbd88ff6360486f

Wrong. This only works if it is impossible to find another string that is 10 characters long and has the same hash. If another string exists but nobody can find it, that's good enough.
MD5, SHA-1 and SHA2 all use the Merkle-Damgård construction. They work by processing the input one block at a time. For each input block, they apply a compression function (a different one for each MD or SHA variant) to the current internal state and the input block to produce the next internal state. At the end, they append some padding to the last partial block and apply the compression function one more time (or more depending on the exact length of the input). The techniques for finding collisions for MD5 and SHA-1 attack the compression function: they are based on finding block content B1 and B2 such that two distinct internal states S1 and S2 map to the same resulting internal state S'. The techniques allow very little control over the content of B1 and B2, so they don't allow creating collisions where the input is less than one block long, perhaps minus a few bits at the end which can be brute-forced to look like the valid start of padding. (In fact, as far as I know, it takes two blocks of input to reach a collision.) So we don't know how to find collisions on strings that are shorter than the block size. Both MD5 and SHA-1 have a 64-byte block, so there is no way to find a collision where one of the strings is shorter than about 60 bytes.
Of course, even if the current attack techniques don't allow finding a collision on short input, it would be stupid to use a known broken hash function. Attacks only ever get better.


JavaScript code authenticity when loaded from 3rd party website

There are no built-in solutions.  (But there certainly should be!)  You can indeed download the data using XMLHttpRequest 2 and then verify its hash using a JavaScript SHA-256 implementation before doing something with the result (e.g. evaling it, if it is JavaScript code).  This will only work if the untrusted server supports CORS.  The browser cache of the resource can still be used.


Key Management: storing encrypted key in database and decrypted key in session variable

I was thinking about doing a similar thing.  I came across this answer while searching which seems to imply that this is an acceptable practice as long as you aren't using passwords or password hashes in the key.  https://security.stackexchange.com/a/18998/39545


How can we use a symmetric key for signing data on TPM2.0?

AES is a symmetric block cipher.  Like most block ciphers, it is typically used for encrypting data, although it can be used in constructions such as CMAC (or other block cipher-based MACs) for creating message authentication codes (MACs).  Since these MACs use a symmetric key, that same key is necessarily required to verify the MAC.  Also, none of these block cipher-based MACs are available with tpm2_create.
While people do sometimes refer to the process of creating a MAC as "signing", more properly that term refers to algorithms that are used in digital signatures, such as RSA, ECDSA, or EdDSA.  All of these algorithms are asymmetric, containing a public key and a private key.  The private key is required to sign, and the public key is required to verify.  There is no way to turn a symmetric key into an asymmetric key of this type.
So what you're asking to do is functionally impossible.  You can't use an AES key to sign anything, since AES cannot be used to create a digital signature.  Depending on your TPM, you can use several different options for signatures, as outlined in the tpm2_create(1) manual page, but AES is not one of them.