What are some steps to take for securing a Linux server that aren't in this list of obvious ones?

Run your web application as a different user than everyone else.  This is what www-data is for!!!!!
Remove write access to your web root!  (And only your web application (www-data) should have
read/execute)
Use a Web Application Firewall (WAF).  Naxsi for Nginx is an
option however mod_security is a better WAF.
Remove access to port 22 using Port Knocking Or Bastion
Host (Bonus points for using both!)
Force HTTPS only to avoid OWASP a9 violations.  HTTP should only
be used to set HSTS and redirects to HTTPS.
Last I checked Ubuntu doesn't have AppArmor rule sets for ngix,  where as
they do for the LAMP install.  Also be aware that nginx is very young
and as a result more advisories are released for ngix than
[Apache]
setup apt autoupdate for security related updates.
If you have the money,  get a pentest


Yes, it makes a lot of sense.

Firefox does not have an XSS filter, but noscript provides one.

While browser-side XSS filters are not an ideal solution to XSS and can possibly be bypassed, they do catch a great number of reflected XSS attacks. As those are one of the most common web attacks, it is good to have some client-side protection against them (this is even true if you are careful clicking on untrusted links; XSS payloads can also be submitted via forms from websites which you sort-of trust).

Additionally, noscript provides protection against clickjacking. It also claims to have limited protections against CSRF and that it automatically adds the secure flag to cookies.

Weighting these benefits against the downsides of installing third-party software into your browser is difficult, but just the XSS protection would be worth it to me.


Where I've encountered this issue in the past, the best approach I've seen is to script something up in your favorite programming language of choice (e.g. Ruby/Python/Powershell) to retrieve instances of the tokens and then write them to a file.  Once you've got a suitable sample, you can load them up into your entropy analysis tool of choice.

Another option would be to use Burp Suite and its sequencer tool, which allows you to specify a custom location in the HTTP response for the token to be captured from. (more information here)


why CA use private key to sign a digital certificate? What is the logic behind sign a digital certificate with CA private key?

Signing is one of two basic operations you can perform in public key cryptography:

encryption: encrypt with recipient's public key, decrypt with matching private key
signature: sign with sender's private key, verify with matching public key

The goal of digital signatures using private keys is to ensure that the message is as intended by the signer and not modified. Anyone can verify the integrity of the message (in this case: a certificate).

The hash algorithm is applied to the message (the certificate contents), the output padded to the length appropriate to the key size, then signed. This ensures two things:

we have an amount of data to sign that can be handled by the algorithm (eg: RSA, ECDSA)
that data is a representation of the contents themselves

It is important for the certificate signature algorithm to be a safe one (with no known practical weaknesses). This is why md5 and sha-1 are no longer recommended.

You can find more details about message signature using RSA in this crypto.se answer.


Looks like this metadata lists document IDs that were used during creation of the file. You can check this article: http://www.hackerfactor.com/blog/index.php?/archives/2013/05/23.html, search for the "Ancestors" section.

So, it contains technical metadata which could be placed there 'naturally' by the Adobe applications.


Detecting/preventing rollback of encrypted data on a server

The prevention of roll-back on Databases is not easy. Let's talk about rows.

Adding date and time  will not help, you need to store the date of update locally and id of the data.
HMAC will not help, same as above
HMAC and date : will not help, same as above
Channing all rows will not help. The attacker can revert back to an old state in all of the states. You can store the last value of a chain, then you need to look for the validity of the chain.

Is there a solution?

Better use Merkle Tree, which is optimal and requires only log n data transfer. Keep the HMAC of all cells of a row in the last column of the row and use the Merkle tree on this column only. With this, you need only store one Hash value, locally.

If your application servers are also under threat, than you can uses either

a third party, or multiple of if so that in any conflict you can be sure about the change.
Another solution is using HSM in application servers to store the value.

There are some academic articles about the integrity and authenticity of the databases, most of them missing/hiding the rollback problem. The Merkle-Tree is the king.


Can a website's privacy policy be made more effective by incorporating it into company bylaws?

The common way to ensure customers that you actually respect your own rules is to ask a third part to audit and certificate your business. If it is important for you, ISO provides a bunch of normative document that certification organization know. The best known is ISO 9001 for general Quality Management, and the IT counterpart is ISO 27001.

So my opinion is that the best proof you can provide to you customers is a ISO 9001 + ISO 27001 certification.


WebRTC is a P2P technology and performs encryption end-to-end by default.

No metadata on Mozilla's servers. Per session encryption, so Mozilla cannot decrypt.

There may be some vulnerabilities with the technology (i.e. there are), but the design is supposed to address your questions on an architectural level.


Is + as an alternative to %20 an attack vector?

Just for reference: http://host/path?query

The + symbol is somewhat problematic in URIs, this is because it is interpreted differently by different URI encoder/decoders. It is always interpreted as a space if it occurs in the query part of the URI (everything after the ?), however whether it is interpreted as a space if it occurs in the path part of the URI is down the the decoder used.

Your example uses the path section, and the answer will depend upon precisely what decoder you are using. Most of them will not decode + to space when it occurs in path, but you don't know until you try with your specific decoder. This is exactly the type of nasty sanitisation-bypass that can bite you :P


How is the file overlay read by an exe/virus?

The overlay is just appended data to the end of the executable file.  Detecting this can be tricky.  But keep in mind that this portion is only ignored when loading an executable into memory.  Opening the file for reading will allow access to the entire file including the Overlay portion.

The PE header will contain the size of the executable, and you can attempt to base the start of the overlay section on this.  However, this size could be any size including zero or 0xffffffff.

Viruses most likely use the executable portion to gain a foothold into the system, and then load more more suspicious code into memory from the overlay once they have appropriate permissions.  In this case the virus already knows where in the file to find its extra code.

The advantage here might be that the initial actions by the EXE will allow it past virus scanners to run, and the overlay portion isn't taken into account.

How to Append Data to an EXE is a nice little article that talks about how this can be done for legitimate means.


What is the technical rationale behind intermediary email servers?

SMTP is a very, very old protocol, dating from the early days of the Internet when connections weren't reliable and security wasn't a major issue.  Many of the issues with SMTP (open relays, unauthenticated senders, etc.) are the result of trying to provide reliable delivery on an unreliable network where everyone knew everyone else (or at least everyone else's sysadmin).

The original rationale for intermediate servers was that if your server couldn't contact the destination server, it might be able to contact a third server who could relay the email to the destination.


How to obtain privacy and authenticity with DNS?

In short, either install a DNSSEC enabled resolver with QNAME minimization (RFC 7816) on your computer or use DNS over TLS (RFC 7858) towards a remote server you trust/control.

Now in more details, as the previous setup caters for different cases, and can also be combined in some way.

First DNSSEC is not something that you can just use on your side to be applied everywhere, and it is not something that will help for privacy. For zones that are DNSSEC enabled (that have signatures), if you resolver validates them, then you have the guarantee of authenticity (you could not get fake data) and integrity (things could not be changed or downgraded).
This is useful and solves some issue but:

not all domain names are DNSSEC enabled, far from it even
it does not prevent anyone reading your DNS traffic as it remains in clear, both the request and the replies

So if you do that, you must trust your ISP or anyone on the network not to sniff your traffic. Anyone will be able to watch your DNS messages, and alter the one not DNSSEC enabled.

The other option is to connect with TLS to some remote DNS server that speaks this new protocol. This gives you two benefits:

noone will be able to snoop, nor change, your DNS messages as they are all protected by TLS, and this applies to both DNSSEC and not DNSSEC enabled domains
the authoritative nameservers you query will only see the other nameserver IP and never yours.

Of course a poor man's alternative would be to do an IPSEC or SSH tunnel, to get almost the same benefits, however not without some complexities, as you need to handle both UDP and TCP. Or a SOCKS proxy. But since DNS over TLS is a standard now (at least a RFC) it may make more sense to pursue this way instead.

I said you need to trust/control this remote DNS server because obviously it will see all your DNS traffic. So it depends on you to define who you can trust or not. Some public open DNS providers do also provide DNS over TLS nowadays, for example CloudFlare: https://developers.cloudflare.com/1.1.1.1/dns-over-tls/ but you can find many other ones here: https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Test+Servers

If you need to use such nameservers that you do not control completely, some may advise you to set things up in such a way that you use multiple ones and that you spread your queries among them, so that no single one could reconstruct your whole DNS session. A little more complicated to put in place as this is not the standard way a list of nameservers operate by default.

As a side note, the standard of DNS over HTTPS is currently cooking and should arrive "soon". I guess that many providers will offer this service, so you will have the same dilemas as today with VPN providers
(who to trust, etc.)

Also you said "But each DNS server only sees one component of the domain, they don't get to see the entire target." which is wrong in practice today. The protocol allows that but for various reasons since no one remembers when, the recursive nameservers were sending the whole name (each label) to each authoritative nameserver at each step. It is only now with QNAME minimization standard (RFC 7816) that resolvers can do the traversal by sending only one label each time. This is not without problems, as some nameservers do not cope with that (hence some recursive ones implemented a fallback strategy: first try with QNAME minimization and if it fails start again with full name as before)


In the USA, you can report SMS phishing attempts to the US-CERT by forwarding them to 772-6; emailed phishing attempts can be reported to phishing-report@us-cert.gov.  See the US-CERT website for more details.

In other countries, you'll have to check with your own government.


Confused about symmetric 128,256 key and the secret provided

The passphrase is used to derive a key from using a hashing algorithm which turns the passphrase into a fixed length series of bits.

Most implementations will use the PBKDF2 hashing algorithm to generate a hexadecimal key of 256-bits. The easiest way to do this is to use PBKDF2 with SHA-256.

An important note though, AES itself doesn't care about how the key is derived, all it wants is something which is 256 bits long. How you generate that key is beyond its scope. There are bad ways to generate keys and there are good ways. The above mentioned method is considered a good one. If you want to know more about how key derivation works, I suggest reading this wikipedia article.


Are there regulations that govern how social security numbers are stored and viewed?

This is one of those times that there may not be a clear and specific answer, but I assure you, there is an answer.
Part of that answer is found in one of the comments here made by Artog. There IS a NIST publication on the subject. The bigger concern is this...
In every Security class we discuss the prudent person rule. The question is “what would a prudent person do with this situation?”
If this company is using insecure methods to protect data that can potentially harm people (SSN, name, address, phone number, employer, etc) they CAN open themselves to huge liability. They could be responsible for any financial problems they cause.
There are several problems with what you have posted:

Is someone already exploiting their database?
It is likely the problem will only be discovered after damage is done.
Then, the question is, do they notify anyone in the database of the breach?

The reality is, that unless whatever this database is falls under some form of regulation/control, it is unlikely that a change will happen. Because change costs money, and the business is likely already making money off the database with the vulnerabilities you described in place.


I believe you're confusing the purpose of a salt. You can derive a salt from an infinite amount of ways, but that doesn't change the purpose of the salt. And for the salt's purpose, it need not be secret.

So when reviewing critiques on your salt derivation, just understand that you're getting this feedback based on the purpose of the salt.

Other than that, user authentication can be very broadly generalized by something you know, or something you have. An image falls under the category of something you have.

Keeping that in mind, its fun to experiment and be creative with custom authentication schemes, but these schemes have not been hardened or analyzed for weaknesses, and for that reason, they should not be used in a production application.

The security industry is sort of like the FDA. It's not that you can't make a new, effective, safe drug, it's just that yours hasn't passed inspections.  Inspections are costly, and if the problem is already a solved problem, we can't be arsed to inspect yours.

And that is why we generally respond, unfortunately in a brash way, of don't roll your own security. It's a solved problem.


It looks like you assume that the identity of the server is proven by the server demonstrating that he owns the presented public key. But this does not prove the identity of the server from the perspective of the client.

An important part of validating the servers identity is that the client verifies the servers public key against the expected one. That's why the fingerprint is presented to the client for validation on first connect or if the key has been changed. This means that the fingerprint or public key needs to be known by the client up-front, i.e. before key validation. What you describe is instead blindly trusting any key presented to the user in the hope but not certainty that it is the correct one (TOFU - trust on first use).

  Someone told me that the server domain certificate is able to solve the problem

Certificates in SSH have a similar role as certificates in TLS (and thus HTTPS). They have a public key inside and they are issued and signed by a certificate authority trusted by the client. In case of certificate based authentication the server presents the certificate which includes the public key and the issuers signature. The issuers signature can be used to validate that the certificate was issued by the locally trusted authority and thus that they public key in the certificate is really the expected servers key. After that the public key is used as in normal key based authentication, i.e. the server has to demonstrate that it owns the private key for the public key.

With certificates the client thus does not need to know every server key up-front. It is instead sufficient to trust a specific authority that it issues and signs the correct certificates which include the servers public keys. This makes it more scalable if you are dealing with lots of different systems which are all managed by a few entities.

For how to use certificates in SSH see for example How To Create an SSH CA to Validate Hosts and Clients with Ubuntu.


Risk to Domain members in a Domain that's extended into the DMZ

I would principaly worry about what is allowed by the firewall(s), and what are the privileges of the accounts used in the DMZ on the internal machines. The real question is IMHO what could happen if an attacker could break the security of an application running on a DMZ server:

does the firewall allow connections from that server to the internal lan?
does any internal server (or client machine holding shared resources) accept connections from one of the users used in the DMZ?

If above risks (DMZ -> internal zone) are already covered, you can then considere DMZ -> DMZ, meaning if one application in the DMZ is compromised, is this account able to do anything on other applications from same server, and what about the other servers.

I know those are just hints, but it is the best I can without more elements on your actual configuration, including the small details as noticed by paj28 in its comment.


My recommendation at that point is use a better service that doesn't require you to pass the information from one form to another.  If you are handling PCI at all, then you have to worry about at least some of the regulations.  It is best to have your system call out to a payment provider, let the user use their site and then their site will tell you about the success or failure.  Many vendors will even let you do it in such a way that it doesn't look like they are leaving your site.


Does 2FA Help Prevent Unauthorized Access in Phishing Attacks?

2FA alone does not help in this scenario. If the 2FA input screen on bank.com does not have other protections, like TLS, pinning/HSTS, MITM protection, and/or verify the client or detect login anomalies, then there is a vulnerability.
This is a case where an integrated password manager in the browser can help the end-user, by not providing the credentials to begin with.
Other types of 2FA, besides user-entered codes, offer greater protection.


Why are passwords limited to 16 characters?

If you are to abide by CWE-521: Weak Password Requirements.  Then all passwords must have a min and max password length.

There are two reasons for limiting the password size.  For one,  hashing a large amount of data can cause significant resource consumption on behalf of the server and would be an easy target for Denial of Service.   Especially if the server is using key stretching such as PBKDF2.

The other concerns is hash length-extension attacks or the prefixing attack against MD5.  However If you are using a hash function that isn't broken,  such as bcrypt or sha-256 ,  then this shouldn't be a concern for passwords.

IMHO 16 bytes is far too small.  bcrypt has a built-in cap of 72 characters,  which is probably a reasonable size for a  heavy hash function.  Key Stretching used by these functions creates the possibility of an Algorithmic Complexity Attack or ACA.


What usually happens is that the CA creates a certificate for a company, and that company signs the software. The CA validates whether the company is who it says it is, but doesn't check the software at all.

So a corporation called ACME can get a certificate for ACME from Thawte CA. They can then sign any software with that. If you receive such signed software all you know is that ACME signed it. It says nothing about the software. Thawte didn't check the software, they only checked whether they gave an ACME certificate for ACME.

If you don't know the company, the fact that it is signed doesn't offer any security. It only offers security if you know and trust the company. For example, if software is signed by Microsoft I generally trust it not to be malicious. If it is signed by ACME I still don't know.


Bypassing password authentication in example PHP

The extract() imports variables into the current symbol table from an array. The get_contents might actually be file_get_contents() which reads a file into a string. The file could be either on the local filesystem or from the Internet via HTTP.

If you know the contents of the text file referenced in $pass you know the password you should have in $inp, but you don't have that file nor its location.
$_GET['pass'] becomes $pass because there's the extract($_GET);. Hence, by adding a GET variable you can change the password required for printing the answer.

I would try a file with predictable contents, e.g. ?pass=/etc/hostname&inp=server.example.com%0A – the Line Feed character %0A is required, because /etc/hostname ends with a newline.


Recover deleted file despite full disk encryption

In addition to Moshe's answer, I'm going to provide an example with LUKS since some people seem unconvinced. Also, see here for why overwriting may not be 100% effective (although it certainly helps).

Example

Make a sparse file, create a filesystem, and mount it:

$ truncate -s 100G /tmp/device
$ mkfs.ext4 /tmp/device
$ sudo mount /tmp/device /mnt
$ sudo chown user:user -R /mnt

Make a few confidential files:

$ echo "super secret data" > /mnt/secret
$ echo "super secret data" > /mnt/confidential
$ echo "super secret data" > /mnt/top-secret

Get inodes for files:

$ ls -li /mnt
total 28
13 -rw-rw-r-- 1 user user    18 Nov 10 11:34 confidential
11 drwx------ 2 user user 16384 Nov 10 11:33 lost+found
12 -rw-rw-r-- 1 user user    18 Nov 10 11:34 secret
14 -rw-rw-r-- 1 user user    18 Nov 10 11:34 top-secret

Ensure files are written to disk, then get extents for inodes:

$ sync /mnt/*
$ debugfs -R "stat <12>" /tmp/device
...
EXTENTS:
(0):33793
$ debugfs -R "stat <13>" /tmp/device
...
EXTENTS:
(0):33794
$ debugfs -R "stat <14>" /tmp/device
...
EXTENTS:
(0):33795

Check those blocks to make sure the data is there:

$ dd if=/tmp/device bs=4096 skip=33793 count=1
super secret data
1+0 records in
1+0 records out
4096 bytes (4.1 kB, 4.0 KiB) copied, 1.9034e-05 s, 215 MB/s
$ dd if=/tmp/device bs=4096 skip=33794 count=1
super secret data
1+0 records in
1+0 records out
4096 bytes (4.1 kB, 4.0 KiB) copied, 1.888e-05 s, 217 MB/s
$ dd if=/tmp/device bs=4096 skip=33795 count=1
super secret data
1+0 records in
1+0 records out
4096 bytes (4.1 kB, 4.0 KiB) copied, 7.1178e-05 s, 57.5 MB/s

Remove the files:

$ rm /mnt/secret
$ rm /mnt/confidential
$ rm /mnt/top-secret
$ ls -l /mnt
total 16
drwx------ 2 user user 16384 Nov 12 17:34 lost+found

Format the device using LUKS, then create a new filesystem:

$ sudo umount /mnt
$ sudo cryptsetup luksFormat /tmp/device

WARNING!
========
This will overwrite data on /tmp/device irrevocably.

Are you sure? (Type uppercase yes): YES
Enter passphrase:
Verify passphrase:

$ sudo cryptsetup luksOpen /tmp/device encrypted_device
Enter passphrase for /tmp/device:

$ sudo mkfs.ext4 /dev/mapper/encrypted_device
mke2fs 1.42.13 (17-May-2015)
Creating filesystem with 26213888 4k blocks and 6553600 inodes
Filesystem UUID: 279e6c3b-a183-4a94-b06e-78db1665b2a0
Superblock backups stored on blocks:
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
    4096000, 7962624, 11239424, 20480000, 23887872

Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

Now we have a new filesystem:

$ sudo mount /dev/mapper/encrypted_device /mnt
$ sudo ls -lR /mnt
/mnt:
total 16
drwx------ 2 root root 16384 Nov 10 11:37 lost+found

/mnt/lost+found:
total 0

But is our secret data still there?

$ dd if=/tmp/device bs=4096 skip=33793 count=1
super secret data
1+0 records in
1+0 records out
4096 bytes (4.1 kB, 4.0 KiB) copied, 1.8944e-05 s, 216 MB/s
$ dd if=/tmp/device bs=4096 skip=33794 count=1
super secret data
1+0 records in
1+0 records out
4096 bytes (4.1 kB, 4.0 KiB) copied, 2.2056e-05 s, 186 MB/s
$ dd if=/tmp/device bs=4096 skip=33795 count=1
super secret data
1+0 records in
1+0 records out
4096 bytes (4.1 kB, 4.0 KiB) copied, 8.7082e-05 s, 47.0 MB/s

Conclusion

Unless you wipe the disk, it's probable that at least some of the old data remains there unencrypted.


As one example, Kerberos requires time synchronization. If you connect to a time server that changes your time by a large amount, it could interfere with the operation of kerberos. There may be other protocols that depend on embedded timestamps for secure operation.

Also: some applications do not behave well if the time suddenly jumps. It may be possible that there are attacks based on changing the time. I don't know about Windows, but the NTP daemon on *nix systems tries to gradually adjust the time instead of jumping it -- for this reason.

A good way to sync with a time server (especially if your system clock is off by a lot) is to manually set the time "close enough" to what you can manage manually -- within a few seconds is best, within a couple of minutes is fine if you don't have a good time source. Then connect to the time server and the local time service / daemon can make smaller adjustments to the system time, possibly spreading the adjustments out over a longer time so that there are no jumps in the system clock.


Would this be an accurate proverb towards IT security?

It is right, but note: you have to differentiate between the practical and the theoretical possibilities.

If your attackers need $10^500$ clock cycles to decrypt your data, then the possibility of a crack is only theoretical. In practice, you have a much more chance that the crack happens because a software, hardware or theoretical fault in your systems, as anybody could crack it in the next billion years.


How secure is NOPASSWD in passwordless sudo mode?

NOPASSWD doesn't have a major impact on security. Its most obvious effect is to provide protection when the user left his workstation unattended: an attacker with physical access to his workstation can then extract data, perform actions and plant malware with the user's permissions, but not elevate his access to root. This protection is of limited use because the attacker can plant a keylogger-type program that records the user's password the next time he enters it at a sudo prompt or in a screensaver.

Nonetheless, requiring the password does raise the bar for the attacker. In many cases, protection against unsophisticated attackers is useful, particularly in unattended-workstation scenarios where the attack is often one of opportunity and the attacker may not know how to find and configure discreet malware at short notice. Furthermore it is harder to hide malware when you don't have root permissions — you can't hide from root if you don't have root.

There are some realistic scenarios where the lack of a password does protect even against sophisticated attackers. For example, a stolen laptop: the user's laptop is stolen, complete with private SSH keys; either the thief manages to guess the password for the key file (perhaps by brute force), or he gains access to them from a memory dump of a key agent. If the theft is detected, this is a signal to investigate recent activity on that user's account, and this means that a planted malware should be detected. If the attacker only had user-level access, anything he did will leave traces in logs; if the attacker obtained the user's password and ran sudo, all logs are now compromised.

I don't know whether the downsides of NOPASSWD balance the upsides for your use case. You need to balance that against all the other factors of your situation. For example, it seems that you allow but don't enforce having different passwords. Can you instead use a centralized account database? How much containment do you need between your systems? Are you considering alternatives to Ansible that would support differing sudo passwords? Have you considered other authentication mechanisms?


On Mac OSX using FileVault 2, are all user's files unencrypted if the current user has rights to login from cold boot up?

This is a common misunderstanding of the purpose of full disk encryption (FDE). It's job is to protect from an offline attack, where the disk is removed and connected to another computer.

If your computer is turned on, then FDE is no longer doing anything to protect your disk. At this point, you are being protected by the Mac's operating system's access controls, not FileVault.

Those aren't bad, although of course if the technical account needs admin rights to run the diagnostic tool...

Finally, as ever, there is immutable law #3 to consider: "If a bad guy has unrestricted physical access to your computer, it's not your computer anymore."

You'll have to evaluate your threat model. What are the risks? What do you fear the technician might do, and what would that cost you? Based on this you can work out what will make the risk acceptable. For example:

If the risk is low, then your plan to create a separate account should be fine.

If your risk is high, then a safer approach is to wipe the hard drive before bringing it in, then restoring your sensitive data afterwards.

If your risk is very high, then you'll just have to not get your machine serviced.


How to access directories disallowed in robots.txt?

The robots.txt does not disallow you to access directories. It tells Google and Bing not to index certain folders. If you put secret folders in there, Google and Bing will ignore them, but other malicious scanners will probably do the opposite. In effect you're giving away what you want to keep secret. To disallow folders you should set this in Apache vhost or .htaccess. You can set a login on the folder if you want.


Does my brokerage/bank use poor password security measures?

"Salting" makes sense only as part of password hashing. From the response you got ("passwords [...] are on a secure, encrypted channel"), one may infer that:

Passwords are not hashed at all. The bank is able to recover your password at any time.
Some sort of encryption is applied, either for the storage itself (with an unspecified key) or for the transfer from one machine to another within the bank system (probably SSL). Or maybe both.
Whoever answered you does not consider that you can understand technology, or does not understand technology himself, or both.

As for the limitation on password length, it is indeed a problem and a very poor practice, since it prevents you from using passwords with high entropy and yet easy to remember (see this question). There may be technical reasons for that (compatibility with a legacy system -- and there are a lot of legacy systems in banks), but it is equally plausible that the limitation comes from a poorly understood Tradition (see this question).

Now let's take the point of view of the bank. What is the use of your password ? Is it to protect the your assets ? No ! The password is there to protect the bank. Not you. Your password is not for you; it is for them.

The bank, as a whole, wants to make money. Successful attacks make them lose money, because:

they have to refund the user;
they must deal with the loss of reputation.

Passwords can be used to reduce these losses, in several ways:

If the break-in is through guessing the password of a user, then the bank can claim that it is not their fault, but the fault of the user who chose a weak password. This limits the damage to reputation.
Similarly, if they can point the user for being at fault, they may get away with not refunding him.

If the password is strong, then the probability of a breach is lowered. However (and that is an important point), long and complex passwords increase the probability of the user forgetting his password. Such an occurrence implies a phone call to the helpdesk, hence a loss of money. There is a potential for a trade-off here.

What must be remembered is that the bank tries to maximize its own profits and thus uses criteria which do not necessarily match your own assessment of the situation. They may oppose really strong user passwords if such passwords imply higher cost on their part, be it on compatibility layers with legacy systems or increased helpdesk usage. Their best interest does not necessarily match your best interest.

Moreover, password security is poorly implemented in general, because it is not well understood, as is demonstrated by the abundance of myths floating around (e.g. the myth which says that including punctuation signs improves security). That the bank is old does not mean that it is good at handling recent technology.

In any case, most cases of bank account theft are not due to a password too easy to guess, but to a password which was stolen with a key logger. Chances are that the effect of the "password rules" does not even show up statistically, so the bank has no real way to measure how efficient or inefficient that specific security policy is.


Importing bcrypt passwords into Active Directory

AD only uses LM and NTLM password hashes for domain authentication.  You won't be able to import the bcrypt hashes and have them work to authenticate users to the domain.

You could modify your web app authentication process to temporarily capture the plaintext password when a user successfully logs in and create a corresponding AD user account for them with that password.  This assumes you have time to wait for the majority of your users to log in before they start using the AD.  Anyone who doesn't log in during that time wouldn't have an AD account.


Buffer Overflow protections in custom library

Compile-time protections in an executable do not confer protection to code in linked libraries, or vice versa. If you have an executable linked against a library, both the library and the executable must be compiled with protections if you want to protect the entire thing. If only the executable or only the library has the protections, then vulnerabilities present in the code that is not protected may be exploitable.


Constant time compares when array sizes are not equal?

Aborting early is fine, as it doesn't reveal timing for anything secret (unless you consider the length to be a secret, which doesn't seem plausible).

As for your edit, comparing password hashes in non-constant time is also fine. The attacker has no efficient mechanism to "choose" password hash outputs such that he can iterate through all possibilities for a byte at one position while holding the preceding bytes constant. So there is again no timing attack — not even to reveal the hashed password.


I provided lots of un-encrypted personal data to Google Drive over the years. How can I best retake control over my data?

I went through this recently and completely de-Googled everything. I will try to answer your questions with a bit of my own experience.

  What are my prospects of improving this situation?

Google has a cute little "take back my privacy" feature that is at best a socially awkward joke with an offensive punch line. It's just there to give advocates the warm fuzzy - don't think for a second it does any real good. The alternative therefore, is to move away entirely.

If you're going to move away from Google's prying eyes (and I fully support this) it comes with some sacrifices but is well worth it.

The best way to begin is to import your docs into something like Zoho or disroot hosting providers and are much more privacy friendly. Zoho has a very user-friendly application that will basically upload your entire Google Drive for you and make migration very, very easy. It also has the ability like Google Docs to collaborate online with others and edit via URL. Disroot is not as mature of an organization, but has very high regards for privacy and also is an Email provider. I bought a domain through GoDaddy as as registrar and moved my Email to protonmail, a Swiss company renowned for both their mail and VPN services (although I use VyprVPN instead.... for now). You can use a custom domain or keep the protonmail.com domain, if you'd like.

Ditch Chrome for Firefox and use DuckDuckGo as your search engine. This part might be the most crucial regarding Google's collection of information about you, even if you did not ask about this.

Finally, privacy from Google Docs is near worthless if you use an Android because they will accumulate most of your personal information anyway. You can  install Copperhead OS on your Android phone which completely and utterly removes ALL google services and is built for the ultimate privacy (if not always convenience). You may opt for Waze or Nokia's "Here" instead of Google Maps. I traded Google Play for F-Droid and Aptoide. Finally, I traded Youtube for NewPipe and actually love the "play in background" feature.

  Could I reasonably take out the data, encrypt it, and re-upload it to Google or another storage service to make it less likely that hackers, rogue Google employees, or any rogue authority can access it?

You could, but that would not serve much purpose. They still have your data and your encryption is probably no match for Google's engineers assuming they actually wanted it, and Google keeps a lot of metadata, meaning that while your individual documents 'might' be safe, your video consumption and music habits on youtube, driving history on maps, search history, doctors appointments, emails, etc is all kept as well assuming you use other google services.

If you REALLY want to erase ALL of your data, start looking in to and using tools found here and start doing a reverse google search on yourself. There are quite a few companies who aggregate and sell your data (persopo, radaris, etc), so you will need to go through them one by one and request that your records be deleted. It's time consuming, but if you're in IT security especially, it's well worth it.

Finally, consider how important social media is to you, because besides Google and the US government, Facebook is the biggest privacy violator out there, and LinkedIn and others are not far behind. (NOTE - I may be a hypocrite but I keep LinkedIn still. Tinfoil hatters gotta eat too!)

This may be extreme measures for you, and that's understandable - privacy and convenience has a trade off.


Does requiring users to fill out a PDF w/ CC information and mail it back violate PCI compliance?

Why don't you ask about their privacy policy? It would be the only way to resolve that aspect of the question.

I would expect your issuing bank or card company are the best people to ask if the request is compliant - they have the knowledge, authority and responsibility, and you can verify their identity. Commentators here at best will be able to refer you to a standards document, which you'll have to read, and then worry if your interpretation is accurate.

As to the practice itself - yes I think it's risky. Weigh it up against how badly you need to buy the product from that supplier. Credit cards can always be cancelled, but there can be lots of information on a government ID that shouldn't be floating around in someone elses data store.


How to give rights to a System Administrator in an application?

How about you factor out authorization to a single function that makes all security decisions. Calls would be something like isAccessAllowed(user, FOO_OPERATION, <misc data>). Then your admin check is a single conditional in the start of the isAccessAllowed function.

Implementing such a system also allows you to change security backends without having to rewrite your application. It also does a nice job of separating security code from application code.


What part of TLS specifies how to verify a certificate chain

Within SSL/TLS, the server sends its certificate chain systematically to the client (well, unless the client wants to negotiate a cipher suite that uses no certificate at all, but that's pretty rare in practice). See the TLS standard, in particular this diagram, which says it all:

  Client                                               Server

  ClientHello                  -------->
                                                  ServerHello
                                                 Certificate*
                                           ServerKeyExchange*
                                          CertificateRequest*
                               <--------      ServerHelloDone
  Certificate*
  ClientKeyExchange
  CertificateVerify*
  [ChangeCipherSpec]
  Finished                     -------->
                                           [ChangeCipherSpec]
                               <--------             Finished
  Application Data             <------->     Application Data

         Figure 1.  Message flow for a full handshake

For (much) more complete explanations on how SSL/TLS works, read this answer.

Note, though, that while SSL/TLS formally relies on X.509 certificates, the protocol is not irremediably married with X.509. Within the handshake dynamics, the idea is that the server sends its public key to the client within a certificate chain, and then the client somehow uses the server's public key. How the client obtains the server's public key is a bit out of scope; normally, the client does so by decoding and validating the certificate chain sent by the server, but the client is free to "know" the server's public key from any other way that it sees fit. In some dedicated applications (especially embedded systems), the client may contain a hardcoded copy of the server's public key, and just use that, completely disregarding whatever the server sends as "certificate chain".

Moreover, the "certificate chain", from the point of view of SSL/TLS, is a sequence of opaque blobs, such that the total length does not exceed 16 megabytes. While these blobs are normally encoded X.509 certificates, they may be something else, as long as the client agrees (and a client who ignores the server certificate chain will, by definition, agree to anything). There is even a formally defined RFC for using OpenPGP keys instead of X.509 certificates in SSL/TLS.

IF the certificate chain follows the usual rules (X.509 certificates, that the client validate), then the X.509 rules apply. The complete X.509 path validation algorithm is a work of the Devil to confuse and corrupt good men's minds. However, as a simple summary, an issued certificate (your "intermediate CA certificate") matches its issuer (in your case, the root) through the two following properties, which must all be fulfilled:

The subjectDN field in the issuer (root) must be equal to the issuerDN field in the issued (intermediate CA). Thanks to the multitude of possible encodings and Byzantine Unicode rules for case matching, actual "equality" of names is a potentially complex notion.
A certificate is signed; the signature on the issued certificate must be verifiable with regards to the issuer's public key.

Therefore, if you want to keep the intermediate CA certificate unchanged, then, at the very least, the new root will need to use the exact same name as the old one, and also the exact same key pair. If you change either (or both), then you will need to reissue a new certificate for the intermediate CA.

The same principles apply down the chain: if you change the intermediate CA certificate, then you might still keep end-entity certificates unchanged (the certificates previously issued by the intermediate CA), if (and only if) the new intermediate CA certificate still contains the same intermediate CA name and intermediate CA public key.


No.

If the user input is properly encoded (HTML encoding in this context), XSS is not possible as user input will never be treated as JS code. Proper HTML encoding (conversion of input into their HTML entities) is the preferred way of preventing XSS when any user input is inserted/reflected back within HTML code.

Your example seems to be a case of DOM based XSS (where user input is never sent to the server and is inserted into the DOM directly). If this is the case, the conversion into HTML entities (HTML encoding) is being done on the client (browser) it self.

Chances are, this input is reflected back somewhere else in the response (case of Reflected XSS). Some examples where XSS can be performed in your scenario:

As value to another HTML attribute (HTML context) where this input is not HTML encoded.
As value to an event handler or declared as a JS variable within the inline script tags and given the data is not properly encoded here.


Managing website passwords for small team

I would highly recommend using a variant of KeePass. I use KeePassX, it will allow you to keep a local repository of all of your passwords and sensitive information encrypted and accessible to all of your team members.

I have been using KeePassX at work for about a year now and have had no complaints.


In order to exploit the vulnerablity, a MITM attacker would
  effectively do the following:

  o Wait for a new TLS connection, followed by the ClientHello
  ServerHello handshake messages.

  o Issue a CCS packet in both the directions, which causes the OpenSSL
  code to use a zero length pre master secret key. The packet is sent to
  both ends of the connection. Session Keys are derived using a zero
  length pre master secret key, and future session keys also share this
  weakness.

  o Renegotiate the handshake parameters.

  o The attacker is now able to decrypt or even modify the packets in
  transit.

  The script works by sending a 'ChangeCipherSpec' message out of order
  and checking whether the server returns an 'UNEXPECTED_MESSAGE' alert
  record or not. Since a non-patched server would simply accept this
  message, the CCS packet is sent twice, in order to force an alert from
  the server. If the alert type is different than 'UNEXPECTED_MESSAGE',
  we can conclude the server is vulnerable.

Source: https://nmap.org/nsedoc/scripts/ssl-ccs-injection.html

You can use openssl s_client in linux for sending packets to the server and confirming the vulnerability manually.

Moreover I will suggest you to use testssl.sh available on https://testssl.sh because the tool is way more comprehensive and accurate.


can the site not auto redirect the main page to the advertisement in some time without the need for user clicking on the link or opening the new tab?

They lose your focus. You got redirected to the ad site, you probably will not get back. If you got interested, you will interact with the target site, not theirs. If you aren't interested, you close the tab.

can the site not open the advertisement in the new tab automatically?

They can open a new tab and not be blocked only in a short time frame after loading the page, or when you interact with the site. That's why some sites that opens a popup have a link saying Click here to open, so if your browser blocked the automatic popup, the link will open it.

can the site not open the advertisement in the new tab instead of opening the content in the new tab and opening the advertisement in the main page?

They aren't interested on the ad being seem. No matter if you saw it ow not, they are getting paid anyway. Opening their site on a new tab makes the history clean, and you probably will close the ad on the original tab, and lose the track of the sites you went until reaching theirs.


Trying to install 2 products which hack deeply into the operating system while doing the same job is unlikely to be a good idea. It's likely that the second will simply displace the first. It's possible that that they may recognize the other's fingerprint database as containing the original malware.

OTOH, for a high security corporate gateway, where the 2 products are running on separate hosts, then yes, it should give better coverage.


In my case, I use this working alert rule for SYN Floods.

alert tcp any any -> 192.168.1.3 any (msg:"TCP SYN Flooding attack detected"; flags:S; threshold: type threshold, track by_dst, count 10 , seconds 30; sid: 5000001; rev:1;)

Where:

The "threshold" keyword means that this rule logs every event on this SID during a 30 second interval. So, if less than 10 events occur in 30 seconds, nothing gets logged. Once an event is logged, a new time period starts.
The "track" by_dst keyword means track by destination IP.
The "count" keyword means count number of events.
The "seconds" keyword means time period over which count is accrued.
The "sid" keyword is used to uniquely identify Snort rules. This information allows output plugins to identify rules easily. This option should be used with the "rev" keyword.

sid < 100 Reserved for future use
100 < sid < 999,999 Rules included with the Snort distribution
sid > 1,000,000 Used for local rules

There are further information here and here.


Email and telephone identification - gmail

I think you might refer to this passage in my answer to your question, rather than the comment you linked to:

  Much more plausible would be to ask the email provider for data on previous or subsequent usage of the account. If it gets accessed over the mobile network and the provider has logs of its NAT, the phone may be tracked.

There are several steps here that are to be taken, none has anything to do with email headers. Given, sometimes information is leaked through email headers; yet, let's assume they use a webmailing service with fake information. No information is leaked about the sender then.

Yet, as described in my previous answer:

If

the Email-Provider can give information on IP addresses previously or subsequently accessing this account and
the mobile network provider that those IP addresses belong to has traffic logs and logs of its NATs,

there might be a possibility that the actual user of the email address can be tracked.

Still, both points are big ifs and pretty unlikely to happen,

For the first case, because the user might never again use and never previously used that account and there are few legal ways to track that information.

For the second case, because the data neccessary for that is huge and again, legal reasons.


Should I keep scrypt/bcrypt parameters secret?

I would say that the cost parameters counts as "implementation details" and relying on them beeing hidden would therefore be security through obscurity.

Actively keeping them secret would be like using them as some kind of low entropy pepper. Not entierly useless, but almost. Plus, if an attacker manage to crack one password she will know the correct factors. So just try password1 with some different factors on all passwords, and you are done. If you want an additional secret to protect the passwords, just use an ordinary pepper or encrypt the hashes. Those are solutions actually intended to solve this problem.

That does not mean that you need to disclose them to all the world unless you have reason to. Sure, if you want to tell someone to brag about how secure your system is, go right ahead. But I would not put it on my webpage, especially if they were low since that could encourage attackers. (On the other hand, saying "we use bcrypt" is sort of like putting up an "beware of the dog" sign on your fence.)

Most people use one of a few sets of cost factors. I would encourage you to pick cost factors based on what is good for your system, and not what is hard to guess.

Do note that the cost factor is right there in the hash, so you would need to actively cut it from the string to implement this. But I would not bother.

Somewhat related question: Can I share what password hash function I used in a public report?


Is it possible that a Peer AS over BGP can sniff other AS traffic?

Your question is a bit broad since you're not very explicit in which traffic you're talking about and what exactly the relationship between those two network is.

If two networks (ASNs) have a peering relationship and exchange routes, the result is that traffic is routed between those networks. Of course, network traffic from peer A which is routed to peer B can be sniffed by peer B (and vice versa), since it passes their network equipment.

Traffic exchanged between peer A and another peer C cannot be sniffed by peer B.


Why are website (such as gmail.com) certificates issued by my company?

Some companies want to be able to inspect all traffic exiting their network (data loss prevention, etc.). To do this, they require that all encrypted traffic be decrypted before it exits.

To make this possible, the company then issues its own certificates for external domains. Normally, those certificates are issued by Certificate Authorities (CA) that act as neutral 3rd parties for this sort of thing. But in an SSL Interception scenario, the company itself issues the certificates. Your traffic flows from your client, to the company border, gets decrypted, inspected, re-encrypted, then passed on to the destination.

The potential issue here is that the company might not be as up-to-date or as secure in the way they issue certificates as a CA. But that might not be a huge issue because the only people you are being protected from are the other employees at the company.

So, to answer your question, the local, company-issued certificate is not as cryptographically strong as it could be, and your browser is issuing that warning.


How can I detect malicious activity based on patterns of DNS requests?

There is no way to reliably detect all malware using DNS analysis only but DNS analysis can help a lot.

While some malware might be detected based on access to known to be bad domains (i.e. domain blacklists) other might be detected because they use uncommon domain names or use a known domain generation algorithm. Deeper analysis can also make domains stand out which have rapidly changing mappings to IP address, i.e. fast flux networks. There is also be malware which stands out because of use of TXT records or similar. But there is also malware which communicates using social media sites and thus does not stand out in most networks. And of course there is malware which uses fixed IP addresses for communication and thus does not cause any DNS traffic at all.

In short: there is no reliable way to detect malware using DNS analysis only. But DNS analysis can help a lot. The easiest ways are probably DNS blacklists provided by various vendors or the use of specific DNS servers like OpenDNS which already block lots of suspicious DNS activity. Apart from that the better you know your network the more unusual activities stand out. These might indicate malware activity, but there might also be other reasons for unusual activity.


Is there any danger in subpages that can be called by url but cannot compile due to missing includes?

It is enough to rely on the compilation error but it makes your webpage more error prone.  For example maybe sometime you will (accidentally) enable php error output and then you will have a information disclosure. You should always make it hard to do mistakes.


OAuth authorization code grant with exposed client secret

Yes, exposing the client secret would increase the risk of a token being compromised, but there are other pieces that would need to perfectly fall into place for that to happen. If we look a an example POST for a token in the Authorization Code Grant Flow:

POST /oauth/token HTTP/1.1
Host: authorization-server.com

code=Yzk5ZDczMzRlNDEwY
&grant_type=code
&redirect_uri=https://example-app.com/cb
&client_id=mRkZGFjM
&client_secret=ZGVmMjMz

Implementation may differ in slight ways but let's look at a couple other pieces of information (in addition to the client_secret) that the attacker also needs to get a token:

code - The authorization code that is granted is typically single use only. Obtaining a code would mean having access to an authorized user's account and completing the authorization request prerequisite to this grant type.

client_id - While not a 'secret' per se, this is the registered applications id which would need to obtained and is not usually something that is guessable. (though I suppose if the attacker has the client secret, they also have the id? Seems odd to have obtained one and not the other)

The authorization code is definitely added security compared to implicit grant, but also like you suggested, Auth-code is much more secure because the token is not meant to be returned to the user-agent (browser). It's more commonly implemented in a backend/frontend application with the code/token exchange happening in the backend.


Using SSLStrip, password is still encrypted

SSLStrip is a transparent proxy that is used to prevent the victim of a MITM attack from uing SSL by clicking on an SSL link. To achieve this SSLStrip replaces all links that start with https:// with http://. The Idea behind this is that most users arent aware of encryption and just use encryption becaue the owner of the webpage links or even redirects them to the secure version of the webpage.

The request you see is clearly not encrypted because you can read it. So this is not a problem of SSLStrip. It is application specific. You can preprocess a password by using javascript. This process can be triggered by clicking the submit button for example. This is done to prevent a sutuation where the pasword travels the wire. It seems like you are in such a situation. Have a look at the webpage with firebug. You can check the button for costum functions triggered when the click event is triggered or the input textfield for costum events when keyup is triggered for example.


Most of the infections come from computers where security is poorly managed so the autorun feature isn't disabled.

Moreover, USB devices are inherently insecure as their firwmare can be rewritten for malicious intent.
From SRLabs BadUSB:

  Reprogramming USB peripherals: To turn one device type into another,
  USB controller chips in peripherals need to be reprogrammed. Very
  widely spread USB controller chips, including those in thumb drives,
  have no protection from such reprogramming.

  (...) Once reprogrammed, benign devices can
  turn malicious in many ways, including:

  1) A device can emulate a keyboard and issue commands on behalf of the logged-in user, for example to exfiltrate files or install
  malware. Such malware, in turn, can infect the controller chips of
  other USB devices connected to the computer.

  2) The device can also spoof a network card and change the computer’s DNS setting to redirect traffic.

  3) A modified thumb drive or external hard disk can – when it detects that the computer is starting up – boot a small virus, which infects
  the computer’s operating system prior to boot.

  Defenses? No effective defenses from USB attacks are known. Malware
  scanners cannot access the firmware running on USB devices. Behavioral
  detection is difficult since behavior of an infected device may look
  as though a user has simply plugged in a new device. Blocking or
  allowing specific USB device classes and device IDs is possible,
  however generic lists can easily be bypassed. Pre-boot attacks may be
  prevented by use of a BIOS password and booting only to the hard
  drive.

  To make matters worse, cleanup after an incident is hard: Simply
  reinstalling the operating system – the standard response to otherwise
  ineradicable malware – does not address BadUSB infections at their
  root. The USB thumb drive, from which the operating system is
  reinstalled, may already be infected, as may the hardwired webcam or
  other USB components inside the computer. A BadUSB device may even
  have replaced the computer’s BIOS – again by emulating a keyboard and
  unlocking a hidden file on the USB thumb drive.

  Once infected, computers and their USB peripherals can never be
  trusted again.


you can use -Wl,-z,norelro to disable RELRO.


Is there a security benefit to be found in using a virtual machine if the host is infected?

There are multiple theoretical situations where your actions in a Virtual Machine would be hidden from garden-variety malware. For example, banking trojans wouldn't know how to inject themselves into your browser that's running in the virtual machine. Although in theory malware can record your screen in HD, usually they don't want to play babysitter.

Additionally, Windows 10 has a feature called Credential Guard that leverages virtualization to protect a certain type of secret key, even if the computer is infected.

Windows Server 2016 also has a feature called Shielded VMs.

However these are edge cases with their own debates about the scope of what they address. For all intents and purposes, in the real world if the host machine is infected, all attached virtual machines should be considered compromised as well.


Why Bitlocker requires partition on some computers but not all

I've never seen that behavior, and this is just a guess, but: BitLocker replaces the NTFS partition header (volume boot sector) with its own metadata, which contains the information needed to decrypt the disk (if a valid key is supplied), and also points to the "real" boot sector within the encrypted volume. The BitLocker metadata is also replicated across the volume in additional locations for redundancy, in space that NTFS marks as allocated but does not use for any files. As such, turning on BitLocker requires reserving some space on various parts of the partition, and it might be picky about what parts those changes are made to. It's possible that, for some reason, some of the changes that need to be made near the start of the volume could not be made (because files were currently in use), so BitLocker created a new partition from free space at the end of the volume and put some of its metadata there.

That doesn't explain it needing 852 MB, though; not sure what's up with that. The BL or NTFS volume metadata needs to fit on a boot sector, which is generally only 4 KB. I suppose it could be a copy of the NTFS Master File Table or something, but in that case I'd expect it to be encrypted too (and also the MFT needs to be accessed frequently, so putting it on a separate partition on the same physical storage doesn't make a lot of sense).

My other guess would be that it's additional OEM recovery / OS restore data, based both on the partition type and the approximate size. That doesn't make sense for one computer to have and the other not to, though, unless they were imaged differently (or the additional OEM / OS recovery data was deleted off one of them); I don't know how sure you are that the software / stored data on each machine is identical, vs. just the hardware and OS image.


What damage can a MITM do to encrypted traffic, and what can be done about it?

Assuming the encryption is properly implemented and the key isn't compromised, all an MITM attacker can achieve by changing the data is turning it into unpredictable garbage. When A and B do any form of plausibility checking on the data, they should notice that.

So what can the attacker do?

Suppress the communication completely by simply filtering it all
Turn the communication into nonsense by making some random changes (countermeasure: Add a hash to each message to detect and discard damaged messages)
Insert even more nonsense into the communication hoping to deplete resources (DOS attack)
Re-send previously observed message ("replay attack"). Even if they couldn't understand a message, if they observed that sending a specific message caused something to happen, sending the exact same message again might cause the same thing to happen again (countermeasure: Add a timestamp to each message and discard messages which are too old. The timestamp should be included in calculating the hash).
Create a copy of the cyphertext in case they somehow manage to obtain the encryption key in the future.


Yes, this is feasible, but you will need to study intensively.

I have some recommendations that may help in learning this material:

Learn about TCP/IP.  I recommend TCP/IP Illustrated, by Stevens, but any other network book may be a fine alternative.  Anotehr useful textbook may be Computer Networking: A Top-Down Approach by Kurose and Ross.  Make sure to learn about how things like IP, TCP, UDP, DNS, HTTP, DHCP, and ARP work.
Learn about firewalls.  I recommend Firewalls and Internet Security by Cheswick, Bellovin, and Rubin.  This is an outstanding book that will teach you about more than just firewalls.  In the process of learning about firewalls from these authors, you will also learn how to think like a security expert, and you will learn a variety of security risks associated with computer networks.
Learn how to configure a firewall.  I recommend learning how to set up a IPTables firewall.  Don't just read about it; install Linux on your machine and write the IPTables firewall rules to build your own firewall.  Experiment and learn how to do it yourself.  This kind of hands-on knowledge will be very valuable.
Learn how to use Wireshark.  Spend some time analyzing packet capture dumps and reading through them to understand everything you see.  Play around.  This will give you some great hands-on knowledge.
Learn about how HTTPS (SSL/TLS) works.  There are many sources that explain it well.
Learn about the Kaminsky attack on DNS.  It is educational.  I recommend these two articles: Reliable DNS Forgery in 2008: Kaminsky’s Discovery and An Illustrated Guide to the Kaminsky DNS Vulnerability.
Learn about network intrusion detection systems (NIDS).  They are a good tool to know about.
Read Steve Bellovin's paper A look back at Security Problems in the TCP/IP Protocol Suite.


If you do not have an internal Cybersecurity resource, you can hire a Managed Security Service Provider (MSSP) or you can use free resources provided by the Cybersecurity & Infrastructure Security Agency (CISA) which will help report on potential vulnerabilities.


Why is data quality important for privacy?

It allows to build a history. When I got five different datasets about you from five different sources which list three different addresses, I know that you seem to be someone who moves a lot, which can have various reasons. When I can pinpoint that a while ago your last name changed and shortly afterwards your address changed as well, it tells me you either married or got divorced. So I will spam you either with household items or dating sites.

It gives me more material to link datasets together. When I have one dataset from you with an outdated telephone number and another old dataset which is anonymous except for the same outdated telephone number, I can link them to each other.

It also allows identity theft in cases where personal information is used to identify you. For example, you might have some old email account you don't use anymore. When I would hack that account somehow, you wouldn't even notice. But maybe there are still some websites where you have accounts bound to that old email account. I could now use the "forgot password" function of these websites to take over your accounts.

However I still agree that less data is better than more and that one should generally avoid to have more data about them in some databases than strictly necessary.


Assuming the spam comments are to blog posts or similar...configure a CAPTCHA so that a successful response to the challenge is required prior to a comment being posted or a contact form being submitted. It should reduce the number of automated responses.

CAPTCHA modules are available for most web software packages.

More about CAPTCHAs here.


How is a Digital signature of a X.509 generated?

... which part of the certificate to hash ... Does x.509 have a standard or do they just hash everything in the certificate?

It's all defined in RFC 5280. In section 4.1.1.3. you will find:

  4.1.1.3.  signatureValue The signatureValue field contains a digital signature computed upon
     the ASN.1 DER encoded tbsCertificate.

And to find out what this tbsCertificate is continue reading with section 4.1.2:

  4.1.2.  TBSCertificate
     The sequence TBSCertificate contains information associated with the
     subject of the certificate and the CA that issued it.  Every
     TBSCertificate contains the names of the subject and issuer, a public
     key associated with the subject, a validity period, a version number,
     and a serial number; some MAY contain optional unique identifier
     fields.....

The certificate itself is then the tbsCertificate, the signatureAlgorithm and the signature. Or in a more formally defined way at page 116:

Certificate  ::=  SEQUENCE  {
     tbsCertificate       TBSCertificate,
     signatureAlgorithm   AlgorithmIdentifier,
     signature            BIT STRING  }

TBSCertificate  ::=  SEQUENCE  {
     version         [0]  Version DEFAULT v1,
     serialNumber         CertificateSerialNumber,
     signature            AlgorithmIdentifier,
     issuer               Name,
     validity             Validity,
     subject              Name,
     ...


How is the exchange of tls on email servers?

Do all email servers (also different providers) that implement tls, use tls to encrypt the messages and headers?

Usage of TLS in transporting email does not encrypt the email itself the same as use of TLS in HTTP does not encrypt the request and the response specifically. Instead the underlying connection is encrypted, either from start (smtps, port 465) or after a STARTTLS command (smtp, port 25). By encrypting the underlying connections everything inside this connections gets protected, which include in case of SMTP the mail but also the SMTP commands for authorization, specification of sender and receiver etc.

  ... and how to find out if a server does implement tls?

You can connect to the server and speak the SMTP protocol, issue a EHLO request and check if the response contains the information that the server supports the STARTTLS command:

$ telnet aspmx.l.google.com 25
220 mx.google.com ESMTP b48si10559063wrb.307 - gsmtp
ehlo myhost
250-mx.google.com at your service
...
250-STARTTLS

But note that contrary to the use of TLS for HTTP (i.e. HTTPS) TLS in SMTP does not provide an end-to-end encryption from sender to recipient but only a hop-by-hop encryption between the mail transfer agents (MTA). Thus you only find out from this that a specific MTA supports TLS and not that all the hops on the way to a specific recipient do it. Also each hop has the mail in clear text, i.e. only the transport between the hops is protected with TLS.

  Could the missing of tls-encryption be a sign of ssl-downgrading ...

There are some firewalls which strip STARTTLS from the response and thus cause the client to not use TLS.


Under what circumstances is my website vulnerable to clickjacking?

By default, any new website is probably vulnerable to Clickjacking, depending on the webserver defaults.

For defense against it, you should set HTTP-Response-Headers, as the OWASP Clickjacking Defense Cheat Sheet recommends. Another valuable and more concise ressource is Wikipedia:

Disallow embedding: All iframes etc. will be blank, or contain a browser specific error page.

  Content-Security-Policy: frame-ancestors 'none'

  X-Frame-Options: deny

Allow embedding of own content only:

  Content-Security-Policy: frame-ancestors 'self'

  X-Frame-Options: sameorigin

Allow specific origins to embed this content :

  Content-Security-Policy: frame-ancestors www.example.com www.wikipedia.org

  X-Frame-Options: ALLOW-FROM www.example.com www.wikipedia.org

Most examples start with a malicious website, because an attacker will require this malicious website for his attack on your vulnerable website: He can simply create his own evil.com website, containing an iframe of your victim.org.

As long as victim.org does not prevent the attacker from doing so, victim.org will remain vulnerable to Clickjacking.


Best way to validate /etc/hosts from third party providers to avoid ads?

You might also want to allow for blank lines. But, "starts with #, 127., blank-line" should be sufficient if trying to validate 3rd party lists for inclusion in yours. Though this wouldn't stop malicious denial of service. For example, if you started performing this as a service, but then somebody placed your own domain name in the list with a 127.0.0.1.

Also,

A loopback address is not always 127.0.0.1 . I've seen some of these custom hosts files also use 127.0.0.2 or other 127.0.0.* addresses. RFC 3330 defines loopback as any 127.0.0.0/8 address.

Also, this may not directly apply, but IPv6 localhost values such as 0:0:0:0:0:0:0:1 or ::1 are also valid.

Redirecting a site such a gmail would already be somewhat mitigated by the use of SSL certificates along with HTTP Strict Transport Security which tells a browser to only use SSL to connect to a site.


Is my Data Loss Prevention approach missing something obvious?

The most likely weakness is in how you identify a file's "type".

A file's extension is ambiguous: ".dat", for example, can be any of thousands of file types.  Many file formats are "PKZip"-style compressed archives containing the real data, so you can't use naive content sniffing (eg. it's hard to distinguish a Java JAR, an Word docX, and a PKZip archive).  Even advanced content sniffing has edge cases that make it hard to get right (you can append a zip file to a JPEG to get a file that is valid in both formats).

Edit: The other thing you're missing is the analog hole.

So a user can't copy and paste credit card information from a Word document to an email, and they can't attach the document to the email.  Nothing is preventing them from re-typing the document in the body of the email.


The data in the cert is hashed and the hash is sighed with C's private key. C's public key is in the cert. All of this is hashed and signed by a CA's key. Changing the subject changes the hash, the new cert is bad without even verifying the first signature.


Buffer Overflow memory address calculation on 64bit

If you fimilar with gdb and can control rip, then you are one step away from the solution.

Let's make a small example

void main() {
  char* buff = "asdf";
}

compile it

$ gcc test.c

and then use debugger

$ gdb a.out
 (gdb) set disassembly-flavor intel
(gdb) disassemble main
Dump of assembler code for function main:
 0x00000000004004d6 <+0>:   push   rbp
 0x00000000004004d7 <+1>:   mov    rbp,rsp
 0x00000000004004da <+4>:   mov    QWORD PTR [rbp-0x8],0x400574
 0x00000000004004e2 <+12>:  nop
 0x00000000004004e3 <+13>:  pop    rbp
 0x00000000004004e4 <+14>:  ret
End of assembler dump.

So our variable buff is at rbp-0x8 on the stack. If ASLR disabled - the address is always the same. You can get it with:

(gdb) break *0x00000000004004e2
Breakpoint 1 at 0x4004e2
(gdb) r
Starting program: ./a.out
Breakpoint 1, 0x00000000004004e2 in main ()
(gdb) p $rbp-0x8
$1 = (void *) 0x7fffffffdbd8


How to protect myself from future fraud?

What you need to do is learn the tricks of the trade. What likely happened was your card was read by a "Skimmer" and then re-programmed on another card. Many Credit Card Companies make gift cards that look very similar to a real credit card, which makes life easier for a would be thief as finding a legit looking credit card has become much easier.

Your best lines of defense are as follows

Learn to look for and spot card skimmers (on ATM's and employees who you hand your card to feeding it through a cash register)
Only pay with a security chip enabled card
Don't ever leave your credit card unattended (don't give it to a waitress to charge your meal to - ensure they bring the machine to you)
Protect your PIN at all costs


TL;DR

A JWT, if used without Cookies, negates the need for a CSRF token - BUT! by  storing JWT in session/localStorage, your expose your JWT and user's identity if your site has an XSS vulnerability (fairly common). It is better to add a csrfToken key to the JWT and store the JWT in a cookie with secure and http-only attributes set.

Read this article with a good description for more info
https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage

  You can make this CSRF protection stateless by including a xsrfToken JWT claim:

  {
    "iss": "http://galaxies.com",
    "exp": 1300819380,
    "scopes": ["explorer", "solar-harvester", "seller"],
    "sub": "tom@andromeda.com",
    "xsrfToken": "d9b9714c-7ac0-42e0-8696-2dae95dbc33e"
  }

So you will need to store the csrfToken in local/sessionStorage as well as inside the JWT (which is stored in a http-only and secure cookie). Then for csrf protection, verify that the csrf token in the JWT matches the submitted csrf-token header.


How are alternative operating systems even possible to load on a mobile device?

For a trusted boot (or authenticated boot or secure boot or however you want to call it), you need a root of trust that's protected for integrity. It doesn't need to be a “super-secret” sector, it needs to be a “super-shielded” sector. ROM fits the bill.

In practice, device manufacturers like to put as little code as possible in the ROM, because they don't want to stop updating the code a few months before the device ships. So that code typically does nothing more than initialize a few core devices (e.g. put the MMU into shape), load the first few sectors from a storage medium, verify their cryptographic signature against a public key stored in ROM, and transfer execution to that code. If the signature doesn't match, the ROM code may allow the user to upload an alternate boot image (typically over USB).

That first non-ROM boot code is often considerably more complex than the ROM code: it usually needs to know how to manage memory, access various storage devices, perhaps read filesystems, have at least a rudimentary user interface and so on. So, in practice, all that code buggy, and that (or later in the boot chain) is how iPhones get jailbroken. Some manufacturers, such as Apple, are indeed deeply concerned with controlling the boot image; that doesn't mean they succeed against a determined community.

Furthermore, even if the signed boot image has held, the operating system itself is far too complex to withstand attacks for very long. Signing the whole OS is not practical as users of all but the most basic mobile phones and PDAs expect to be able to install their own applications (and OSes tend to have root holes). The OS can typically do pretty much what it wants, except that if it naively overwrites the boot image, the device won't boot. If you want to run a different operating system, you may be able to use the original OS as a jumping point from which you boot your real operating system.

Speed is another factor: verifying the authenticity of a 100kB bootloader is just a blip on a modern smartphone, but verifying the authenticity or the integrity of a multi-GB operating system is too slow to do at once. Incremental verification also slows down disk reads, and requires filesystem support that isn't widely available at this time.


is it possible to execute an executable file as the owner rather than current user

Not really sure what you're asking. When you execute programs, they run as you. You can su them to run as another user, but you have to become the other user first (ie you have to know their password).

I think the scenario you are describing is that a file is created by the user victim with the following permissions:

-rwxrwxrwx 1 victim victim exec_file

and you want user to be able to execute the file and have it run as victim.

victim could use setuid to set the special bit of the executable like this:

victim$ chmod u+s exec_file
victim$ ls
-rwsrwxrwx 1 victim victim exec_file

Now when user runs the file, it will run as victim. This is not a vulnerability or an attack since victim explicitly set it up this way.

You might think that the following would work:

user$ ls
-rwxrwxrwx 1 user user exec_file
user$ chmod u+s exec_file
user$ chown victim exec_file
user$ ./execfile  # I'm victim now, right?

but linux will prevent you from doing the chown unless you sudo it, ... but if you have sudo powers already, then this isn't really much of an attack.

The closest thing I can think of to making this an actual attack is if multiple users run this program on a regular basis, and you have write permissions on it, then you can replace it with your own code and wait for the owner (or anybody else) to come back and run it. Now somebody else is running your malicious code as themself. In general, bad idea to give users write permission over files that other users will execute. Far better to have it like this:

-rwxr-xr-x 1 user user exec_file

or even better:

-rwxr-xr-x 1 root root exec_file


First of all, DNS tunneling typically leverages the fact that DNS traffic is not usually monitored.

So, to (give or take) effectively handle DNS tunneling these are required:

Payload analysis (high-level view at a DNS query itself)
Traffic analysis (stateful analysis i.e. keeping a track of multiple request/response of DNS queries)

There are a bunch of other things to add to that (entropy measurement in a DNS query, et cetera) as well. You can refer to the SANS documentation.

The idea is to stop a machine from being compromised at all in the first place. An unaccounted/unknown compromised machine in a network is a big problem.

As it will be off-topic, I will skip what organizations typically do to avoid getting into this situation in the first place.

For what it is worth, due to the same reason, a definite protection against a reverse shell is very difficult. Pattern/Traffic analysis (with or without SSL stripping) is the way to go for this, again.


Create a SSL certificate and sign it with a personal certificate which in turn is signed by a certificate authority

Depends on the value of the Certificate Basic Constraints field of your certificate. Most probably it will be  Is not a Certification Authority. However, you can get a CA type certificate which is allowed to issue more certificates. The main CAs (top level) have certificates with the value of Certificate Basic Constraints of the form

Is a Certification Authority
Maximum number of intermediate CAs: unlimited

Sometimes, you see certificates of the form

Is a Certification Authority
Maximum number of intermediate CAs: 0

which means that they can issue certificates, but they can't issue certificates which can issue certificates. In other words, they can only issue certificates of the Is not a Certification Authority type. For example, Google signs each of its subdomains separately using such a certificate.

You can also find

Is a Certification Authority
Maximum number of intermediate CAs: 1

which means that they can issue certificates of the Is not a Certification Authority and certificates of the Maximum number of intermediate CAs: 0 type.

Check with your CA to see if you can get an Is a Certification Authority certificate.


Can IP address be a component of 2-factor authentication?

I would think of an IP address as being "somewhere you are" rather than any of the traditional "something you know", "something you have" and "something you are" that are part of 3-factor authentication.

Although IP addresses are trivial to spoof, TCP connections are not and SSH is a protocol built on top of TCP.  The IP address of a TCP connection is a reliable indicator of who you are directly connected to.

Let's say I limit SSH connections to just my office IP address, an attacker is going to have to do one of:

Be in or near (if he cracks the wireless) my office
Be on the path between my office and my server (say inside our ISP).
Control a machine within my office.

Point 3. allows the attacker to be anywhere in the world but it increases the difficulty of an attack.

Points 1. and 2. significantly reduce the number of people who can successfully use the other factors (such as your SSH key or password) if they manage to acquire them and hence I see it as being worthwhile.

The quality of the IP address is a big factor here.  I used my office as the example above but if you have a dynamic IP address, do you trust the entire range your ISP owns?  How does that affect how easy it is for an attacker to get one of those IP addresses?  Does the trustworthiness of an IP address change when you know there are 10 machines hidden by NAT behind it?  What if there are 2,000 machines and 100 wireless access points?

I would not consider an IP address to be a factor on its own.


Strange devices & open ports on my network

The above result is of my modem, the thing that is strange about it is
  that it has port 23 & 992 open.

These are probably ports to internally manage it, see if you can connect to it using telnet/ssh/putty and login with the credentials you have; but probably baked in into the firmware, and potentially with credentials that are specific to the device manufacturer.

The web interface on home devices (which I assume this is), is often for non-expert users to manage the device without many chances to break it.  There's no rule that every interface has to be manageable over the web interface.  Lookup your device online and see if there's any way to log into it; and configure these services.

A quick google for your device:

"The default user name for the Verizon MI424WR router is "admin," and the default password is "password"

  I do have the option to open these ports, but they are unchecked.
  Which means it should be closed. So how can I close these ports?

That's usually to allow ingress traffic; i.e - where you open a port on your WAN interface to be forwarded to an internal host.  This allows you to run services and make them accessible on the Internet.

  [..snip...] The above scan is a device that I do not know where it is
  physically? It also has some very suspicious ports open? How can I
  identify this device? Should I try to kick it off my network?

If you don't have WIFI, run a ping on this IP and try to unplug each device sequentially and see when it stops responding.  Looking at the DNS reverse looking (Cisco Spvgt), it may be an extra IP address that your modem has. Note that IP addresses are just based on IP stacks and not physical interfaces.

  Another scan that I cannot post currently, has an open port '12345
  Netbus'? Is this some type of malware? The device is an android TV
  box.

No, it's a service running on that port.  You can run any service on that port if you want.  NetBUS used to be known RAT that was using that port, and possibly the most known one.  Telnet to us, run Amap, or so - to see what is running.

THC's Amap may help you out more to see what protocol is behind these ports.


How to calculate CVSS of an attack so that it matches those in CVEs?

I would go with the CVSS calculator from the NIST which you can find here http://nvd.nist.gov/cvss.cfm?calculator&adv&version=2

If the vulnerability can be exploited over a non-adjacent network, and the Access Complexity is Low, and the attacker needs to authenticate multiple times you have

AN:N, AC:L, Au:M

No impact on the Confidentiality and Integrity while a complete impact on the availability gives

C:N, I:N, A:C

will give the following scores

Base-Score: 6.1
Base-Impact: 6.9
Exploitability: 6.4

and an overall score of

6.1

makes it a major vulnerability. You can further calculate the Temporal and Environmental scores on the NIST page.


On a very abstract level: malware on each victim's machine in addition to encrypted AES keys used to encrypt the files, stores an encrypted copy of the private key required to decrypt them. This copy itself is encrypted with the public key of the attacker and can be decrypted with the attacker's private key (called "master key" in the article).

I will try to rephrase Kaspersky's article TeslaCrypt 2.0 disguised as CryptoWall in a more verbose way.

For the sake of simplicity I will skip the fact that each file can be encoded with different AES key. Also actual implementation might differ (particularly more data can be sent to the attacker and some steps are performed on the attacker's side). Anyway the answer aims to explain how the master password-scheme works:

At first victim has only attacker-public-key (embedded in the malware).
Attacker has attacker-private-key.

malware creates a new BTC address with a victim1-BTC-public-key (to send BTC) and a BTC-private-key (to withdraw BTC)
malware uses attacker-public-key and and victim1-BTC-private-key as the input to ECDH which generates an encryption-key-1
malware XORs victim1-BTC-private-key with the encryption-key-1, stores the result as encrypted-victim1-BTC-private-key, forgets encryption-key-1
malware sends the victim1-BTC-private-key to the attacker and deletes it

Victim owns: attacker-public-key, victim1-BTC-public-key, encrypted-victim1-BTC-private-key.
Attacker owns: attacker-private-key, victim1-BTC-private-key.

Next malware starts to encrypt files:

malware generates a key-pair and uses the private key as AES encryption key, so the pair consists of victim1-AES-key (victim1-keypair-private-key) and victim1-keypair-public-key
malware uses the victim1-BTC-public-key and victim1-AES-key as an input to ECDH which generates an encryption-key-2
malware XORs AES-key with the encryption-key-2, stores the result as encrypted-AES-key, forgets encryption-key-2

Victim owns: attacker-public-key, victim1-BTC-public-key, encrypted-victim1-BTC-private-key, victim1-keypair-public-key, encrypted-victim1-AES-key.
Attacker owns: attacker-private-key, BTC-victim1-private-key.

Now victim paid the ransom and attacker releases a key to decrypt the files:

attacker reveals BTC-victim1-private-key
malware uses BTC-victim1-private-key and victim1-keypair-public-key as an input to ECDH which calculates encryption-key-2 (the same as above)
malware XORs encrypted-victim1-AES-key with the encryption-key-2 which gives victim1-AES-key
malware decrypts the file(s) with victim1-AES-key

No other victim can do anything using BTC-victim1-private-key.

Attacker decides to release the master key:

attacker reveals the attacker-private-key
malware uses attacker-private-key and victim1-BTC-public-key as the input to ECDH which generates an encryption-key-1 (the same as above)
malware XORs encrypted-victim1-BTC-private-key with the encryption-key-1, stores the result as victim1-BTC-private-key
malware uses BTC-victim1-private-key and victim1-keypair-public-key as an input to ECDH which calculates encryption-key-2
malware XORs encrypted-victim1-AES-key with the encryption-key-2 which gives victim1-AES-key
malware decrypts the file(s) with victim1-AES-key

In the latter scenario any victim can use the attacker-private-key first to derive the victim*-BTC-private-key then victim*-AES-key.


How would anyone ever break even this basic, amateurish cipher/encryption scheme?

First of all, how would anyone ever be able to tell that the letters
  are all nonsensical and not used for anything other than separating
  the numbers?

It requires an intuitive leap.  The cryptographer, reviewing the data for patterns, will note that there are certain numeric tuples that repeat regardless of the alphabetic character.  Once they break the frequency counts out to consider the numeric tuples separately from the characters, it becomes intuitively obvious that the characters are filler.

Additionally, if the coder is 'randomly' selecting the character to insert, it won't be random.  You'd need a computer to pick characters with anything regarding true randomness, and you already destroyed your computer in step 3.

  And even if they did, what do the numbers mean?

Again, frequency counts.  How often does each numeric tuple repeat?  Make a graph.  What language is most likely being encoded?  English?  Okay, then assume the most common tuple is an 't'.  Second most common is an 'o'.  Decrypt as if those are true and see if any textual patterns arise.  Not getting patterns?  Shake them up and try 'o' first and 't' second, is that any better?  Repeat the process until the cleartext shakes out.

  They have no way of knowing this unless they have a copy of our sheet
  which only exists in two copies in the world and was generated by an
  offline computer which is now physically destroyed.

No, it can be inferred from the cipher text.  Your system is essentially a monoalphabetic cipher, one of the easiest to crack.

  And, what if to further complicate everything, we decide to write the
  messages in reverse? Or to do every other look-up in reverse, so that
  the columns and rows are swapped every other character? With just a
  few simple rules like that, it seems like they could never, ever
  decrypt our messages, even with the most powerful computers in the
  world.

You're still describing a substitution cipher, which are demonstrably fallible.  You might try to read about the career of Elizebeth Friedman, who broke codes like that used by organized crime and the Germans in the 30s and 40s.

  I probably am making a fool out of myself here, but I seriously don't
  understand how anyone, no matter how smart, given unlimited time,
  could ever break this cipher/encryption scheme which I just came up
  with quickly without having any expertise in the field.

That is such a common problem we have a rule describing it; Schneier's Law:

"Anyone, from the most clueless amateur to the best cryptographer, can create an algorithm that he himself can't break."


Yes, an SSH tunnel will provide the same confidentiality and integrity as an OpenVPN or IPSec VPN tunnel, assuming the configuration is secure. If you expect an active MITM attack, you will need to verify that the SSH fingerprint that you are seeing is correct. If you have set up the server, you should take a note of the fingerprint so you can verify that it is correct when you connect to the server.


How do OTT providers protect LIVE streams?

So to support Live Stream and requirement that only logged-in users are allowed, the database of the users is needed. This also means there's need for registration.

To allow only registered users to view the live stream, you need your own website with user registration, and then you need a media server or CDN which will check with your web site if token (cookie) is valid.

The below scheme is in its simplest form. Normally there's dedicated "Key Server" as with typical encryption system. Additionally the stream is also encrypted and the key server is not only checking your username / password or token but if the content owner allows you to play the stream. It would also send you the decryption key (or the license, depends on the technology used).

Most media servers and CDNs support this. With HTTP servers can have custom authentication module.

If you look for technology which can do all of that look at Kaltura, they got free version as well.

Regarding HLS and DASH streams, ideally it would be:

CDN service which checks the tokens with your Key Server (because main app server is not the one you want to query because of performance, the Key Server must have cache of tokens or dedicated scalable database).
Your media server can have simple plugin to check for tokens
Your HTTPd server can have custom module to check for the tokens

In case of DASH and HLS you have 1. metadata files (like m3u8 or manifests) and media fragments. All fragments are usually encoded with single AES key and the key is normally stored in the meta-data files. It's quite different for DASH as there can be optional key server.

So the solution for HLS is for example to send Cookie to every possible request and then check for that Cookie. HTTPD server has to have cache of this stuff. You could extend this method to DASH however they provide  more decent mechanisms.

The current technology to protect content:

Most live streams are using Flash Access (as flash is major platform for live stream delivery)
There's Widevine by Google which is slowly being adopted (Android)
Microsoft Playready
W3C EME
Custom token-based authentication in simplest form - and that's not a technology but a way of integration.


As ott mentioned & let me reinforce it: Use a VPN! Especially for email sign in and banking. It's best to use it for any login activities. A traveller named Nomadic Matt wrote a couple of good articles to help you pick out which is the best for you:

Everything You Need To Know About VPNs for Travel (HINT: if you are traveling with a phone and a laptop, choose a provider that supports multiple devices)

The No-Nonsense Guide to Data Security for Travelers

Other things to do:

I personally bring a couple of small new storage USB drives (>4GB) as throw aways in case I have to print from at an internet cafe. In foreign countries, these computers can be riddled with viruses.
Have a PIN code on your mobile devices. If it supports swipe, it has been shown that grease prints make it fairly easy to re-create your pattern. Also turn on feature to wipe after a limited number of incorrect attempts.
Make sure you are using encryption on your phone (SD card included) and full-disk encryption for your computer. Have these devices turned off when entering the country and passing through customs (beware that you may be asked to turn on and decrypt).
Consider limiting the data that you take to the country. If you don't need it, leave it at home with your back-ups.
Phone theft (esp. these nice shiny expensive smartphones we have) can be common depending on the areas you are visiting. Have a remote wiping application enabled on your phone. I wouldn't put too much hope in the tracking feature as some countries do not have resources to "track down the phone of a tourist" they might have bigger fish to fry.
Get the correct plug adapter (whatplug.info shows G,D & M)) and do not charge from USB stations like you may do in American airports.
Turn on two factor authentication methods for email and banking during your trip. You could have these warnings forwarded to a service like Google Voice (free).
Keep Wi-Fi and cell service off (airplane mode) when not using it to avoid connections.

A more thorough checklist is provided here by and article in Security Magazine. This list may seem like overkill but depending on your job and the type of data you carry (read: the stakeholders of that data) they may be more essential.

Have a great trip!


I know it's not the most straightforward, but:

hping3 -q --scan 1-1000 -S 192.168.0.1 | grep -v 'Not res'


As Terry said in the comments, you can test out nmap on scanme.nmap.org, which is designed for exactly this.

You could also set up a machine in a VM, or on Amazon EC2 for testing, with various services and firewall configurations, in order to see how nmap's results change depending on your OS and configuration.