This is article 6, lawfulness of processing:

  Processing shall be lawful only if and to the extent that at least one of the following applies:

  the data subject has given consent to the processing of his or her personal data for one or more specific purposes;
  processing is necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract;
  processing is necessary for compliance with a legal obligation to which the controller is subject;
  processing is necessary in order to protect the vital interests of the data subject or of another natural person;
  processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller;
  processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child.

See also the following article (article 25, data protection by design and by default):

  Taking into account the state of the art, the cost of implementation and the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for rights and freedoms of natural persons posed by the processing, the controller shall, both at the time of the determination of the means for processing and at the time of the processing itself, implement appropriate technical and organisational measures, such as pseudonymisation, which are designed to implement data-protection principles, such as data minimisation, in an effective manner and to integrate the necessary safeguards into the processing in order to meet the requirements of this Regulation and protect the rights of data subjects.
  The controller shall implement appropriate technical and organisational measures for ensuring that, by default, only personal data which are necessary for each specific purpose of the processing are processed.That obligation applies to the amount of personal data collected, the extent of their processing, the period of their storage and their accessibility. In particular, such measures shall ensure that by default personal data are not made accessible without the individual’s intervention to an indefinite number of natural persons.

And article 28 defines "data processors", which are companies that process data on behalf of a controller. There must be a particular contract between these two parties, here's a little quote:

  Processing by a processor shall be governed by a contract or other legal act under Union or Member State law, that is binding on the processor with regard to the controller and that sets out the subject-matter and duration of the processing, the nature and purpose of the processing, the type of personal data and categories of data subjects and the obligations and rights of the controller. That contract or other legal act shall stipulate, in particular, that the processor [...]

What does this mean in practice? My personal interpretation (IANAL) is that it's ok to share data on Google Drive provided that:

sharing CV data with other employees must be necessary, or the data subject can reasonably expect such data to be shared in that way. For example, if it's only shared between office workers, and you only have one office with three employees working next to each other, I don't think this can be a problem. On the other hand, if you are sharing data between hundreds of employees (in different offices, different locations, for different tasks, etc.) then accessing CV data is none of their business.
Google Drive has provided a DPA (Data processing agreement) that is compliant with article 28 and the GDPR in general, because Google will be processing personal data on your behalf. You need to check this carefully, because I'm not sure Google is compliant for their free services. The last time I checked, only business services (paid versions of their free services) had settings that could be configured to make the service compliant with GDPR and had privacy policies that contained a section for DPA agreements.

My opinion is that just asking the user for consent will not work in this case, because unnecessarily sharing CV data this way just seems a matter of careless organization, rather than a meaningful reason for processing. All it takes to fix this issue is protecting some files with a password, or sharing a folder only with certain accounts.


Why don’t SMTP servers just require all senders to be authenticated before accepting mail?

Laziness mostly. Ease of configuration, it's easier for administrators to setup a central SMTP server which doesn't require authentication to send email, than one that does.

You will often see that this is also offered by ISPs to accomodate their clients more easily.


Risks of photographing sensitive information using Android devices?

Is it completely safe to do with a smartphone

"Completely safe" is a myth.

  or can there be security threats?

The security threats depends upon what application you got installed on the phone and other varying factors too.

  This makes me think of if there could be security risks or surveillance threats.

You need to look into processes and connections, and examine the data in transit to affirm the claim.

  Is there any additional risk if the phone is Chinese-originated?

Most chips are manufactured in China. There are speculations that the Chinese government asked companies to embedded smartphone chips with obfuscated monitoring microchips, but some deny it. Please check your own model and make OR consider buying a trusted device examined earlier.


What is the message called someone sends to verify a key?

While there may be other names, calling it a challenge seems appropriate. From the challenge-response Wikipedia page:

  In computer security, challenge-response authentication is a family of
  protocols in which one party presents a question ("challenge") and
  another party must provide a valid answer ("response") to be
  authenticated.

Later on the article goes on to describe the symmetric encryption version of the situation you mention:

  One way this is done involves using the password as the encryption key
  to transmit some randomly generated information as the challenge,
  whereupon the other end must return as its response a similarly
  encrypted value which is some predetermined function of the originally
  offered information, thus proving that it was able to decrypt the
  challenge. For instance, in Kerberos, the challenge is an encrypted
  integer N, while the response is the encrypted integer N + 1, proving
  that the other end was able to decrypt the integer N.


Given a hash value, is it possible to determine the length of the
  initial string that was digested? (SHA256)

No. The result is always a fixed length output in the case of SHA256, regardless of input length. Therefore there is no way to know the original length from looking at the output. The hash function is designed so no knowledge of the original input can be determined.

  Also, given two hash values, is it possible to determine if either one
  of them was a result of digesting a larger string?

No, for the same reasons as above.

  As far as I understand SHA256, nothing but guessing the string itself helps.

Remember that different input strings can, and do, result in the same hash digest (the output).


Where to find papers / information about spyware, tracking and cookie problems?

Here are some papers that I enjoyed and think are worth reading:

Flash Cookies and Privacy II: Now with HTML5 and ETag Respawning, by Mika Ayenson, Dietrich James Wambach, Ashkan Soltani, Nathan Good, and Chris Jay Hoofnagle. 2011.

Flash Cookies and Privacy, by Ashkan Soltani, Shannon Canty, Quentin Mayo, Lauren Thomas, and Chris Jay Hoofnagle.  August 2009.

A Crawler-based Study of Spyware on the Web, by Alexander Moshchuk, Tanya Bragin, Steven D. Gribble, and Henry M. Levy. Proceedings of the 13th Annual Network and Distributed Systems Security Symposium (NDSS 2006), San Diego, CA, February 2006.

Behavior-based Spyware Detection, by Engin Kirda, Christopher KruegelGreg Banks, Giovanni Vigna, and Richard Kemmerer.  15th Usenix Security Symposium, August 2006.

An Empirical Study of Privacy-Violating Information Flows in JavaScript Web Applications, by Dongseok Jang, Ranjit Jhala, Sorin Lerner, and Hovav Shacham.  CCS 2010.

SpyProxy: Execution-based Detection of Malicious Web Content, by Alexander Moshchuk, Tanya Bragin, Damien Deville, Steven D. Gribble, and Henry M. Levy. Proceedings of the 16th USENIX Security Symposium (USENIX Security 2007), Boston, MA, August 2007.

Measurement and Analysis of Spyware in a University Environment, by Stefan Saroiu, Steven D. Gribble, and Henry M. Levy. Proceedings of the First Symposium on Networked Systems Design and Implementation (NSDI '04), San Francisco, California, March 2004.

Automated Spyware Collection and Analysis, by Andreas Stamminger, Christopher Kruegel, Giovanni Vigna, and Engin Kirda.  12th Information Security Conference (ISC), Lecture Notes in Computer Science, Springer Verlag, Italy, September 2009.

Dynamic Spyware Analysis, by Manuel Egele, Christopher Kruegel, Engin Kirda, Heng Yin, and Dawn Song.  Usenix Annual Technical Conference, USA, June 2007.

Do Not Track: http://donottrack.us/.

An Analysis of Private Browsing Modes in Modern Browsers, by Gaurav Aggarwal, Elie Bursztein, Dan Boneh, and Collin Jackson. USENIX Security 2010.

Fingerprinting Information in JavaScript Implementations, by Keaton Mowery, Dillon Bogenreif, Scott Yilek, and Hovav Shacham.  W2SP 2011.

Timing Attacks on Web Privacy, by Edward W. Felten and Michael A. Schneider. Proc. of 7th ACM Conference on Computer and Communications Security, Nov. 2000.

RequestPolicy: Increasing Web Browsing Privacy through Control of Cross-Site Requests, by Justin Samuel and Beichuan Zhang. PETS 2009.

What Californians Understand about Privacy Online, by Chris Jay Hoofnagle and Jennifer King.  September 2008.

Americans Reject Tailored Advertising and Three Activities that Enable It, by Joseph Turow, Jennifer King, Chris Jay Hoofnagle, Amy Bleakley, Michael Hennessy.  September 2009.

Cookies and Web Browser Design: Toward Realizing Informed Consent Online, by Lynette I. Millett, Batya Friedman, and Edward W. Felten. Proc. of CHI 2001 Conference on Human Factors in Computing Systems, April 2001.

Informed Consent in the Mozilla Browser: Implementing Value-Sensitive Design, by Batya Friedman, Daniel C. Howe, and Edward W. Felten. Proc. of 35th Annual Hawaii International Conference on System Sciences, January 2002.

Adnostic: Privacy-Preserving Targeted Advertising, by Vincent Toubiana, Arvind Narayanan, Dan Boneh, Helen Nissenbaum, Solon Barocas. NDSS 2010.

I Still Know What You Visited Last Summer: Leaking browsing history via user interaction and side channel attacks, by Zack Weinberg, Eric Chen, Pavithra Ramesh Jayaraman, and Collin Jackson. IEEE Security and Privacy Symposium 2011.

This should be enough to get you started.  I recommend using standard literature search methods.  For instance, read the related work sections of these papers to see if they identify/cite other papers worth reading.  Then, plug each paper into Google Scholar to find what newer papers cite them, and see if any of those are interesting.  Keep expanding your pool in this way.  If there are any researchers who have written multiple papers you really liked, check out all of their publications.  Look at the proceedings of PETS, WEIS, and SOUPS, as they may have more that is of interest to you.

P.S. I also want to point you to an excellent blog by a leading researcher that you might enjoy, 33bits.org.  Check out especially these topics on that blog: ubercookies, history stealing, tracking.


What is more safe: 3g/4g or public wifi?

If John have both options, which one should he choose, and why?

This depends on your threat model. Modern public hotspots do not use encryption or authentication whatsoever, allowing absolutely anyone with basic consumer hardware to sniff and modify unencrypted traffic. Cellular networks, on the other hand, do use encryption and at least a certain level of mutual authentication. Attacking it requires specialized hardware and often specialized cryptographic knowledge. While it may be possible to break 3G and 4G encryption, it's going to be far harder than just setting up Wireshark on a public network, which can be done on pretty much any laptop.

However, cellular networks are also very long-range, meaning that the data, potentially encrypted only weakly, is traveling very long distances. Compare this to Wi-Fi where the effective distance is quite limited. In fact, due to latency requirements in the protocol, there is a hard limit for active connections enforced by the speed of light. Passive monitoring must also be done locally due to the relatively low-power wireless transmissions made by Wi-Fi routers and computer wireless cards.

Overall, if your adversary, positioned on the airwaves with a transmitter and receiver with the intent of monitoring your wireless traffic, is local and unsophisticated, then Wi-Fi is dangerous. If your adversary is remote and sophisticated, then cellular networks are more dangerous. Note that WPA3, an upcoming encryption feature for Wi-Fi, will allow public networks to provide encryption even without a password.

  And what precautions should he have (tools are permited)?

Use of a VPN to a trusted endpoint will protect from any relevant wireless attacks. A VPN creates an encrypted tunnel between you and a server, and that server connects to the websites you visit on your behalf. While VPNs are often advertised (incorrectly) as anonymity tools, they are actually only useful in this scenario for encryption. A VPN will ensure that an attacker who is able to monitor your wireless traffic will not see what sites you visit or the data you send to or receive from said sites. If you do not wish to pay for a commercial VPN or configure one yourself, Tor is a free alternative.

Assuming it's not possible to use any kind of encrypted tunnel, the next best thing is to only connect to websites that use TLS (HTTPS sites). Someone monitoring your wireless traffic will be able to see the website you connect to, but not what page on that website you are visiting, nor what you upload.

  is there some sort of infection that spread by just being in the same network of a infected device?

It is possible in theory, and vulnerabilities in Wi-Fi chips have been found that allow for remote arbitrary code execution, but they are unlikely to be used as an infection vector for a worm. It is more likely to be used by a sophisticated attacker targeting one or a few specific individuals. If the Wi-Fi chip itself is compromised, it can often (but not always) compromise the computer's operating system. This can be partially mitigated by enabling an IOMMU. I believe Windows does this by default, to a limited extent. On Linux with an Intel CPU, you can enable this by adding intel_iommu=on to your boot parameters.


How can I allow only authorized browsers to access a website?

There's a very interesting use case in this other answer, using client-side certificates:

Why would the BBC web site always ask for a personal certificate, and how do I avoid giving it away?

Another quick-and-dirty option might be implementing a VPN and shifting the domain of the problem from PHP to system administration. This might prove useful if, in the future, you need to give access not only to a website, but also to other resources such as shared folders, etc.


Do my Android apps use TLS or other encryption when connected to public Wifi? How can I tell?

The encryption and authentication inherent to the 3G network protect you only within the infrastructure of the 3G provider, but not beyond. If you do a plain unencrypted HTTP connection with your phone, the data is unprotected once if gets outside of the provider's network, and enters the Internet at large, where wild beasts roam. If an app is sending unprotected private data, you have a problem, regardless of whether the sending goes first through WiFi or through 3G. The WiFi just makes the problem more locally obvious.

To get an idea of how things are handled on your phone, you may run a packet capture application, just like you could do with a PC. It will probably needs the phone to be rooted, though. Moreover, even if the capture shows an SSL/TLS session, you still do not know how the client authenticates the server certificate (in particular, what root certificates are accepted by the application, and how it matches the certificate with the intended server name), so you cannot gain full assurance that a random app does things properly.

There is nothing in the OS which enforces use of TLS; but at least a reasonably good TLS client is provided, and most app which want to do some SSL/TLS will actually use HTTPS, for which the default implementation does things in a reasonably sane way (just like a Web browser). So we can say that an app developer who uses SSL/TLS but botches it must have been inordinately creative in his sloppiness.


Removing remnants of a Metasploit exploit

Meterpreter never touches the disk. So until you don't do anything deliberately that changes resources on the hard drive and leave evidence, chances are there will be no evidence on the disk. However, this is not so simple. OS can transfer pages from memory to disk when the system is low on memory. Although meterpreter reflective loader code specifically requests the OS not to flush the page to the disk where the meterpreter process is hosted, it's only a process request which can be ignored by the OS.

I am not going to explain the network part since it is out of scope here but a lot of times evidence is gathered from the network logs as well. SSL won't provide any benefit if it is intercepted in the middle (you have the option of certificate pinning in the stager code) but the bottom line is if you are concerned about forensics, make sure you are covered on all sides.


Is it possible to create a hardware 'Plug and Play' TOR proxy?

You could also use a travel router which supports openwrt, in most cases they have enough space to install tor. There are also cheap single board computers with two ethernet connections.
What you are looking for is called a transparent proxy:
https://trac.torproject.org/projects/tor/wiki/doc/TransparentProxy
It boils down to installing and configuring tor, enable forwarding and some iptables stuff.
Security:
There might be leaks. Also you maybe don't want to tunnel all of your traffic through tor. Tor itself has its problems too ... Depends on your threat model and why you actually want to use tor.


Could an attacker prevent IIS from logging requests

You will not see the payload in the logs If the attacks were sent via a POST, as opposed to a GET.


Terms for input/output to and from a Firewall

Maybe you are thinking of:

Ingress which indicates inbound flow, for instance flows coming from Internet to your LAN/DMZ,
Egress which indicates outbound flow, for instance flow leaving your LAN toward the Internet.

These will be handled in quite a different way regarding your firewall policy.

If you are just referring to data coming to the firewall itself to be analyzed (no matter the origin) and the accepted data that the firewall let pass out, then as far as I know it is just as you said in the title: input and output flow, as it would be for any other kind of network device.


Does your company have an IT team? If so the best thing to do is get them to do it or you could risk losing your internship. If not the next best thing if possible is to do a clean install of the operating system. If that's not possible try this out:

From a clean machine download the latest MalwareBytes and
AVG and CCleaner and put those installers on a thumbdrive
Boot the infected machine into safe mode. This is usually accomplished by pressing F5 while the machine is booting.
I usually run CCleaner then MalwareBytes then AVG but I don't think the order matters just run them and get all of the crud off of there.
After that boot into windows normally, if there are any definition updates for malwarebytes or avg download them.
Run all 3 again.

When you boot into safe mode windows will only load what's necessary to run, more likely than not the malware won't start in safe mode. You may also want to check the below registry keys. If any of the entries have a * next to the name it will start in safe mode. However I would caution you to stay away from the registry if you don't know what you're doing because you could really mess stuff up in there and in 90% of cases I have dealt with the malware doesn't start in safemode.

•HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
•HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
•HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce
•HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce

If you're STILL getting those ads look at the url and place an entry in your hosts file to send that url to 127.0.0.1. Here are directions on how to edit your hosts file.

Hope this helps and good luck!


Should I take care of mysql credentials?

It is very good that the mysql server is not required to support remote connections because it greatly reduces the attackable surface.

But you should consider defence in depth as a strategy to slow down an attacker or even reduce the impact of an attack.

Setting up a good password for the database users is no significant amount of work, so you should do that. That same is true for permissions that are likely not needed such as executing shell commands or creating stored procedures.

Fine tuning the permissions of the database users might be more difficult. So it might be more effective to spend effort elsewhere first. For example reviewing a web application for SQL injection vulnerabilities.


Certificate identification that is renewal safe

Your certificate must be identified at least using his Common Name (CN), or at best using his Distinguished Name (DN).

The Distinguished Name is based upon X.500 directory service standard, and is actually a hierarchical set of property/value couples allowing a unique identification of a given certificate, independently of technical certificate properties (key, usages, serial number, validity period, issuer, etc.).

For instance, the Distinguished Name from the current Stack Exchange website is C = US, ST = CA, L = San Francisco, O = "CloudFlare, Inc.", CN = *.stackexchange.com, which can be decomposed the following way to clearly see the hierarchical relation between each properties (it goes from the more general to the more precise):

C = US                       // Country = United States
ST = CA                      // State = California
L = San Francisco            // Locality = San Francisco
O = "CloudFlare, Inc."       // Organization = CloudFlare, Inc
CN = *.stackexchange.com     // Common Name = matches the URL hostname

The details of the attributes composing your certificate will heavily depend on your application and needs (some attributes may even appear several times with different values, the most common example being the OU (Organization Unit) attribute).

Do not hesitate to check the other question given in the beginning of this answer to get more information on the subject.


Is it safe to serve any user uploaded file under only white-listed MIME content types?

HTML content-sniffing, as outlined by Krzysztof; primarily but not exclusively IE.
jar: URL vulnerability in older Firefox
Content resembling a JAR file (GIFAR et al) - hosting something that could be interpreted as a Java archive implies XSS because of the different Same Origin Policy enforced by Java.
A file containing something that looks a bit like crossdomain.xml content can be targeted by loadPolicyFile call to get XSS for a Flash caller.

  Should I assert the files being uploaded have magic bytes matching the client provided mime type?

Insufficient against chameleons (files equally valid as either type).

  What is the solution to make this secure?

The only strong mitigation is to serve your untrusted uploaded content from a different hostname from your main site.

That different hostname can be a subdomain of your main site if you are only worried about direct JavaScript XSS/Same Origin Policy.
It must be a disjoint subdomain if you need to prevent it from reading cookies (such as session IDs). That is, it can be insecure.example.com if you have your main site on www.example.com, but in that case you must not also allow your site to respond on bare ‘example.com’. example.com cookies can't be prevented from inheriting into insecure.example.com on IE. Best practice: redirect all access to example.com to www.example.com.
It must be a completely different domain if you need to prevent cookie forcing: that is, insecure.example.com can write a cookie that will be read by www.example.com, potentially overriding cookies set by www.example.com. This is a less severe vulnerability: the ability to read the cookies typically leads to session hijacking, whereas cookie forcing leads only to denial of service (as www.example.com won't work without its cookies).
It must also be served on a different IP address, if you are concerned with a preventing cookie-stealing using a vulnerability in older Java plugins, or if you have other services running on ports which you would not want applets to be able to access.

Between them, browsers and plugins have made hosting uploaded files securely a terrible ordeal.


Here is some links that may help you:

https://vizsec.org/data/

http://www.fukuda-lab.org/mawilab/data.html

https://mcfp.felk.cvut.cz/publicDatasets/

On the other hand, consider datasets from 1999 is not going to be very useful unless you are testing the stability of your system, but for detection/classification I don't think will help from my point of view


Is the security of a VPN client on a Virtual Machine decreased?

It is very hard to say whether or not using a VM is more secure. As you are referring to technicalities, please take a look at this page written by the maintainers of Tails (a well known Linux distribution for anonymity via TOR). These warnings apply to every VM, not only Tails.

On one hand utilizing compartmentalization can add security, however this added layer also means an extra attack vector. If you are sloppy with running patches, might have downloaded some software from weird places, having your little brother using your PC as well, etc, these things might make you vulnerable, using a VM or not. And even worse, it might have you end up with not one but two compromised systems.

If you think you can be a good 'host' for your VM, go for it as I think the risks are low (now that I made you aware of those). If you require even more security, then you probably better of using a dedicated computer for these events.


In GSM is it correct to say A8 uses the random generated by the Auc and Ki to generate Kc?

The referenced presentation describes how the protocol works.

The A3 algorithm is used for authentication and A8 for key derivation. They both take as input:

A random 128 bits number challenge
Ki a 128 bits private key (included in the SIM and known by the network)

A3 outputs a 32 bits response. And A8 a 64 bits Kc cipher key that will be used for A5 algorithm.

As both inputs can be known to the base station and the subscriber's device, there is no need to forward Kc to anyone. It's computed on the spot.


Using the mobile phone as single authentication factor would be very bad.

  The mobile phone number is being used by gmail as the optional second-factor authentication

The import part here is "second-factor". It sound like you are proposing to use the mobile as a single authentication factor. That would be very bad because mobile phone are not secure. If your device get compromised the attacker would also get access to your webpage.

Like on normal computer there are many ways to attack a phone. Think about remote exploit or an evil app. If you lose your phone it even worse. If you did not fully encrypt the device your lock screen would not protect you. Even with encryption the attacker could brute force the password.

Anyway using the mobile phone as second-factor is a good idea but it can not replace a password.

By the way: biometric passwords are bad because mostly you can copy them very easy and you have big trouble changing them.

Update in response to the comment: Password manager vs one time password via mobile phone

Mobile phones and password managers are very different. One is a mostly bad protected device that is very likely to be lost, while the other is an encrypted file on a device.

You could intercept the one time password while it's send to the device (SMS is not encrypted). HTTPS might be broken. Phone numbers can be highjacked and routed to other devices. You would need to authenticate your phone to the website.

Assume you have done that and you fully encrypted your phones with a strong password. Now it's like a password manager? Nope. Phones are mostly turned on even if lost, so you can recover the encryption key from RAM.


On the ability to reverse engineer the Instagram Private API

Yes, once you release an application, you have no control over what people do with it. You can obfuscate or pre-process code to make it harder to find things out, but by definition, it needs to be executable and accessible to the underlying processor. Given enough time and effort, someone can always find out anything that is embedded in the application. This applies to any type of application - mobile app, desktop app, console app. If all else fails, a really determined attacker could emulate the processor and dump out what happens.

No, but the attack methods change. Taking the Instagram example, if you have a web app, communications can be sent over an encrypted channel, but they might not be able to control the source of communications. It would be difficult to distinguish between the legitimate app and a third party one. For some businesses, this is important (for example, if they show adverts in their official app). On the other hand, with a mobile app, it would be possible to provide, for example, certificate verification, where the server and client mutually verify each other. In this case, it would be possible to remove a compromised certificate on the server side, although this might cut off users who haven't updated their apps.
In the first case, attacks would concentrate on identifying valid calls to the backend system, and then attempting to abuse that. In the second case, attacks would initially try to extract the certificate, but in that process would probably find the calls.


OAuth - How does the Resource Server validate the access token is not for any other Resource Server?

You can also use JSON Web Token (JWT) (https://tools.ietf.org/html/rfc7523).

The JWT includes an "aud" parameter to specify the audience of the issued token.
Resources servces must check the signature of the token and the data it contains.

See https://tools.ietf.org/html/rfc7523#section-3

Another solution would be to associate a resource server to the access token by creating a new property (containing a name or url or the client_id to identify your authorized "resource server").
 Then checking this parameter depends on how the communication between your authorization server and your resource servers works.


Is there a secure way to create and distribute Shamir Secrets?

There is no such thing as a one-dimensional scale of security which would allow to rate all or even most scenarios as low, medium or high security. Every scenario has context, requirements, goals, and overall an attack model.

In any case, Shamir's Secret Sharing is "perfect", in that it is one of the very few algorithms which offer unconditional security: even infinitely powerful computers could not break the features offered by that scheme.

What are these features ? Namely:

The algorithm works in a finite field K. Practical implementations use GF(256), i.e. bytes.
Let m be a sequence of elements of K (i.e., some bytes).
Let n be the "number of shares" and t the "threshold" such that n ≥ t ≥ 1.
The algorithm produces n "shares", where each share is a sequence of elements of K of the same length as m. The shares are such that any subset of t shares is sufficient to efficiently rebuild m; but any subset of t-1 shares yields no information whatsoever on m (except, of course, its length).

Regardless of its perfection, the algorithm is only for transit: at the time the shares are produced, the value m exists as a whole in some physical system; and when the value m must be rebuilt, it is rebuilt: it again exists as a whole in some other physical system. The splitting operates only between these two points in space-time. It is sufficient for some usages, some of which being possibly "high security"; I have used it, for instance, to split a backup copy of a master key in a smart card management system (the master key does exist in a specific system; the backup was done to be able to recover from a catastrophic loss such as a flood or fire).

No algorithm does everything. There are scenarios where the security features of Shamir's Secret Sharing do not match that which is needed. In a context of "shares" and "threshold", there are, for instance, group signatures: this is meant for situations where digital signatures must be produced, with no single entity being able to generate signatures on its own. But we also want this property to be maintained even if many signatures are produced. If you wanted to use Shamir's Secret Sharing for that, then you would split a normal signature private key, and rebuild it when signing, but this requires a "trusted system", both for key generation and key usage. That system would, transiently, acquire knowledge of the full key. If this is unacceptable to you, then you have to do something else, and that's what group signature algorithms are meant for. A group signature allows for a signature to be generated by the collective actions of sufficiently many key share owners, without the private key being disclosed to any of them, however dishonest he may be.

Group algorithms are inherently more restrictive than Shamir's Secret Sharing since they do not, by definition, rebuild the secret that was split; as such, they can only compute a specific function involving the secret (e.g. signature generation or asymmetric decryption). On the other hand, good group algorithms can avoid to some extent the need for a trusted system (many group signatures have honesty thresholds: if sufficiently many malicious key share owners cooperate with each other, they may gain some extra power).

Group algorithms are no more or no less secure than Shamir's Secret Sharing; they just do something else.


Could overlapping SHA256 hash begin to loop at some point?

My best understanding of your question is:

Given a hash, from a known hashing function, if I apply the hash to itself any number of times, shall I ever receive the same number again?

In that case the answer is "Possibly in a very,very,very,very long time depending on exactly what algorithm you use and how you use it."

A word about multi-hashing

At any rate, in a password context (which I realize is not your context) you wouldn't want to simply apply the same hash again and again blindly without understanding some deeper ramifications. In the case of passwords, you want to a iterative hashing solution that adds work to slow down crackers.

https://stackoverflow.com/questions/348109/is-double-hashing-a-password-less-secure-than-just-hashing-it-once

My advice to you

For the purposes of a card game it might make more sense to simply encrypt the clients cards, send them to the server, and send the results back to the user. In your system (as I understand it) logic pertaining to the win state is conducted in the client, which can be manipulated.

Instead, just ensure that there a secure connection between the client and the server, and do all the logic on the server side. Perhaps convoluted hashing set ups for online betting like this were made before the ubiquitous use of https.

What I think you are trying to do

I think the reason you providing the client the hash is so that you can provide some form of assurance that the game isn't rigged. You are trying to implement something like the below:

http://cseweb.ucsd.edu/~aauyoung/projects/cse207project.pdf

However, to accomplish this for a game like poker, you will have to develop a complex and will audited cryptographic system, which (while assuring the fairness of the game to a theorist) might do little to assure fairness to non technical user.

If you provide provide more information about what you are attempting to do, I'll do my best to update the answer.


Techniques to find out the domain a given name server resolves for

If your looking for all the DNS names that are served on a particular IP Address you can use http://www.ip-neighbors.com/ or recon-ng has some modules for IP enumeration as well.

As a last resort, if you have the client's FQDN, run Fierce or another DNS brute-forcing tool and cross reference your results.


SSL/TLS has a slight overhead. When Google switched Gmail to HTTPS (from an optional feature to the default setting), they found out that CPU overhead was about +1%, and network overhead +2%; see this text for details. However, this is for Gmail, which consists of private, dynamic, non-shared data, and hosted on Google's systems, which are accessible from everywhere with very low latency. The main effects of HTTPS, as compared to HTTP, are:

Connection initiation requires some extra network roundtrips. Since such connections are "kept alive" and reused whenever possible, this extra latency is negligible when a given site is used with repeated interactions (as is typical with Gmail); systems which serve mostly static contents may find the network overhead to be non-negligible.
Proxy servers cannot cache pages served with HTTPS (since they do not even see those pages). There again, there is nothing static to cache with Gmail, but this is a very specific context. ISPs are extremely fond of caching since network bandwidth is their lifeforce.
HTTPS is HTTP within SSL/TLS. During the TLS handshake, the server shows its certificate, which must designate the intended server name -- and this occurs before the HTTP request itself is sent to the server. This prevents virtual hosting, unless a TLS extension known as Server Name Indication is used; this requires support from the client. In particular, Internet Explorer does not support Server Name Indication on Windows XP (IE 7.0 and later support it, but only on Vista and Win7). Given the current market share of desktop systems using WinXP, one cannot assume that "everybody" supports Server Name Indication. Instead, HTTPS servers must use one IP per server name; the current status of IPv6 deployment and IPv4 address shortage make this a problem.
HTTPS is "more secure" than HTTP in the following sense: the data is authenticated as coming from a named server, and the transfer is confidential with regards to whoever may eavesdrop on the line. This is a security model which does not make sense in many situations: for instance, when you look at a video from Youtube, you do not really care about whether the video really comes from youtube.com or from some hacker who (courteously) sends you the video you wish to see; and that video is public data anyway, so confidentiality is of low relevance here. Also, authentication is only done relatively to the server's certificate, which comes from a Certification Authority that the client browser knows of. Certificates are not free, since the point of certificates is that they involve physical identification of the certificate owner by the CA (I am not telling that commercial CA price their certificates fairly; but even the fairest of CA, operated by the Buddha himself, would still have to charge a fee for a certificate). Commercial CA would just love HTTPS to be "the default". Moreover, it is not clear whether the PKI model embodied by the X.509 certificates is really what is needed "by default" for the Internet at large (in particular when it comes to relationships between certificates and the DNS -- some argue that a server certificate should be issued by the registrar when the domain is created).
In many enterprise networks, HTTPS means that the data cannot be seen by eavesdroppers, and that category includes all kinds of content filters and antivirus software. Making HTTPS the default would make many system administrators very unhappy.

All of these are reasons why HTTPS is not necessarily a good idea as default protocol for the Web. However, they are not the reason why HTTPS is not, currently, the default protocol for the Web; HTTPS is not the default simply because HTTP was there first.


John the Ripper / Hashcat rule, reject candidate if char at position X is the same as character at position Y

You can make Hashcat output the list to stdout and pipe the output to a python script that filters it, then pipe the output to another instance of Hashcat (or John).

hashcat --stdout [list generation options] | python_filter | hashcat -a 0 -m HASH_TYPE HASH_FILE

I am not aware of rules in hashcat that would do this comparison, I hope this helps.


Does logging out also stops the hijacked session?

That depends on the server-side code. If the server deletes the session ID associated with your user ID, then the attacker will also be logged out. If, for some braindead reason, the Server only deletes your cookie (by expiring it) or purges the ID from the URL, then the attacker can still use your session.

If the server is a distributed system, the deletion of your session ID may take a while to reach all systems.

If the attacker has used the session to change your login credentials or reveal your passwords, then logging out will do you no good and can shut you out. Secure systems always ask for the password before revealing/changing login credentials, but not every system is that secure ...


How to i disguise my phone as a tablet/computer?

More manageable than link layer addresses is filtering on browser user agent, or something like p0f IIRC. You don't specify how/what is blocked. If it is browsing, go to about:config in firefox/similar, and create a new key called general.useragent.override . Try a value like 'Mozilla/1.0' - other user agent strings can be found with google. If it is something like p0f (passive OS fingerprinting) it can't be easily bypassed on a phone. Perhaps OpenVPN. If it is mac address you will need to root your phone (perhaps towelroot), install supersu, and either change it with ifconfig $radio hw ether 00:de:ad:be:ef:00 or some app from the play store. That is a mess. Don't root your device unless you are ok with a voided warranty.


Where can I find a list of frowned upon usernames for web sites?

This is really the wrong solution to the problem: trying to prohibit "administrator"-like names will become a constant game of whack-a-mole with increasingly creative impersonators.

A blacklist of official-sounding names can be a starting point, but you should also provide an easy way to positively identify admins, such as a unique naming pattern (only admins can register a username ending in "(admin)"), or displaying their names or messages in a unique color.


Is the ProtectedData class still an acceptable method to store passwords?

Yes, this is one of use cases that Protected Data (and the underlying DPAPI) was expressly designed for, and is generally probably the best mechanisms at your disposal.

One thing I'd add is that it's best to set the DataProtectionScope to CurrentUser, which will offer stronger protection, because the data isn't available to other users and processes on the machine as when the scope is set to LocalMachine.


How a VPN makes the effect of being physically in that private network?

It all depends on encapsulation and your point of reference.  Your understanding of a VPN is correct, but you are missing one technical aspect.  Once a VPN tunnel is created, you can send connections through that one and it acts like you're right there.  In most corporate VPN setups, the software used actually creates a virtual network adapter, that the operating system can use to communicate (much like "Ethernet" or "Wireless LAN", but instead would be called "VPN Adapter").  When your OS attempts to communicate over the network, it'll route your traffic through the VPN adapter which, because it's a "tunnel", shoots straight into your company's network and then goes from that point of reference.

The way this all works is through encapsulation.  The layers of protocols for networking allow for encapsulating data at different levels.  Ethernet protocol encapsulates IP, IP encapsulates TCP, TCP encapsulates your VPN data, which in turn encapsulates whatever other data it needs to send.  When a network communication is sent through the VPN virtual adapter, the traffic is the normal Ethernet[IP[TCP[HTTP]]] encapsulation scheme, but then gets additional encapsulation as it is sent over the VPN, resulting in Ethernet[IP[TCP[VPN[Ethernet[IP[TCP[HTTP]]]]]]].


Am I performing this encrypting scheme correctly?

You are performing a lot of unnecessary steps.

What you appear to want is to maintain encryption between Alice and Bob, but to use a 3rd party to verify that Alice is the sender.

You could accomplish this by:

Alice encrypts message with Bob's public key
Alice signs the message with Alice's private key (or send authentication token encrypted with Proxy's public key)
The Proxy receives and verifies the signature (or auth token) with Alice's public key
The Proxy strips the signature then passes it on to Bob.

That covers all your requirements more simply. One encryption. Sender verified. Sender remains anonymous to receiver.


Bash history won't help you against a semi-competent attacker in the usual case.

There's an alternative: The auditing subsystem. Install auditd and configure it, so it logs for example program executions and other things you configure. In basically logs the system calls that are made according to filters you have created.

Now, if you really want to depend on bash history, you can make it more secure: Recent bash versions can log to syslog instead of a local user file. Then, syslog can be redirected to a remote syslog server if that's imporant to you.


How to set iptables to drop packets that I'm not listening on?

If never seen this done without a script, so here is a baseline script for you to accomplish this:

checkht="lsof -c httpd | awk '{print $1}' | uniq | grep h"

if [ -n "$checkht" ]; then

    echo "webserver is running let me shut down uptables rules blocking HTTP"
    iptables -vnL --line-numbers |awk '/tcp dpt:80/{print "iptables -D INPUT "$1}' | sh

else

   iptables -A INPUT -s 0.0.0.0/0 -p tcp --dport 80 -j DROP

fi

Checks to see if http is running, if it is, it makes sure that IPTABLES has no rule blocking HTTP. If it's not running, it blocks the world from reaching that port. However, because you're not listening on the port, the rule to block makes little sense. There is nothing for anyone to attack since nothing is running.


Hashing sensitive data and checking for duplicates

"Secure" for file hashing is very different to "Secure" for password hashing.

When password hashing, you usually have a "small" string, like "password123". When someone is trying to break the password, they go through small strings and get longer until they find a "collision". Bcrypt and other "slower" choices help to slow down brute-forced password breaking, by making the algorithm more memory/CPU bound with a linear chain of hashing cycles so that GPU optimization doesn't give a significant speed boost.

For file hashing, unlike short password strings, the files are relatively huge. There's no practical way that files could be "brute-forced" to finding a collision. So an algorithm like bcrypt doesn't add any meaningful security benefit.

Therefore, SHA (and even MD5) are "secure" for file hashing. I would tend to choose a hashing algorithm that's CPU/Memory efficient and outputs a large hash string to reduce random chances of a collision with another file. A recent edition of SHA hashing algorithm is probably the best choice.

You might also transmit the length of the file along with the hash for further reduction of risk of a collision, however, that might not be valid for your situation, where revealing a file size could be saying too much.

(Note: I assume the communication of the file hashes occurs over an encrypted transport like TLS)

Looking at the other answer from kelalaka, it's a great answer, but I don't agree with a couple of points, so to clarify:

1)  I don't believe salt is necessary. That's for password hashing, and further slows down the possibility of creating a universal rainbow table. However, again, this is necessary because the password is so short.

2) I don't believe that any form of signing (HMAC) is necessary. For one, that makes hash comparison impossible. Usually a signature accompanies the file bytes, the verifier may hash the file themselves, then check the signature. But also, a hash is already secure enough to disquise the data in the file - that's what it does.


It's a tradeoff.  You're probably better off behind the VPN, but at a cost.

VPN will add a 2nd layer of authentication
VPN prevents unauthenticated attackers from attacking web app
VPN increases support burden
IPSec VPN doesn't traverse NAT well
VPN potentially makes things slower

Your webserver should already be in a DMZ.  Exposing a service to the internet that's on an internal (non-DMZ) network is a significant risk.

If you have users authenticate to the VPN, you should try to use some sort of single-sign-on solution so they don't have to authenticate to the app as well.  The idea of adding 2 sets of usernames/passwords to the app is just cruel to your users, and would offer very little security benefit (might actually encourage the use of weaker passwords, increases attack surface).


PCI Compilance - Custom payment processor

As a former PCI QSA, my opinion is no. With the detail available, it appears that Server A would be considered part of your card holder environment since credit card transactions are transfered through it via the POST.  In this situation, you would not be compliant with Requirement 6: Develop and maintain secure systems and applications, and Requirement 11: Regularly test security systems and processes.


Fuzzing tool to find heap overflows in a Windows binary

No fuzzing tool will scan a windows binary looking for vulnerabilities,  because that is not fuzzing!   There are dynamic or static analysis tools that can look at the code or a compiled binary to determine if it is vulnerable.  From experience all of these analysis tools produce tons of false posties and false negatives.

Using a fuzzing framework like Sulley or Peach you can test any interface for memory corruption vulnerabilities.  Both of these projects have great documentation and have been used to find many buffer overflows.

You will still have to define what interface you are fuzzing.  Are you fuzzing files?  Or a remote API?  The fuzzing framework comes with a testing harness to generate test cases and determine when the application crashes.


Are these merchant integration instructions wrong about server-client interaction?

At a glance, it looks like the instructions in the developers' guide are not so much wrong as simply misleading.  As you note, pretty much all the examples do show the sensitive ssl_merchant_id, ssl_user_id and ssl_pin fields embedded as hidden form fields in HTML code sent to the customer.  However, if you work your way all the way to chapter 9, "Transaction Security", you'll find the following paragraph under "Best Practice Tips" (boldface original, italics mine):

  "Server Side Code – Your users can read HTML source code from your Web pages when they are downloaded to their Web browser. Although our simple examples in the document show this as a method for passing data to VirtualMerchant, we do not recommend this for your production
  website. All sensitive merchant data, including transaction amounts and your VirtualMerchant
  credentials, should be placed in server side code, rather than in hidden value fields on an HTML form. This will reduce the ability of malicious users to exploit client browser vulnerability to edit and use this data for their own fraudulent purposes. If you are not knowledgeable enough to implement this on your own, there are quite a few shopping cart providers that inherently provide this service and are compatible with VirtualMerchant."

So, basically, it's a case of "do as I say, not as I (show you how to) do".

That said, it does seem to me that, if you follow all the other security recommendations carefully, passing the merchant/user ID and PIN to the customer may not be as bad as it might seem.  Done right, having those values should only give the customer access to a limited user account that only allows them to make payments to you — but that's what you're allowing them to do anyway, so it should be no big deal.

Of course, that only holds if you really can (and do) make the user account used for the form so limited that it's safe to hand out to customers.  Without further study, I can't really tell whether that's possible or not.


Blowfish... I feel younger. This is an algorithm from more than 15 years ago, which is not bad in itself, but the author of Blowfish itself (Bruce Schneier) proposed an enhanced version called Twofish, back in 1998, for the AES competition. That the product claims to be "the ultimate database solution" but neglects the last 15 years of science and technology, including the AES, is not a good sign.

If using the same password for distinct files yields the same "identifier", but a different password produces a different identifier, then this "identifier" can be used to attack the password with cost sharing -- in other words, a rainbow table. An attacker could go through the expense of building the table once, because he could then apply it to every instance of a file coming from that product. This is not a bad sign, this is a worse sign.

None of this means that the password could be trivially extracted from the files (none of this excludes this possibility either), but it is sufficient to recommend not using this product.


I have the solution.

I used the link of urlscan that wrote in the question and checked the HTTP tab.
I clicked on the show response button

https://urlscan.io/result/14f59032-94ab-4b39-b7ef-1c0d33bc02f7/

I checked the response on each request and see a pop cash script.

<script type="text/javascript" src="//cdn.popcash.net/pop.js"></script>

This feature is a legitimate advertising service that website publishers use to generate revenue on their sites.

There are some adware programs that are injecting these ads onto web sites you visit, show automatically pop-ups and do user redirection to third websites in order to generate revenue.

I found an unwanted program in the OS, after the program uninstallation the calls were stopped.


Is it a security risk to remind users of the password requirements at login?

If someone wants to crack the passwords for some of your site's users, then knowing the password rules may help him reduce his list of "potential passwords" by pruning out the passwords that the server would not have accepted in the first place. However, if:

the attacker can also register as a user (as is the case for many Web sites, where account creation is free);
the "registration page" already lists the password requirements;

then the attacker can be assumed to already have that information. Hence, it does not harm security to recall them on the login page.

Anyway, maintaining password requirements secret would be difficult, since they have been shown to all users. A secret which is shared by more than 3 or 4 persons is no longer a secret. So it can be assumed that the attacker already knows your password requirements, and displaying them on the login page gives him no extra advantage.

There is a risk that displaying the password requirements on the login page may confuse some users, because such requirements are usually displayed on registration pages, not login pages. You will have to be careful in your wording and presentation. Another possible usability issue is if you change the password requirements at some point, for new passwords: some old, but still valid passwords may fail to match the new requirements, and, there again, the corresponding users may be confused by the mismatch. Yet, these are not security issues (except that confused users are, generally speaking, a potential security hazard).


Who can carry out Man-in-the-Middle (MITM) attacks?

There are many more ways of performing a MitM attack:

Direct DNS hijacking - spoofing a DNS response to the client's DNS request for the target server, to point to an IP controlled by the attacker.
The "Dan Kaminsky DNS attack" (for lack of a better name) - spoofing a DNS response to a client trying to find the nameserver for a host, allowing the attacker to pose as the real nameserver.
Address Resolution Protocol (ARP) poisoning - flooding the target with fake ARP broadcasts, to trick it into thinking that the target server's IP points to the MAC address of the attacker's machine on the network.
Route protocol spoofing and other attacks against protocols like BGP, RIP, OSPF, etc.
Partial MitM via packet injection attacks (e.g. sniffing the network, then spoofing a packet so that its source address is that of the server, and the TCP sequence numbers match the expected values)
Spoofing a response to a proxy auto-config script (if the client has one set) to cause it to point to an attacker-controlled proxy on the network.
Compromising the target server's account with their domain provider to redirect it to an attacker-controlled IP, which can then act as a transparent proxy.
Rogue WiFi APs with common or popular names (e.g. "Starbucks" or "BT-OpenZone")
WiFi hijacking with devices such as the Hak5 WiFi Pineapple, whereby it pretends to be any AP that a user device searches for (i.e. "are you there?" "sure, connect to me!")
Compromising home routers (the standard SOHO stuff is garbage) to inject into the routing table, add a static DNS entry, etc.
Utilising router features such as UPnP to mess with the routing table.

And probably a hundred more others that I can't think of right now...


There used to be a Microsoft tool called Windows SteadyState which could be used to do that, but it is unsupported now.

However, Microsoft provides some alternatives that use Windows 7 technologies: see this document.

The only downside is that hard drive protection can not be recreated; a workaround could be creating a separate recovery partition and booting to it every time.
Yes, you could use the WAIK, prepare and customize a WinPE USB key, copy a "fresh" Windows 7 image on it and use it as needed to reimage the computer.

(Edit: as @Graham Hill pointed out, it is also possible to create a VM, take a snapshot and revert to it at every boot.)


Should digital forensics examiners avoid the term "evidence" outside legal proceedings?

The point at issue isn't so much a legal one as it is one of proper communication.

Most of the civilized world uses the word "evidence" to refer to signs of some particular activity or behavior or process. A dentist finds evidence of tooth decay, a home inspector finds evidence of rodents. The word in common usage is pretty broad.

But when talking to a lawyer, you say the word evidence, and she mentally appends "of criminal wrongdoing" without you putting the words there, because in her practice, that's what "evidence" always refers to.

So if, in analyzing a compromised system, you point out that there is some evidence of a failed login attempt at 7:35 UTC, she's possibly going to assume that you said there is evidence of an unauthorized break-in attempt at 7:35, when in reality you said no such thing. You simply said that someone tried to log in and failed, and you noticed that fact in the logs. The logs make no mention of whether or not that user had authorization to access the computer, and you have not done any additional follow-up work to determine whether that was the case.  That is, the facts you uncovered are not necessarily the sort of "evidence" she's after, and you don't want to suggest that you have already determined them to be relevant.

So to save both of you a lot of misunderstanding and potentially some serious embarrassment in the courtroom, you avoid the word "evidence" because it has a special meaning to her. This is the sort of advice that is borne out of frustrating experience, and not a bad idea to follow.

Whether the examiner will personally get into legal trouble in such am instance isn't clear, nor do I think that's necessarily the implication. But you could certainly spark a misunderstanding which could damage the case in court, and that's worth considering.


After performing a SSL strip, can you upgrade back to HTTPS with your own encryption from the proxy?

Unless the attacker is able to install a new certificate authority (CA) at the users system he can not make the client visit the original site by https through the attacker proxy without the client getting certificate warnings. And, installing a CA just from inside the browser without any explicit user interaction is not possible.

The attacker could though change the target URL's within an SSL stripping attack not only from https:// to http:// like the normal sslstrip program does but could keep https:// and instead change the site which gets visited. For example if the attacker owns example.org he could change the access from https://example.com to https://example.org and mirror the original site at his attackers site. Many users would probably not notice such change and happily fill in credentials and similar.


Dynamically assign and revoke MySQL user privileges

This is generally a very good practice and often employed by large enterprises.

For example, have a look at the security applied to operational staff working on Microsoft Office 365 & Azure. They have NO access to data at all. When they need to trouble-shoot something and need access, they have to follow a process whereby they request the access from their ops security team along with the reasons and timescale. They are given access for a very limited time.

Of course, you need to balance this approach with the overheads of managing it. To be successful in any organisation, you would need to be able to automate the request/access process. That brings its own risks which you would offset using monitored audit logs.


Some systems do use alpha one time password. S/Key or the less old OpieKey are example of them
For OTP systems using hardware calculators, the price of the hardware matters, and digital displays able to display only digits are cheaper than ones able to display letters
The OTP is generally computed as a mere number (ie a sequence of bits). It can then be represented as a decimal integer (only digits), an hexa integer (0-9 + A-F), encoded in base64 (alphanumeric ASCII), or in a any other encoding. The already cited S/Key used a number of 4 letter words.


First I ask is there an aboslute definition?

Is there an absolute definition of anything these days? You will find most definitions for XSS say the same thing in the end. XSS is essentially injecting malicious scripts through un-sanitized user input.

Have a look at these two animations:
XSS Animation 1 and
XSS Animation 2

This sounds similar to a SQL injection but it attacks the web server, not the user?

XSS scripts are generally executed in the clients browser and attacks the user (I'm not saying it cannot be detrimental to the server as well)

Again it sounds like someone would mess with the URL to put malicious code into GET passed variables but wouldn't this be like attacking one's self?

You could share the unsafe URL with others who use the website. Maybe it is as simple as a facebook link that results in the person sending all of their personal information to you.

It implies XSS is done usually with JavaScript, is this true?

Yes. For example: enter this into a sites form,
<script>alert('xss');</script>
. If you see an alert with xss, the site is vulnerable. From there you are limited by your imagination and expertise.

Myspace was a bloodbath in regards to XSS. Look up the Sammy worm. It will surprise you how many people/companies ignore XSS (and security in general). I worked for a company where you could easily write a simple XSS worm that would erase all of the users data (on the website), and subsequently delete all of their contacts data as well, thus eventually deleting everyones data. This involved calling the applications API on behalf of the user within JS.  General rule, never trust user input.


RFC 4306 is not the current official reference for IKEv2, RFC 7296 is. Right in the introduction it states:

  Every request requires a
     response.  An INFORMATIONAL request with no payloads (other than the
     empty Encrypted payload required by the syntax) is commonly used as a
     check for liveness.

Then in section 1.4 it defines the following for INFORMATIONAL exchanges:

  The request
     message in an INFORMATIONAL exchange MAY also contain no payloads.
     This is the expected way an endpoint can ask the other endpoint to
     verify that it is alive.

And in section 2.4 it says the following:

  To check whether the other side is alive, IKE
     specifies an empty INFORMATIONAL request that (like all IKE requests)
     requires an acknowledgement (note that within the context of an IKE
     SA, an "empty" message consists of an IKE header followed by an
     Encrypted payload that contains no payloads).

And in the same section a bit later:

  If no
     cryptographically protected messages have been received on an IKE SA
     or any of its Child SAs recently, the system needs to perform a
     liveness check in order to prevent sending messages to a dead peer.
     (This is sometimes called "dead peer detection" or "DPD", although it
     is really detecting live peers, not dead ones.)


Understanding the signing and verification process through a CA

Now my question is; since every CA has its own public key, and the
  client is verifying against that CA, and not directly with my public
  key, how is the link between the CA's public key and my own public key
  (which is signed with that CA) made? Is this linking function done
  internally by the CA?

The certificate issued by the CA that contains your public key is signed with the issuing CAs public key. When you present this certificate to the client it must validate that the CAs signature is valid and comes from a valid CA (among other things).

If the CA is an intermediate CA then in turn the cert containing it's public key is signed by a CA higher up in the chain, continuing in the same manner until a root CA is reached. When a client validates your cert, in turn it validates all the intermediate CAs up to a root CA.

Edit: As Jenny D pointed out, the issuing CA will provide the chain back to the root CA if it is an intermediate CA. You can see this chain (e.g. in Safari) when you inspect a certificate for a website (in this case for google). (Google Internet Authority G2 being the issuing CA and GeoTrust Global CA being the root CA).


First and foremost,  XSS is an output problem - one which almost always affects the server's output, and is therefore patched on the server. XSS allows for an attacker to inject JavaScript, which is used to hijack the browser and perform any action as the victim.

The only viable client-side XSS mitigation is having a strict content-security policy (CSP) which disallows inline injections. The CSP is a set of server-defined rules that are enforced by the browser and is used to limit the execution of JavaScript. The CSP is a new and very powerful tool for shutting down XSS.

Another common approach to client-side XSS mitigation is to use AngularJS templates. A secure template language like AngularJS will mitigate XSS by neutralizing executable code which was intended to be displayed as text.  This is a great approach to developing secure applications. However an application that uses AngularJS cannot protect against API calls that are vulnerable to XSS, only the CSP can do that.

AngularJS + CSP will make an application very difficult to exploit with XSS, but nothing is 100%. There is still the possibility of DOM based XSS and Cross-site attacks in Flash, which are both very similar to each-other.  There is no blanket mitigation here, not even a Web Application Firewall (WAF) can stop these attacks - they are perfect and widespread.


How would you reason with and work with the security paranoiac on your team?

Consider the usual risk management statement:

  Don't spend 1000$ to protect 100$

Now, it might just be a situation that the execs are not aware that what they want will cost 1000$; more likely that they just don't realize that they're only protecting 100$ worth.

If that is the case, you could consider trying to implement methodology that will provide some hard numbers, to replace the vague feeling of uneasiness that can accompany the fear of the big scary word "SECURITY".
If they want to be fiscally responsible, they should try to understand the actual costs, risks, and benefits. I would even try to have that discussion with them without using the word security, which just seems to be confusing and irritating them.

It is also likely that, since they dont understand it, they're worried about doing their due diligence, and/or can be held responsible (either personally or corporately) if anything goes wrong. They need to be shown how to do this effectively, and yet still be "good enough" - not to never be hacked, but to make it a fair tradeoff. Even if they do get hacked, they need plausible proof of having done their diligence, so as not to have their reputation damaged (or other similar fallouts).

I recommend using FAIR , which is a quantitative methodology for putting a price tag on specific risks.
Also see: "How do you compare risks...?"

Either way, this should enable you to change the conversation from the soft, prickly, uneasy feeling of "security", to a hard talk about costs, benefit, and money. Always bring it back to showing them the money.

Worst case, if nothing else works out, put together an expensive, phased, multi-year plan. Have it prioritize the important things, as you see them, and delay to later years the issues that you would have preferred to forgo.
In most orgs, the later stuff will never get done anyway.
And even if it does, this way, you're still getting them to do the right stuff, and they're spending money on the feeling of security - which, sometimes, is important too.

Best part is, since it is in phases, you can build into the plan a re-adjustment step, between phases. Use this as a platform for a full security lifecycle... You can keep re-adjusting the unimportant phases as needed, to squeeze in other important bits.


Firmware is code. It executes on the CPU on behalf of some hardware device; or it executes on the device directly.

In general, if your own hardware is intent on spying on you, then you lose. A more worrying development is that many pieces of hardware (e.g. keyboards) contain a completely honest firmware that is upgradeable, and some malware has been spotted in the wild which replaces some firmwares (using the "upgradeable" feature) with malicious code.

The biggest firmware of all is called the BIOS; it is the code which runs first when the computer boots up, before the operating system is loaded (and, indeed, the BIOS is responsible for loading the OS). Malware installed in the BIOS itself resists, by definition, complete reformat-and-reinstall of the operating system. The CIH virus, better known as "Chernobyl virus", was already muddling with the BIOS back in 1998 (but it was doing so rather inexpertly, resulting in a mangled BIOS, not a stealthily infected BIOS). More recent virus will install in a non-destructive way, and persist.

The BIOS is not the only piece of reflashable firmware in a computer, so the possibilities are large.

To write a firmware-installable virus, you need to do some reverse-engineering on the hardware and firmware format. It seems that attackers do that. Open-source firmwares would technically make such reverse-engineering easier, but would also help the "defenders" who look for security vulnerabilities that they can fix. It is the classical Open-source / closed-source security debate which has been ongoing for quite some time and has not reached any sort of definitive conclusion yet.

The call for "declarative-only firmware" is a bit misguided, though. The idea is that no piece of hardware should come with specific code to be executed on the CPU; instead, such code should be in the operating system driver. This fails to take into account the whole situation, in two main ways:

A machine must be able to boot up in order to actually load the OS and the drivers, so there must still be some firmware somewhere (namely, the BIOS) who knows how to access the hard disk.
Many peripheral devices have their own CPU. This includes of course GPU, but all network interfaces, keyboards... and, for them, it makes no real sense to call for a "declarative-only firmware" since the code is meant for the device CPU anyway, not for the main CPU, and the OS never sees it. A keylogger inserted into the firmware for an Apple keyboard has been demonstrated.

Generic workarounds:

Work only with hardware from "trustworthy sources" with strict internal security procedures (in particular background checks on employees) so that chances are that the firmware is initially clean and honest.
Make it so that firmware is not reflashable. There again, this depends on the hardware. For instance, for some motherboards, the BIOS cannot be reflashed unless a specific jumper is physically set; otherwise, the needed reflashing current simply cannot reach the chip.

Since a lot of existing hardware with reflashable firmware cannot be made non-reflashable, and "trustworthy sources" are a rarity from the point of view of any nation (because parts come from different countries), it follows that these generic workarounds are not actually practical.

(Maybe China could come up with a "100% Chinese computer" but having all parts produced on your national territory is not the same as being able to trust in their honesty and reliability.)


What current algorithms are considered (un)secure?

An algorithm can be secure only if used properly within a protocol that matches what the algorithm was meant to do. So none of the algorithms you list can be deemed "secure" in an absolute, unconditional way.

On the other hand, some algorithms are necessarily insecure and should never be used (for a security purpose). In your list, these are:

DES block cipher: it uses a key which is too short to be strong against the most stupid of brute forces attacks. 3DES, however, is fine in that respect.
Block ciphers in ECB mode tend to leak a lot of information on the encrypted data, with "real-world" plaintext data, and should be avoided except in some very specific cases.
RC4 has some biases which are rarely deadly, but are still a concern.

The rest of the list is "fine", in that they can be used properly and provide useful security. A lot of people nowadays are very nervous when they see "SHA-1" but this is a crowd-induced reflex which is mostly unsubstantiated.


If you write random bytes to an entire device, and then create a headerless (no LUKS or TrueCrypt) encrypted block at a random point on the device, then this is not something that can be detected.

For example on Linux;

Take a 100GB HDD.
Fill it with random data:

dd if=/dev/urandom of=/dev/sda bs=4K
Create an encrypted loopback device at a 'random' point on the disk:

losetup --offset $RNDOFFSET --sizelimit 5G -e aes -k 256 /dev/loop0 /dev/sda
Make your filesystem:

mkfs.ext4 /dev/loop0
And mount it:

mount /dev/loop0 /mnt/secret

The purpose of all this is that encrypted data should be indistinguishable from random bytes. This way your encrypted 5GB block is camouflaged against the random noise. Any crypto-disk headers, such as LUKS, would show clearly where the block resides, so bare encryption must be used.

Provided you keep $RNDOFFSET secret (don't go writing it to your fstab) the presence of an encrypted filesystem should be very difficult to detect.

And you can always say that the device is just a scratchpad or swap area that you use with a key that is randomly generated at each boot.


You can encrypt your key file and ssh will prompt you password to decrypt when you are connecting to your server.

ssh-keygen -p [-f keyfile]

ssh-keygen will prompt for a password used to encrypt the key.


NIST SP 800-90A DRBG, incorrect reult following algorithm, correct result rearranging algorithm steps?

The answer to this mystery can be found in another NIST document, The
NIST SP 800-90A Deterministic Random Bit Generator Validation System (DRBGVS), p.4:

The Generate random bits, do not print is the 6C58...AEB0 bit string. The second one, Generate random bits, print out is the 56f3...aca2 bit string.


How to use testssl.sh on an SMTP server?

wget https://testssl.sh/testssl.sh

chmod +x testssl.sh

./testssl.sh --mx <domain name>

works fine.

./testssl.sh -t smtp <ip>:25

and

./testssl.sh -t smtp <ip>:587

also work fine.

Note that not specifying the port assumes port 443, despite specifying protocol smtp. That doesn't work.


My network stops working when a certain network appears, am I being hacked?

This is not a security issue, but a WIFI spectrum conflict issue. This is quite common if you use 2.4Ghz 802.11b/g/n. With many people that subscribe to similar ISP in an adjacent area(e.g. apartment), this makes the situation worst, e.g. default ISP WIFI router always set to specific WIFI channel.

You can mitigate this issue by:

Experiment with another channel
Install WiFi analyzer, and choose a channel that is less like conflict with other
Solution 1 will not help if there is too many WIFI routers. Get a 5Ghz 802.11n/a/ac, together with correspondence USB WIFI dongle.  Use Wifi analyzer if you want to avoid another neighbour that use 5Ghz WIFI.  Because 5Ghz are not as penetrating as 2.4Ghz, so you don't need to worry much about 5Ghz spectrum conflict with your neighbour.(unless you live in HK/Japan with extremely small apartment)


A key logger can be installed at different levels in the system with different detection ways. You already have other answers that explain that it could be installed in a dedicated process and how to detect its activity.

But it could also be installed by changing the part of the X11 server that processes keyboard inputs. If it is presented as an add-on offering additional capabilities like simpler input on non ascii characters, automatic xxx (put you most expected feature here) it can even be willingly installed by the end user on its own machine. Else, it could be installed (if attacker managed to become root) at boot time through a dedicated init module.

It could also be installed as a kernel module and directly monitor physical keyboard activity. The installation procedures could be identical as previous case.

The only way to secure a system if to always follow all security rules:

protect it with a strict firewall (easy)
never use root to do simple tasks (those two first rules are the principle of least priviledge)
never run any uncontrolled piece of software on it

And the latter is the harder to follow. Of course I assume that you only dowload system software and updates from official sources and do control checksums. But this game or add-on or utility looks so cute... And as soon as someone has made you execute code that he wanted while you would not have, it is no longer your system.

TL/DR: as usual, security cannot be reduced to technological tools but highly depends of human practices...


Asymmetric crypto: Decrypt own messages without having private key

If you encrypt the message using a symmetric algorithm (AES), then you store this key twice - once encrypted with the admins public key, and the other with the users public key.

This way when the admin wants to view the message, he decrypts the first key, and the user uses the second.


Can someone perform DDoS on my VPS even if it is only accessible through SSH?

DDOS means Distributed Denial of Service. If no service is provided by your VPS then no service can be denied. If SSH is provided then SSH can be denied. This means a DDOS can actually work against your system too: if all the bandwidth is taken by the attack or your system is busy trying to process connection attempts to SSH then you will not be able to login anymore yourself, i.e. the service is denied for you.

Additionally your VPS shares the hardware with other VPS which all share the same bandwidth and CPU. Due to this if any of the other VPS gets attacked it might affect your VPS too.


Try the following command to check the expiration dates of the certificates in the keystore

keytool -list -v -keystore server.keystore -storepass <<password>> | egrep "Alias|Valid"

This should tell you if the new certificate is in the store with the valid dates you expect.

If the certificate is present and valid then check the following

  If you imported the key and certificate originally using the PKCS12 method, use an alias of "1" rather than "jetty", because that is the alias the PKCS12 process enters into the keystore.

This is documented in the jetty documentation about renewing certificates found here.


How do websites track users for flow control

There's many ways to enforce request rate limit, so I'll mostly focus here on what appears to be going on in your case;

It's highly unlikely, considering it's a commerce site, that you're dealing with such an anal retentive IDS (Intrusion Detection System) setup to block anything that remotely looks like a crawler and blocks (redirects in your case) requests on network level. Even though such systems are capable of request rate limiting, on sites like you describe, those would be setup a lot more permissively and only try to prevent illegal requests, request flooding, and similar. 20 GET requests per hour isn't that.

What's more likely going on is that you've hit a pesky WAF (Web Application Firewall) which acts on the application level and would care to fingerprint your browser and compare consecutive requests to establish if you're a crawler, then flag your requests as suspicious if they follow certain pattern that it is setup (or even trained, if you're dealing with a heuristic WAF) to detect. Such as, say, requesting many subsequent pages in the same order as they appear in the source, but are missing this source page (or the domain alone in case of HTTPS) in the GET request header's referer [sic, it's mispelled in HTTP specs] field. This would happen if you scripted your browser to request each new page independently, as if you typed its URL in the address bar and pressed enter, and is one of the safest methods (low chance of false positives) of detecting automated crawlers (aka bots), especially if you repeatedly request long and messy URLs and they otherwise use human readable versions of URLs, or ones equipped with additional URI parameters (referrer schemes, user tracking,...) in emails and everywhere else where users might access more of them in a short period of time without opening them through some landing page.

In short, if you'll want to avoid this detection of automated crawlers, you'll either have to inspect and obey rules in their robots.txt page, request from site admin to lax the rules for your crawler and make sure they can easily identify it (such as through user agent string), or make your script such that it mimics a human user better. Penultimate paragraph should help you avoid one of the most common bot detection techniques that seems to apply in your case, but you might hit additional ones as your request rate increases.


Secure authentication: partial client-side key stretching... please review/criticize my idea

Client-side hashing works, conceptually. The problem, though, is that of power. In a Web context, client uses Javascript, and Javascript is feeble for computing intensive tasks. The client already uses a system which may have a relatively small CPU (it could be a cheap smartphone, for instance), but Javascript adds its own overhead, which is huge (because it is interpreted, hard to JIT, and lacks decent integer types). As a rough estimate, client-side hashing in Javascript will be 20 to 40 times slower than password hashing on a decent server.

Unfortunately, user's patience does not stretch; the user tolerates one or two seconds of delay, no more. So when you use client-side hashing, you have to use less iterations than when you use server-side hashing, which weakens the whole picture.

Or, said otherwise, as long as you handle the login process of no more than twenty users per second, server-side hashing will allow you to use more iterations than client-side hashing, and thus be better for security.

If the client uses a Java applet, then it is much more powerful; the "20x" factor becomes "3x". But Java applets have fallen out of fashion and won't work on tablets and smartphones. Mobile clients with a dedicated app may revive the concept of client-side password hashing.

As for the details, the best way is not to "remove one iteration" from the algorithm, but to add an extra hash: cryptographic algorithms are complex animals, and though password hashing function internally use "iterations", they don't necessarily use only iterations. For instance, you cannot easily remove "the last iteration" of bcrypt and get a partial result to be transmitted to the server. So, instead, do all iterations on the client, send the result R to the server, and the server stores both the salt, and h(R) for some hash function h (e.g. SHA-256).


Let's clear something up first:

  I understand the main concept of XSS; on a regular website it could be achieved by for example redirecting someone to a URL with a manipulated query string in it.

No, XSS is when an attacker can inject code into client side code which is executed client side. The injected code can show an overlay (login screen for phishing purposes), perform requests on behalf of the user (call API endpoints to perform XYZ actions), redirect the user to malicious website etc...

The delivery point can vary. Using the query string in a URL is considered a reflected XSS. But say for example you're able to deliver an XSS payload via a comment on a forum, that's stored/persistent XSS. Check out the OWASP XSS page for more information.

The above explanation is usually explained in the context of a browser. Now WebViews are essentially "embedded browsers" in a mobile application. The above attack scenarios apply to WebViews as well. There's a small variation though!

First, in the context of Android and iOS, there are two types of WebViews: WebViews that essentially launch a new browser (SFSafariViewController on iOS, Chrome Custom Tabs on Android) and traditional WebViews. As far as I understand, the former is more isolated (process/permission wise) than the latter. Accessing "app data" in non-traditional WebViews is therefore harder since it requires sandbox escape exploits. For reference, each app inside Android/iOS have their own user/group ID. The app data for each app can only be accessed by the app itself (sandbox restriction).

Second, WebViews can be hardened by disabling JavaScript entirely. Most interesting XSS payloads are delivered via JS. HTML/CSS payloads can still redirect or change the layout of the webpage though!

Third, since WebViews are part of the app, it means that they can access own local app data via file:// handler. The problem? Browsers and therefore WebViews disallow Cross Origin requests. Meaning that a website served on example.com, cannot make requests to www.evilwebsite.com or file:// unless some CORS headers are set. There's one edge case though: sometimes mobile apps download a webpage via a custom HTTP client, save it locally and then open the saved webpage in a WebView. Now we don't have a Cross Origin issue, and it's possible to access app data. This is however one of those cases where the moon and stars need to align:

Successfully deliver a XSS payload
Vulnerable webpage is used by the mobile app
The mobile app programmatically downloads the page, saves it and displays it in a WebView (cross origin ✅)
Mobile app WebView is configured to allow JavaScript (in Android for example, you need to explicitly enable JS)
Interesting (unencrypted) data needs to be available in app data folder (such as shared preferences file) in order to make this attack viable in the first place.


Server with support for both EC and RSA keys

That's just another ciphersuite, given support by the ssl library, it should happen almost automatically.

Some suggestions: Is support for ECDHE-ECDSA compiled in the openssl version you are using? Are they allowed by the SSLCipherSuite you are providing?

Regarding getting help with this, openssl-users seems the right forum for this kind of specific question.


Known risks with the old IPSEC Cisco VPN client?

It is hard to tell what problems a specific unsupported software will cause in detail. But, if you look at the list of past CVE for this product you'll see regular problems  and even problems reported after the product was already end of life. This can be used as a base to extrapolate what kind of problems might still be lurking in the software.


CSRF with special characters in parameter name

There are three different content types you can let a form send (unless you have special CORS permission):

application/x-www-form-urlencoded
multipart/form-data
text/plain

You have tried the first one, and it doesn't work. It's unlikely that the second would help you (it's just a way to stitch multiple content types together when you are uploading files). So your best bet would be the third. Try a form looking like this:

<form enctype="text/plain">
    <input type="hidden" name="use:a:colon" value="This is an attack!">
    <input type="submit">
</form>

You will be able to send requests  without having the colons encoded.  Wheater it actually works or not, well, thats another story. The server might not accept this content type or there may be other hurdles.


Are there security issues around controlled cross site sharing behind SSO?

According to your description, I think what you are looking for is Content Security Policy (CSP). This header is can be specified by the web developers or administrators in the response, to declare approved origins of content, a specific browser should be allowed to load on a website. The intention was to provide a standard way to mitigate code injection attacks like XSS and clickjacking.
Almost all the modern browsers support this.
Refer this To get an idea on how to test if this works on the client side.
More info on the header can be found here


How can I map CVEs to their underlying CWE?

CWE and CVE are very different things, which can't really be mapped arbitrarily from one to the other. CWE is a categorization system for vulnerability types, while CVE is a reference to a specific vulnerability.

But a specific vulnerability can be references by a CVE and also be categorized via CWE (something the researcher who discovered the issue or the CNA who assigned the CVE may have done).

You could scape nvd.nist.gov or cvedetails.com, both of which have a CWE entry for CVEs (see https://nvd.nist.gov/vuln/detail/CVE-2019-10086 or https://www.cvedetails.com/cve/CVE-2019-10086/ for examples). You could also look for CVE APIs which contain the field (this related question has one example).

But for many CVEs - especially older ones - a vulnerability might not be categorized via CWE. You could try to map the Vulnerability Type field from cvedetails.com to a CWE, but if that is also not set, you'd need to categorize the vulnerability manually.


Memory Dumping - Cause for concern in Virtualization?

Is this possible?
Yes, it's possible. The VM's memory is accessible by the host system, which allows the host to read anything inside the VM, including kernel-mode memory. Quite a few VM solutions allow guest instances to be dumped to file, or suspended (i.e. a VM version of hibernate).

Is this a threat?
Note that the VM's memory won't entirely be stored in the host's physical memory, but rather will likely be partially stored in a swapfile. This means that part of the guest OS's memory is stored on the host's disk, making slack space analysis a potential attack, even after the guest OS terminates. Images of suspended VMs may also be accessible to an attacker if he steals the disk or gets file read privileges on the host. If the attacker can compromise the host, he may also be able to issue arbitrary memory reads and writes on the VM process, allowing theft and manipulation of data.

Can the VM grab the memory of the host?
It shouldn't be able to. VMs work by creating virtualised versions of processors and memory controllers. This virtual hardware takes normal memory access interrupts and translates them into a virtual address space. For example, the guest OS's kernel might wish to access the physical memory at 7a22d6aa, but the VM actually translates that address to vm.swap+0x7a22d6aa instead, such that the VM is completely unaware of the translation.

Such an attack would require violation of the isolation mechanisms built into the VM. These isolation mechanisms are very strong, since they have to contain an entire OS and any software / drivers it might run. Isolation is often implemented at hardware level using CPU extensions such as VT-x. However, VM systems are software, and software always has bugs. There have been vulnerabilities in the past where software on a VM was able to attack the host, usually via inter-OS communication mechanisms used for sharing files and clipboard functionality.


MFA is not designed to prevent any file deletion or change. It's only goal is to make stealing user's credentials much more difficult.

Also, you don't setup MFA for S3 bucket (or object), you setup it for a user. Permissions to that user are specified by ACL's and policies.

So in a way you can "enable MFA for S3". Create users, enable MFA, assign policies. But signed URLs are more suitable for your client's needs.


Generally, reading cookies by other sites or by a man-in-the-middle attacker is not possible, if the site is configured correctly.
Cookies are not strictly bound to the same-origin policy. Depending on their settings, they may be shared with subdomains and superdomains. If cookies settings are not marked as secure, cookies set over HTTPS are also sent over HTTP. So, if your cookie is on https://test.example.com, a man-in-the-middle attacker could create http://fake.test.example.com and read the cookie.