What is the purpose of encrypting a symetric key with a public key in XML EncryptedKey?

Why should I encrypt the symmetric key with the asymmetric one? Does increase confidentiality or performance? When should I use this double encryption?

You need to do the symmetric encryption because the maximum size of data RSA can encrypt is restricted by the size of its modulus minus some padding. For example a 1024-bit RSA key can only encrypt data that is at most 117-bytes long. Anything larger than that, you would have needed to split the data into modulus-sized blocks (which also open up a number of other cryptographic issues) or use even larger key (and RSA gets slow very quickly as the key size increases).

Diffie Hellman is a key agreement protocol, it can only work if both side are connected to each other to exchange some data when the document is being encrypted. The use case in document encryption system like XML Encryption is usually that you are creating a document which can be stored and read at a later date by the recipient, and either side may never be online at the same time when generating/reading the document. This is also why Forward Secrecy is irrelevant for document encryption, as you generally want to be able to read the document later, you can't just discard the session key like you would in ephemeral encryption system like TLS. You have to save the session key with the document somewhere so you can read the document later.

If you want PFS, then I'd suggest transferring your encrypted document over TLS/HTTPS, and if you no longer need the document, just delete the document or at least the encrypted part of the document.


Is there a good 160 bit alternative for SHA-1?

First, SHA-256 is significantly faster (usually) than SHA-512, and is strong enough for the vast majority of uses.

Second, you can truncate hash output, as long as you're aware of the "birthday paradox" -- e.g. 160 bits of output gives you ~80 bits of security. You probably want to avoid truncating if possible, but if you need to, SHA-256 truncated to 160 bits is better than SHA-1 at this point.

Note that all the recent SHA-1 attacks are collision-based -- there are no preimage or 2nd preimage attacks, even against MD5, so "reversing" these aren't feasible (currently).


Can a client with an ECC certificate and a server with RSA certificate establish a mTLS connection?

This is more a matter of practice in security protocols than of cryptography, but: YES, DEPENDING.
In older versions of TLS through 1.2 (and before TLS, in SSL3) each possible ciphersuite specifies, among other things, the keyexchange method which controls the 'type' of server certificate to be used, and how -- more exactly, what the algorithm of the key in the SubjectPublicKeyInfo must be, and what must be set in the KeyUsage extension if used. See the table in RFC5246 section 7.4.2 in particular the entries for RSA and DHE_RSA/ECDHE_RSA. If the client offers at least one ciphersuite acceptable to the server and using one of these keyexchanges, and for a keyexchange using RSA-signing (DHE_RSA or ECDHE_RSA) in 1.2 either omits signature_algorithms or includes at least one adequate RSA signature, and the server has a suitable RSA privatekey and cert, it can use it.
The client certificate, OTOH, is not controlled by the ciphersuite. If used at all, it is controlled by the CertificateRequest message in section 7.4.4 as modified by RFC4492 section 5.5 and section 3. If the server requests ecdsa_sign, the client can use a signing-capable ECC cert (informally, an ECDSA cert). The server can't request either of the ecdh_fixed cert types here, because those keyexchanges would require the server use an ECDH cert which your case doesn't.
For 1.3 the protocol changes but the result is the same. Plain-RSA and static-DH keyexchanges no longer exist, so the server certificate is now used only for authentication (signing), and is not linked to the ciphersuite but (only) to the client's signature_algorithms in ClientHello which is now mandatory. Conversely, the client's certificate (if any) is controlled only by signature_algorithms in CertificateRequest (if used). For ECDSA the signature_algorithm values now control the curve as well, which they didn't do in lower versions. It is perfectly fine for the algorithms to be different.
Of course all other requirements must be met: the client must validate the server's cert against the client's truststore at the current time, and for some protocols (like HTTPS) validate its hostname(s); the server must validate the client's cert against the server's truststore at the current time, and optionally check its identity information; the key size(s) and hashes used must be considered strong enough (not RSA-1024, MD5, SHA-1) as must the DHE or ECDHE parameters if used; other extensions like RFC5746, RFC7366, RFC7627, and single or multi OCSP (especially if stapled), must either be agreed or their absence accepted; unacceptable downgrade must not be detected. And probably more I've forgotten.


Open Source tool to block email attachments

Not really, no.

Firstly, when the traffic in question is passing through your proxy server, it's just web traffic - it's not an email yet. So to just block attachments, your proxy would have to read the traffic in great detail, and understand how to tell when every sort of web mail is moving an attachment.

That would be difficult but possible, although it would be hard to be sure you were catching everything: but you also have to consider that Gmail and many other web email providers support https, which means the traffic might be encrypted as it goes through the proxy, and so you have no way of reading it.


Is SSL a mitigating factor for HTTPonly not set on cookies?

HTTPOnly isn't really related to HTTPS. It instructs the browser not to make the cookie visible to JavaScript. So if there is an XSS flaw, regardless of HTTPS it should not be able to steal the cookie through that flaw.

The Secure if received over HTTPS instructs the browser to only send the cookie over HTTPS connections. It's meant to prevent an attacker from sniffing the cookie over the network (open wireless etc.).

HTTPOnly does not stop sniffing on an open wireless network. Secure does not prevent JavaScript from reading the cookie in case of XSS.


Why browsers don't support TLS without encryption and deprecate compression for public data

public data doesn't mean no expectation of privacy when reading it: "how to deal with AIDS" maybe a public page, but readers may wish privacy.
If the website has cookies, they are probably not public data (auth cookies, obviously, but tracking cookies too for example)


Can First Hop Man in the Middle be Defeated with TOR or VPN?

To be clear, issuing the *.google.com certificate causes the browser to explode with errors. You have to explicitly accept the certificate in most browsers in order to render anything, let alone become vulnerable to MitM attacks.

The same is true with other secure protocols. If somebody attempts to MitM a VPN, you probably have TLS authentication again and your client should explode. Same with Tor. TLS encryption won't validate.

You could probably ignore certificate errors in your VPN or Tor client... But why would you do that?

So the short answer is both VPN and Tor defeat MitM attacks... But so do modern browsers.


This entire thing boils down to one simple concept: risk management.
You have a piece of software that gives you raw information about potential threats. Now you go through the process you outlined:

Identifying vulnerabilities
Evaluating vulnerabilities
Treating vulnerabilities
Reporting vulnerabilities

False positives: you evaluate the identified vulnerabilities to determine if they are a risk that needs to be treated.
Vulnerability prioritisation: you evaluate the identified vulnerabilities to determine which risks need to be treated first based on what risks matter most. You can use scores or any other method that works for you.
Getting others to remediate: you need to communicate in a way that is effective in your environment. We certainly cannot provide a single answer to address this. This is often far more political and cultural than it is something related to security or risk.
So, given all this, it appears that you want to know how to evaluate vulnerabilities in a way that is relevant to the risks in your organisation. Relevance being key here. And this is more of a risk management process.
Risk management:

you assess the threats (the vulns in this case) as to whether they might have an impact on goals and objectives, and how much impact that might be (known as assessing "inherent risk")
you determine whether existing controls affect the impact (known as assessing "residual risk")
you tackle the ones that will have the highest residual risk

This can take seconds, or it could take months, depending on your context and how many variables there might be. So, a lot of orgs take shortcuts and just use CVSS scores without assessing existing controls unless remediation has a high cost and a cost/benefit analysis needs to be made.


How does DTLS replace the transport encryption of TLS?

The section you linked to says that the NULL cipher (no encryption) works the same as in TLS, and that RC4 (the only stream cipher in TLS 1.2) cannot be used for DTLS.

The next three subsections indicate that block ciphers and AEAD ciphers work exactly the same in DTLS as in TLS, and that new cipher suits must specify if they are suitable for DTLS along with what changes, if any, would need to be made.


Question 0: Am I correct?

Yes you are correct. Installing a package requires root privilege, so installing a malicious package means running malicious code as root.

Question 2: What are the ways in which Debian team addresses this threat in the main repositories?

First, you are recommended to use only Debian repository, and more precisely Debian stable repositories, this for two reasons:

The code from this repository has been screened by a lot of people before entering this stable branch which will by far limit the possibilities of a malicious application stepping through.
Then only security updates are provided, so future updates size are by far smaller than updates which would add dozens of shiny new features. Such modification being smaller, they are more easily screenable which, again, limits the possibility of anything malicious stepping through.

Then, once your root process is about to initiate the installation of the package, in order to ensure that this package is really the one provided by Debian team and has not been altered by a third party, each packages are cryptographically signed. Any change in the package will result in a bunch of warnings messages which will ask you to think twice before proceeding with this installation.

Question 1: Are there any ways to mitigate this threat?

Now for what concerns your side, it mainly depends on your actual needs and environment.

Of course as etherealflux mentioned in his comment any new installation on a production system should be carefully screened. You may want to manually unpack the package to check its content, you may want to install it in an isolated test environment to check its behaviour, etc.

However, there is also another solution, mainly addressing  your own comment "There is no reason that installing, for example, a tetris game on a communal machine should endanger accounts of users who do not play the said game.".

But for this, we need to step back a bit to understand what packages actually are.

In the early Unix/Linux days, there were no packages (or at least very few in the case of Linux): every one wanting to install an application should first download the source, then compile them. This made software installation and update take longer, but allowed each one to configure the software precisely how they wanted to.

Then packages came: pre-compiled software with most common settings for such system.

Here lies your issue with the Tetris game: these "most common settings" include, among over thing that the software will be installed system-wide, and this is this system-wide installation by default which is the reason why a user installing a Tetris could endanger the whole shared environment and all its users.

Software installation at the user level

As long as your /home partition (if it is a separate one) allows code execution (no noexec mount option in the /etc/fstab file), then your users are allowed to install their own software in their own home directory, without affecting the other user and without requiring root privileges.

However, such installation is not part of the "most common setting" mentioned above, therefore the packages do not offer this possibility. Your user therefore has to proceed as follows:

Download the Tetris game source code,
Read the INSTALL documentation file and check compilations options allowed by the configure script  (./configure --help), both provided with the source code. More specifically, they will need to set all directories to be under their home dir. For instance, the script could allow a --prefix parameter allowing to easily tell where the software will have to be installed, so you could for instance tell ./configure --prefix=/home/myuser/local. But other software may require different parameters to be set depending on their complexity and requirements. With a good and sane project, all this is clearly explained in the provided INSTALL file and configure online help and is easier than it may seem.
Afterwards, all it remains is to execute make, take a break, and once the compilation has ended make install (without sudoing to root!).

The only real issue in such process is if this software compilation requires dependencies not available on the system (this will result in an error message at the configure step, one of the roles of this script being to ensure that all dependencies required to compile and run the software are met). This becomes a recursive issue since you have the choice between installing a package to satisfy the dependency, on compile it at the user level and set the appropriate configure parameters / environment variable so the compilations tools and final binary will find all it needs.

But at last, your user will get a working Tetris fully installed on his account, without affecting the other user and without requiring any super-user privilege.


Is it safe to manually patch bugs on an outdated operating system such as Ubuntu 10.04?

I've been maintaining a private fork of a CMS for approx. 7 years. The initial release had some serious security issues which did not get fixed properly by the original vendor in time. This is why I have fixed it myself and this is where I have lost the compatibility to most of the original patches/upgrades.

This is possible, it takes a lot of time. And it might make sense if you want to do this for a limited amount of time - For example to prepare a solid substitution of an outdated environment. But if you are thinking about supporting the old platform for infinity, you are going to die old, angry and sad.


Can someone trace me from mobile phone IP?

There can be two cases while you're browsing :

Over HTTP :

In this case all your traffic goes in plain-text format, hence if an ISP wants to keep track of browsing history, they can easily do that. But in most cases, ISPs doesn't care(unless Government force them to) about what you do with your internet package. But they surely can track you including the things you send to the sites, like passwords, files. And also can impersonate to be one of the sites you want to visit.
Over HTTPS:

Now when you visit the sites over HTTPS protocol, things get tricky for the ISPs and Government Agencies. Since HTTPS does the two important things :

Verify the source : the data being received is from the Original Source.
Protect the data : the data being transferred is encrypted, so that only sender and receiver knows what is going on. This includes the URL of the website.

Since the connection is encrypted with at least 128-bit key. The ISPs can't see what you're browsing or what you're sending to those sites.

But there is a catch, even though the data is encrypted it at-least needs a source and destination. Now the ISPs can see(if they want+care) the IP addresses you are visiting, and by IP address one can roughly estimate the site you're trying to visit.

So, in order to keep the ISPs completely in dark, you need to use VPN while you're doing any online activity. In your case, you'll either need L2TP/IPSec4 VPN service, or use VPNGate with OpenVPN App(Android, iOS).


How to improve the security and privacy of Firefox

There are several actions you can take in order to secure Firefox, how far you chose to go is of course up to you.

You can make some modifications in the Firefox preferences menu:

"General"

"when Firefox starts"->"Show a blank page"
"save files to:"Downloads"

"Content"

check:"Block pop-up windows"
uncheck:"Enable
JavaScript"
"Languages"->choose only:"en-us"

"Applications"->choose:"Always ask" for every application
"Privacy"

"Tracking"->check:"Tell websites I do not want to be
tracked"
"History"->"Firefox will:"Use custom settings for
history"
"History"->uncheck:"Always use private browsing
mode"
"History"->uncheck:"Remember my browsing and
download history"
"History"->uncheck:"Remember search and
form history"
"History"->uncheck:"Accept cookies from
sites"
"History"->uncheck:"Accept third-party cookies"
"History"->check:"Clear history when Firefox/Nightly
closes"
"History"->"settings":check all -> except:"Site
Preferences"
"location bar"->"When using the location bar,
suggest:"->choose:"Nothing"

"security"

check:"Warn me when sites try
to install add-ons"
check:"Block reported attack sites"
check:"Block reported web forgeries"
"Passwords"->uncheck:"Remember passwords for sites"
"Passwords"->uncheck:"Use a master password"

"advanced"

"General"->"System Defaults"->uncheck:"Submit crash
reports"
"General"->"System Defaults"->uncheck:"Submit
performance data"
"Update"->check:"Automatically install
updates"
"Update"->check:"Warn me if this will disable
any of my add-ons"
"Update"->check:"Automatically update
Search Engines"
"Encryption"->"Protocols"->check:"Use SSL
3.0"
"Encryption"->"Protocols"->check:"Use TLS 1.0"
"Encryption"->"Certificates"->"When a server requests my
personal certificate"->check:"Ask me every time"

Addons

Empty Cache Button [optional]

Calomel SSL Validation [cool little addon which does exactly what its name says and also has some more tweaks in the settings]

Adblock Edge

Easylist

EasyPrivacy

fanboy-adblock

Fanboy's Tracking List

Fanboy's Annoyance List

BetterPrivacy [LSO/Flash-Cookie-Protection]

Cookie Monster [Allows you to Manage your Cookie-Policies. For less baggage use Firefox/Iceweasel "Preferences" -> "Privacy"]

HTTPS-Everywhere [Download via EFF.org] [settings: enable SSL-Observatory but don't allow to transmit ISP-data]

HTTPS Finder

NoScript [go to "settings" and check "also apply on whitelisted sites"]

Perspectives [SSL-Cerfiticate-Control - go to settings: "notary servers" -> check "only contact when websites cause security error"]

RefControl [controls your HTTP-Referers - setting: "block" -> "3rd parties only"]

Request Policy [rejects cross-site requests]

WOT [Web of Trust - user based website ratings that show up in websearches. Caution: Not very accurate. Always double check when in doubt. This addon tends
to get abused by different groups of users who either give malicious sites good ratings - or flag perfectly good sites.]

PwdHash [Nice addon to help your password management. Use "F2" when entering a password into a password field when setting up a new account somewhere to create a MD5-hash using your password and the domain. (When logging in you have to select the password-field and press F2 again to run the hashing.) This way you can use the same password on different sites without having to worry about security implications - because every site gets its own password generated through the hash. The tool is provided by Standford University and can be trusted. No data is actually transmitted to their servers. The hash is generated using your local java-script. If you need to login from a machine that doesn't have pwdhash installed: go to https://www.pwdhash.com/ -> their SSL is very strong.]

FoxyProxy [a convenient Proxy Switcher]

Useragent Switcher [Does exactly that. But be careful: If you set your user-agent as shown below - using this addon it will overwrite these settings and will not automatically restore them if you turn off the switcher. So you would have to manually reconfigure about:config again. Which sucks. But you can get a whole load really cool user agents here. Simply download the .xml and import it to the Useragent Switcher. There are really neat current agents in there: e.g. all kinds of different web browser for all OSs and of course various bots. Google bot comes in handy when you need access to some forum... wink]

Web Developer [Has some cool features. If you like inspecting websites just check it out.]

Bloody Vikings [Creates disposable mail-addresses]

Note: You don't need Ghostery. The above mentioned Adblock lists do a much better job protecting you from web-tracking without using the additional resourced Ghostery uses.

Of course there are more addons you could use. But I don't really see the point of them. Most of them either are snake-oil or even dangerous.
To keep your ISP and possible MITM-attackers from reading what you do on the web always use SSL - as far as it is available. To help with this use:

SSL-Search Engines

The user "SSL Search Bar" has provided easily installable SSL-searchbar-plugins

You get SSL-plugins for all the alternative search-engines like ixquick, duckduckgo etc. there. Install those you happen to use.

Privatelee also looks promising. But I haven't tried it out extensively.

The next thing to do is to change macromedias flash-settings:

Flash-Settings

Go here.

And fight yourself through their nasty settings-manager. Set everything to "0" or "never allow"/"never ask again" and
delete all stored website-content. Give special attention to the webcam and Mic settings

You might as well set the permissions of your .macromedia folder to read only - but that's kind of unnecessary because you want to make sure to edit the options mentioned above - to make sure that you don't allow websites to use your mic or webcam I actually take this one step further by disabling them in BIOS.

You can also go one step further and run Firefox in a sandbox such as Sandboxie.

Just a general idea of the things you can do that will help secure your browser.


Is there a security risk?  No.

Is there a security advantage?  No.

Using HTTPS means that the password is protected in transit, and that it is being sent to the server you intend to.  Hashing the password client-side and sending the hash gains nothing: an attacker in a position to look inside the SSL tunnel and steal a plain-text password (eg. malware installed on the client) can instead steal the hash and pass it when impersonating the user.

As a side note, there are problems with hashing or encryption in Javascript.  Using a browser extension rather than in-page Javascript avoids many of them, but there's still a speed issue: Javascript is slow compared to native code, so you can't afford anywhere near as many rounds of bcrypt hashing.


How could attackers exploit $_SERVER['HTTP_REFERER']

If the website makes certain security decision based on the referer and performs no other security checks, you can spoof this value.

Also, if you are sending raw HTTP, you could use this for some type of injection or possible XSS attack. For example, if the web page behaves differently based on the referer, it might take the referer as input to a function. Since the referer is not commonly a user input field, they may forget to do proper sanitization against this field, giving you an in to do any type of input based attack.

Some more from OWASP:

Using referer field for authentication or authorization
Sites may use referer as a weak form of CSRF protection
Hotlinking to improve phishing quality or cost


How to properly secure an ActiveMQ instance, and what are all of the different files for?

At the time I am answering this, this question is 2 years old, so my answer might include things that have changed from the time this was posted.  Ill answer the second question first:

credentials.properties     -> clear text passwords
credentials-enc.properties -> Encrypted passwords, if configured
groups.properties          -> a list of groups, and what users are members
login.config               -> a file to configure more advanced auth like ldap integration
users.properties           -> a list of user names.

So I found this question while trying to figure out some of these things myself, so I am no expert.  But I will share what I have learned.

Everything above other than login.config is now irrelevant.  or it seems that way to me.  If you are trying to configure LDAP integration, you have to deal with login.config, but otherwise... I think that one is also irrelevant.  The things that do something when I mess with them:

jetty-realm.properties
This is the important one right 'out of the box'.  It is formatted like:

userName: securePassword, nameOfGroupUserIsMemberOf

so if you want the 'foouser' user to use the password 'barpasswd', and be a member of the 'buzgroup' group, this file needs a line:

foouser: barpaaswd, buzgroup

OK, so how does ActiveMQ know to call this file?  By default, it is configured in the file:
jetty.xml
This is a very important file.  Many of the instructions I found for LDAP integration suggest changing this file... but I cant get it to work.  If i figure it out, I will amend this post.
The other important file is:
activemq.xml
At the time of this post, the official docs suggest altering this file for several reasons.  One of them is for LDAP integration... but those instructions do not work as far as I can tell.  Above, you discovered altering this file  to hard-code user accounts.  I think they include this for backward compatibility, but I am not certain.

Now i will answer the first question.  Once you have users configured in jetty-realm.properties, you can configure activemq.xml with permissions.

an example:  https://svn.apache.org/repos/asf/activemq/trunk/activemq-unit-tests/src/test/resources/org/apache/activemq/security/jaas-broker.xml
you can see it in the authorizationMap section...

More notes for anyone interested:

When I followed the instructions to encrypt passwords, the service stopped loading.  The reason seems to be the formatting of the file 'credentials-enc.properties'.  When I reformatted to be like 'jetty-realm.properties', the service would load, but ignore the encrypted passwords.  Fun. I tried putting the encrypt passwords in 'jetty-realm.properties', no joy.

I can get activemq to encrypt and decrypt text, but be aware that the documentation says that only alpha-numeric are supported.  No spaces, nothing else.

Also, I will provide links to the pages I found, but they all conflict, and I got little to work other than the default setup.

What I know about LDAP integration:
if you use JAAS, do not try to use a newer version.  Do not try to use jetty-plus as they suggest in some of these links.

https://www.middlewareinventory.com/blog/active-mq-installation-and-security-setup-and-hardening-step-by-step/
https://activemq.apache.org/encrypted-passwords.html
http://activemq.apache.org/cached-ldap-authorization-module.html
http://activemq.apache.org/security.html
https://stackoverflow.com/questions/52686757/activemq-web-console-using-ldap-active-directory-authentication/55244956#55244956
https://bacedifo.blogspot.com/2013/06/securing-activemq-580-web-console-using.html
https://steamingpileofsoftware.blogspot.com/2013/10/secure-your-jetty-activemq-web-console.html


Can I use hardware random number generation on my computer? Am I already using it?

As a regular computer user your problems won't be with the random number generator you use, but probably something like password reuse. SSL does depend in part on the MD5 hash function, for which collision attacks do exist. Recently the Flame malware exhibited a successful (but computationally expensive) attack on the Windows Update system due to its dependence on MD5 for security. TLS is more widespread and uses the SHA1 algorithm, no attack has yet been found; However any sane hacker will try to attack the CA's directly and use a forged certificate to perform a man in the middle attack, rather than investigate the entropy of your random numbers.

For a regular linux user, you can read from /dev/random to get "pure" random numbers gathered from the enviroment, in practice /dev/urandom is just as good. It hashes the entropy pool that /dev/random draws from and falls back on pseudo random number generators when the pool becomes to "dilute". For comparison on my netbook reading from /dev/random for 10 seconds gives me 46 bytes of really really random data, /dev/urandom pipes 65 megabytes of only slightly less random data. I don't feel like waiting a minute to start a ssh session.

In most any case, randomness is not the weak link. TLS depends on CAs which are operated by people, file encryption depends on how long a password you can remember and where else you type it, people are always part of the equation and they typically less reliable than SHA1.


Do I still use HTTPS when I search from the URL bar in Firefox?

It depends of your Firefox's default search engine. As you can see here, Duck Duck Go has SSL addon. I guess nowadays almost all "serious" search engines like Google do searches over SSL. Not always been over SSL, in very old versions it was in plain. You can check here an article to force SSL search on Google search. The article is an old one (2012).

Anyway, you can do a Proof of Concept (PoC). Start sniffing with a Man in the Middle (MITM) to your computer which is going to do the search.... and you'll see if search is in plain or not on your Firefox's search engine addon (you didn't said which one you are using).


"Legal" means that it depends on the jurisdiction, so you will get at least one answer per country, and in some cases (e.g. federal states like the USA) many distinct answers for a single country.

Usually, in a business context, employees have a right, and an expectation, of privacy, meaning that spying upon their activities is not legal; employers cannot read emails, listen to phone calls, or, indeed, log keystrokes without knowledge and consent of the employees. However, in many jurisdictions, corporations can edict security policies that users must explicitly agree to when they sign their employment contract, and these policies may allow the employer to do some spying. This does not, however, entitle the system administrator to use the data which was thus grabbed.

Of course, even if made "legal" through user explicit consent, generic spying and grabbing of passwords and keys is a very efficient way to make employees very unhappy.


why does aircrack-ng need AP name when wordlist read from stdin?

In most recent versions of Aircrack-ng, when you use the command:
aircrack-ng -w mywordlist <capture file>

You'll be asked to enter the index number of the target network.check this image

Basically, both tools need the SSID to be able to crack the 4-way handshake 'not the point to discuss', but the difference is within the tool.

I believe that Aircrack-ng has some advanced interpreting methods to discover the required bssid or essid from the file, while JTR just asks you to enter it manually.


How can I securely develop a local webapp at a coffee shop?

Safely developing against localhost can be done provided:

your machine is configured to resolve localhost to a loopback address (note, it's possible to change your hosts file to resolve localhost to a different address)
your machine is configured to route the loopback address via the loopback interface (it's possible to route loopback addresses to non loopback interface)
you configure your application to listen on the loopback address, not 0.0.0.0 (many web frameworks listens on 0.0.0.0 by default, this is probably the most common reason for unexpectedly exposing services to untrusted network during development)
if you use a proxy, your browser is configured not to route localhost/loopback through the proxy

In other words, a fairly typical networking configuration.

Also, take care that your database server aren't binding to 0.0.0.0, as that'll allow anyone on the network to connect directly to the database server. It's probably best to set a firewall configuration so you know exactly what ports and addresses that local services are listening on.

The link you pointed is under the context of a publicly trusted CA issuing certificates with "localhost" name. This is unsafe under that context because the recipient of such certificate may use the certificate to intercept the communication of someone with some unusual networking configurations. When you have full control over your own machine's configuration and you know that you don't have some weird configurations on your machines, the loopback interface is safe.


The certificate request is generated where the private key is generated; and the private key should, normally, be generated by the client, since the client will ultimately store it.

You can have a model where you (as a server) generate keys for clients and then distribute the keys and certificates to the clients, but it raises the question of why you use client certificates in the first place: certificates are for situations where the prover (the client, who wants to be authenticated) demonstrate his identity to the verifier (the server) without giving enough information to the verifier to allow it to impersonate the prover afterwards when talking to a third party. In a classic client/server setup, this is overkill; and this extra property disappears if the server itself knows the private keys (even transiently).

Moreover, the third-party CA will bleed you dry by billing you for each client certificate. Using a third-party CA for a purely private business (the client certificates are for you, not for anybody else) looks like wasted money. For the server certificate, this is understandable: you want a certificate that every potential client will recognize as valid, i.e. relative to a root CA certificate that they already have. But in the other direction, this is just your own server. Running your own CA (e.g. with EJBCA) would probably be worth the effort.

Assuming that using client certificate is an unavoidable characteristic of the situation at hand (e.g. some high-ranking manager has heard the term "certificate" and fell in love with it), then you can produce them on the server side by talking to DigiCert (or your own CA, if you run one) with whatever method is appropriate for them. On a Windows system, private key generation, certificate request building, and acceptance of the resulting certificate, can be done with the command-line tool certreq. Once you have the private key (it never left your machine) and the certificate, export them both as a PKCS#12 archive (also called "PFX"), protected by a password, and send that to the client, who will import them in his browser. This transfer ought to occur with some protection, of course... though a PKCS#12 archive is tolerably well protected by the password, you still have to transfer that password to the user in some way.


Try this:
http://pentestlab.org/10-vulnerable-web-applications-you-can-play-with/

and this:
https://www.owasp.org/index.php/Appendix_A:_Testing_Tools

or just google for vulnerable web application for learning penetration testing.


Account identified only by name, surname and date of birth

Given that name, surname and birth date are easily to obtain information for a single person or even in bulk there is (based on your description) an obvious risk that personal information can be viewed and changed (which might result in charges to this person) and also for en-masse denial of service.

Given that this "works as intended" the ones who designed this system either did not understand these risks or they've knowingly accepted the risk in favor of improved usability of this site - which can be a valid decision for this specific use case (although it sounds unlikely based on what you write).  If I understand you correctly you are working in QA of this site. In this case it should hopefully be possible to discuss the design decisions with the developers and software architects to find out if they are aware of the risks and consider these acceptable.


Would an anti-virus software make any other processes consume more CPU?

It is difficult to tell with certainty, depends on the AV implementation and how it intercepts resources being used by processes (executable, files, memory).

Because some AVs run with very high privileges (potentially at the kernel level) it is possible that they intercept system calls and libraries to sandwich their scanning code at run time. In this case, there won't be a separate AV process taking up resources, the system will account resource use to the process that is doing the system calls and pulling in the libraries.

... Unless the sandwich code offloads the effort to AV processes. Then we're back to the scenario where it's the AV that takes up scanning resources.

More traditional AVs work on the basis of scrubbing ram and the file system, potentially monitoring new processes, which would have AV pricesses doing most of the work not the work processes.

How can you find out exactly how it is happening? You'll need to dig in a bit, use strace, monitor kernel tasks with perf, monitor process use of resources over time with and without AV, etc.


CERT has create a CERT Perl Secure Coding Standard and there's been discussion of having Perl::Critic have a set of policies that match their standard.  As far as I know, nothing's been done yet.  Here's the start of the discussion on the Perl::Critic dev mailing list.


If an attacker has an arbitrary write vulnerability, they can bypass any form of software-implemented in-memory code signing. They could modify the memory after the code has been verified but before it is executed (a classic TOCTOU vulnerability), or simply toggle whatever bit is used to verify integrity. The only way this would work is if the check was implemented in hardware, with the actual code being verified by the CPU itself. However, it is much easier simply to use standard access controls to prevent memory injection. On Linux for example, this can be done with the Yama LSM. This is possible because memory injection is mediated by the kernel. The injecting process must specify the target and request permission to read from or write to its memory. The kernel can simply refuse the request, forcing the malicious process to escalate privileges quite a bit to modify memory.


I mean if the Windows' administrator permission right doesn't pop up, then the cyber criminal can't harm me right?

There are no administrator permissions needed to install extensions into your browser, change the start page or generally run and programs as your user which then also can read, modify or delete any kind of data owned by the user. For example ransomware does not need administrator permissions to encrypt the data of the non-privileged user.

  Is there any chance my PC has been infected?

This is not clear from the information you provide. It might be that you've tried to visit a site which incorporates lots like ads in a way similar to how adware does it. It might also be that these scripts serving ads were injected by some adware locally on your system. If the problem happened only with this specific site it is more likely that it is a problem or feature of the site you visited, if it happens with lots of other sites it is probably a problem local to your system.

  So what exactly cloudfront.net adware

Adware, as the name says. That is it might place ads into pages you visit, replace existing ads, maybe clicks on ads in the background so that it looks like that a user is interacting was the ads (i.e. ad fraud).

  ... and how can it infected me?

You've already cited the typical infection vector:

  These adware programs are bundled with other free software that you download off of the Internet.


2 AP (TP-LINK) - bridge mode - security issues

Please check for a "bridge password" somewhere (after, of course, updating your firmware) - there's some reference to one in a Whirlpool forum post, though another user in that post couldn't find it.

As far as needing security, unless you want other to be able to intercept your data and see what you're doing or possibly inject themselves into your network, I would very much recommend some sort of security over bridge mode.

If there is no "bridge password", then I'd recommend one of three things:

1) Upgrade to something different, like a Ubiquiti, that does allow for WPA2 in bridge mode (an example with screenshots is in this tutorial, backed up by the Ubiquiti AirOS 5.5 manual which calls out only AP-Repeater Auto mode as not allowing WPA/WPA2 "because WPA or WPA2 requires different roles on AP
configuration (authenticator or supplicant).").

2) Set up your network so the only traffic over the wireless bridge is tunnelled through a VPN.  Personally, I like OpenVPN with certificate based authentication, which pfSense makes very easy, but properly configured IPSec also works, as do many (but not all) other VPN solutions.

3) Both of the above - WPA2 protected WiFi carrying a VPN tunnel.  This means that, very likely, both would have to be broken in order for your data to be read (i.e. if, long ago, an attacker captured the Wifi traffic of someone using brand-new WEP in 1999 carrying a secure VPN [say, 3-key TripleDES], even today, while the WEP encryption would have been long broken, the secure VPN is likely to still be secure).


What does an unquoted shell variable allow?

In general, $DEFAULT_BRANCH (with no surrounding quotes) is the “split+glob” operator. What it does is:

Take the value of the variable DEFAULT_BRANCH (or the empty string if the variable is unset). This is a string.
Split the string at each whitespace sequence (assuming the default value of IFS). This produces a list of strings.
For every element in the list, if it contains a wildcard character (at least one of \*?) then it is interpreted as a wildcard pattern (glob) and replaced by the list of matching file names. If there are no wildcards or if there are no matches, the element is unchanged. Thus the result is a list of strings (that is at least as long as the previous one).

Contrast with "$DEFAULT_BRANCH" (variable expansion in double quotes), which expands to the value of the variable DEFAULT_BRANCH, plain and simple.

If the value of the variable DEFAULT_BRANCH does not contains any whitespace or any of the characters \[*?, and the IFS variable is set to its default value, then $DEFAULT_BRANCH expands to the value of DEFAULT_BRANCH.

Provided that you've sanitized the value of the variable to contain only safe characters, and that you're sure that IFS hasn't been changed, leaving the variable unquoted is correct.

If the value of DEFAULT_BRANCH can contain wildcards then it's another story — your assertion that you “can't glob” does not follow. For example, the leading refs/ prefix and the ban from .. does not imply that refs/.[.]/.[.]/.[.]/.[.]/etc/passwd is banned. If you don't block wildcards, DEFAULT_BRANCH could refer to an arbitrary file. If your filter is git check-ref-format, it does block wildcards; I think it makes an unquoted $DEFAULT_BRANCH unexploitable.

In any case, leaving a variable unquoted is never harmless. Every time you see an unquoted variable, you need to worry about what makes it safe to leave it unquoted. This is a lot more expensive than writing those double quote characters in the first place. So any variable substitution (or command substitution, same thing) that's left unquoted without a clear need should be reported as a finding and gear your overall evaluation towards judgint the code as sloppy.

Note that there is another gotcha: leading dashes. A leading - in the argument to a command, in many contexts, causes the argument to be interpreted as an option. This can result in the command executing arbitrary code instead of processing a file. To protect against this, put any argument that comes from a variable after --, which means “stop processing options (and accept only operand arguments) from that point”. For example, if myfile has the value -mfoo, then file -i "$myfile" analyses its standard input based on the magic database file foo, whereas file -i -- "$myfile" analyses the file called -mfoo based on the default magic database.

In Security implications of forgetting to quote a variable in bash/POSIX shells, Stéphane Chazelas gives examples of exploits on scripts that don't properly.

In your case, git clone -b $DEFAULT_BRANCH file://$target $target is unsafe, both with respect to DEFAULT_BRANCH and with respect to target.  How exploitable this is depends on what files are present in the system (I don't know what means you have of injecting them).

You say that DEFAULT_BRANCH has to start with refs/ and can't contain spaces, but can contain wildcard characters. Since it starts with refs/, option injection with a dash is impossible — even with wildcards, all matches will start with refs/. You might end up running git clone with more operands than it can cope with, which would result in an error. If you're able to create a directory called refs and a symbolic link inside it, then you may be able to enumerate files on the system, but I don't think you'll be able to read them as git clone will just stop and complain about extra arguments.

If DEFAULT_BRANCH could start with - then you could probably overwrite arbitrary files with values like -u /path/to/file and possibly even run arbitrary commands through --config=… (I'm not completely sure about that, clone isn't hook-rich).

As for target, apparently, it can start with -, so you can pass options that way. Try values of the form -option=badvalue/path/to/file: the part up to the first slash is effectively ignored in file://$target, which lets you specify an option with a value that ends in a valid path to a file. More options may be possible if you can inject files and craft an appropriate wildcard pattern.

You say that “$target is completely sanitized with \”. I don't know what you mean by that; it's impossible to “sanitize” a variable by adding backslashes to a value. Backslashes are only expanded in an unquoted expansion of there is at least one wildcard character. For example, \bar is expanded to \bar, not bar; only something like \*z becomes *z. The only way to protect a variable against expansion mishaps is to double-quote its use, you can't prepare for an unquoted expansion by massaging the value unless you make restrictive assumptions about what the value was in the first place.


How can one decrypt a SSL/TLS session? Besides the private key what else is needed?

For RSA or DH (not DHE) cipher suites, you just need the server private key, of type RSA or DH, respectively (DH certificates are exceedingly rare).

For DHE cipher suites, you would need the dynamically generated Diffie-Hellman private key. This key is never stored anywhere, and that is by design. Correspondingly, you cannot decrypt the data afterwards. This is called Perfect Forward Secrecy.

For the TLS cipher suite with a pre-shared secret: raw PSK cipher suites can be decrypted with knowledge of the shared secret; RSA_PSK suites need knowledge of both the shared secret and the RSA private key; DHE_PSK suites provide perfect forward secrecy.

SRP cipher suites also provide perfect forward secrecy. There again, this is by design: if knowledge of the password sufficed to decrypt a recorded connection, then this would allow offline dictionary attacks, precisely what SRP is meant to thwart.


Which HTTP status codes are interesting from a security point of view?

HTTP 200s can be awesome for an attacker when he is requesting URIs that should be protected by authorization (http://cwe.mitre.org/data/definitions/862.html).

Attackers pay notice to HTTP 500s – they often lead to offensive success.  Observing lots of HTTP 500s can be interesting.  If the app likes to redirect (HTTP 302) upon errors, then lots of HTTP 302s can be interesting.

To catch nefarious activities it may be best to observe numerical changes (min, max, median, mean, standard deviation) of some or all of the HTTP status codes.  Observing 50,000 HTTP 200s in a short time span from an IP block can mean your databases are on their way to public fame.  Lots of unusual HTTP 200s can also mean an attacker has found a way to send malicious requests successfully that are answered with HTTP 200s.

If you have lots of time to play you could model the activity of "normal" users (i.e. how many of each of the HTTP status codes does a normal user generate during a session, for example) then look for variations that cross tolerance thresholds.  Search for anomaly algorithms and try ones you think may work to identify unusual activity by analyzing only HTTP status codes.  Could be fun research actually.

On a side note if you are looking at Apache logs for attacks, check out http://code.google.com/p/apache-scalp/

  Scalp! is a log analyzer for the Apache web server that aims to look for security problems. The main idea is to look through huge log files and extract the possible attacks that have been sent through HTTP/GET (By default, Apache does not log the HTTP/POST variable).


There are several techniques that are still being used beside OAuth.

API keys/Service keys
Whitelisting IP's
User/Password Login
Token Login (non OAuth)... eg. custom implementation.
none, just a 'secret' web-endpoint.

and often a combination of them.

What you saw often was a combination of whitelisting and one of the other techniques.

OAuth was designed to limit the rampant "leaking" of user login credentials, by implementing a system of token and authentication (not based on user information)

it is even designed with thoughts of replacing the tradional Username/password system. (in conjunction with openid which does a similar thing though other mechanisms, that work amazingly in unison).


Should passwords be automatically reset when the underlying method changes

Your option 1. is a bad idea: in addition to the User-Experience / Public-Relations reasons you state, you're also giving attackers a window to intercept the password reset tokens and compromise every account on your server. It also doesn't solve your problem if you have even one user who's too lazy to log in / update their password.

At first glance, both 2. and 3. seem fine to me. Your #2 is no less secure than what you're doing now, but 2. would mean you have to continue supporting the current weak login forever (or do something like "After X months we're wiping your password and forcing you to do a recovery" which breaks the nice user-transparency you want, so let's ignore that).

Let's consider the case where you have users in the DB who will never log in again. With both 2. and 3. you have to continue to support the current hashing alg in your code-base forever just in case they do log in, but at least 3. has the advantage that they (or rather, you) are protected against offline brute-force attacks if your DB is ever stolen.

Since you'll have to keep the "old style flag" column around forever, do yourself a favour and make it an int not a bool so that if you ever have to update your password hashing alg again, you can record which old style they are on.

UPDATE: A very similar question was asked here and built on the discussion from this thread.


Can app / service provider konw when its user using (selfhost) VPN server?

I don't know whether the Netflix App is coded to detect your interface, but the information is available and it certainly could know you are using a VPN.
To clarify, based upon a comment: Yes, any app can know it's using a VPN.
I don't think Netflix cares how you use your account, and using a VPN to your house is fundamentally the same as using your direct house WiFi.


Does passing encrypted card data through a server mean that the server must be PCI compliant?

In this scenario my main concern is whether passing the encrypted card
  details to the web application server is considered an issue for PCI
  compliance?

In the scenario you've described, you are not passing encrypted card details.  You are passing a token, generated by the payment processor and passed back to you through the web client, which represents a lookup to the actual card data once passed (by you) back to the processor.

In this scenario, presumably the shopping cart page which contains the iframe or javascript which causes the customer's browser to send card details to the processor is served by your server.  In that case, you are still subject to PCI compliance, per SAQ A-EP (emphasis mine):

  SAQ A-EP has been developed to address requirements applicable to
  e-commerce merchants with a website(s) that does not itself receive
  cardholder data but which does affect the security of the payment
  transaction and/or the integrity of the page that accepts the
  consumer’s cardholder data.

  SAQ A-EP merchants are e-commerce
  merchants who partially outsource their e-commerce payment channel to
  PCI DSS validated third parties and do not electronically store,
  process, or transmit any cardholder data on their systems or premises.


Does password strength matter when using a YubiKey?

Multi-factor authentication is based on the idea that if one authentication factor fails, you have others to protect you. If someone tricks you into giving up something you know (ex: a password), they will be thwarted by something they don’t have (ex: a hardware token generator).

If you used a good password and were sure that no one could steal (or trick you into giving up) your password, then having a hardware token generator doesn’t really make sense. If you were sure that no one could steal your hardware token generator, then having a password doesn’t make sense. But this defeats the idea of multi-factor authentication.

So to answer your question, if you are very confident that your Yubikey won’t be stolen or cloned, then having a strong password doesn’t offer a huge benefit. But you also limit the benefits of multi-factor authentication if your device does get stolen.

This answer also assumes that websites implement all of the authentication factors correctly. This isn’t always the case since some websites such as Apple don’t require the second factor for all of their services. Historically some services like “Find my iPhone” required only a password and not your second factor even if it was enabled on your account (this may still be the case, but I haven’t checked).


Is there any point in having the HSTS header enabled when using HTTP/2?

Yes, HSTS is still needed, including HSTS preload.

The way a browser connects to HTTP/2 is through a URL that looks exactly the same as the URL for HTTP/1, so it doesn't know that it must be HTTP/2 just from looking at the URL. It will try plain cleartext HTTP if it is given a http:// URL. In order for the browser to not try plain HTTP (and not be subject to attacks from rogue WiFi AP, etc.), the URL must be https:// (and then HTTP/2 upgrade will happen through ALPN), and the way to ensure that regardless of what the user types in the address bar or an external links says, is using HSTS.


Self Signed Certificate in Certificate of Chain

The first error was because s_client doesn't like to see the root CA in sent in the TLS connection. The second error is because s_client doesn't trust the root CA.

To solve this second error, run s_client with the -CAfile option and specify the root CA.


Sharing access-tokens in response header?

If you are doing this for federated identity (single machine/human using multiple services) then use a purpose-built system for that.

Federated identity is hard to build correctly and unlikely to be important enough to your business to be a core competency that you'll justify maintaining properly.

I recommend using SAML 2.0 because it is broadly deployed and supported.  Many implementations (including Shibboleth/OpenSAML) have been extensively pen-tested.

JWT is very similar to SAML, but is still evolving and the inconsistencies in implementations could make it frustrating to deploy successfully.

Both are based on sound cryptographic techniques and deploying them securely depends fundamentally on effective key management.  Using a single private key for signing SAML Assertion or JWT Tokens for an excessive time period, volume of assertions/tokens, or after suspected compromise of a system with plaintext key access compromises the security of all federated services.


If you connect to a totally unknown server, you can indeed be victim of a MITM where someone gives you the fingerprint of a key-pair he controls.

However, the way to go is: setting up the server, get the public key's fingerprint. Then you can validate the fingerprint you see on connect matches the fingerprint you know from the server. If someone were to perform a MITM your client would show a different fingerprint.


Do hashes contain any of the original file’s data?

May contain, or may not. For example, taking the first letter of a message as a hash is possible. It may be a good hash algorithm for a particular purpose, but definitely it is not a good cryptographic hash.

So I will suppose that your question is about the cryptographic hash.

Ideal cryptographic hash algorithm have (beside other) these properties:

It is infeasible to generate a message from its hash value except by trying all possible messages.
A small change to a message should change the hash value so extensively that the new hash value appears uncorrelated with the old hash value.
It is infeasible to find two different messages with the same hash value.

(In real world, replace the word "infeasible" with "highly improbably".)

So, just the first of these properties shows that you are almost correct in your statement

  The only way to know anything about the file is to recreate it independently through trial and error, where the hash offers nothing but confirmation that the created file matches the original.

as there are some issues with it:

The set of all messages is infinite, so there is no possibility to perform an exhaustive search.
In the context of the blind searching the hash don't offer confirmation that the created file matches the original as there are inherently many and many collisions (same hashes for different messages).
It is highly improbable that you find even 1 file (message) with the given hash, so the "trial and error" method will give you nothing but errors.


Form submissions over HTTPS are not encrypted?

Burp is an intercepting Proxy, which lets you inspect and modify traffic between your browser and the target application. Burp is actually serving it's own certificate so that you can see what's inside the request. Normally you will have accepted a security warning for a certificate issued by Portswigger, this is the certificate generate by Burp.

If you want to assess your application you should use Wireshark instead and look at the HTTP requests. Those should not be visible to you.


Full disk encryption for server running virtual machines

Bitlocker with Active Directory integration is probably best for Windows Server 2012.  Your primary problem with FDE on servers is the requirement for boot time passwords with things like Becrypt, TrueCrypt, PGP.  Boot time passwords generate extra work for your network ops.

Encrypting inside the VM is usually unnecessary. What are you defending against? Full Disk Encryption is usually a defence against the disks or the whole device being physically stolen.  In a typical scenario, a VM host server and the VMs will powered on and disks decrypted 24/7, inside a physically secure environment such as a data centre.  But even if your physical server is vulnerable to theft, the VM data will be encrypted any time the physical server is encrypted.

The only occasion I can see where the FDE in the VM would be useful is to protect a backup of the VM - providing the VM was shut down properly before backup.  But it would be better to encrypt the whole backup.

Of course if you are in a regulatory environment where FDE is required for legal reasons then you just have to get on with it - I would use Bitlocker.


Are flash cookies still a threat and that persistent?

While "flash cookies" might be easy to clear as cx42net noted above, there are also other techniques that can be used to store hard-to-delete cookie-like data and read it from the server side.

Take a look at evercookie for reference. I've seen this used in relatively high profile e-commerce and content sites.


In Visual Studio, what are the risks of simply opening an untrusted project? What are the mitigations?

This has to do with the project itself and the automation in Visual Studio.  It could potentially do quite a lot since Visual Studio can do some pretty low level stuff.  The way to mitigate it is to either check the project and solution files manually for build steps and such prior to opening (it's all human readable XML if you have much familiarity with Visual Studio and they aren't  generally too too long) or to simply add the source to a newly created project and solution.


PHP Code execution in function parameters and logical operators

Why PHP will execute code inside a parameter function (sleep in is_string) ?

When a function is called each parameter can be an expression. This is true for almost all languages and might be more obvious when you use something like is_string("foo" . "bar").

  And what is the role of logical operators in this case ?

and just evaluates and combines the parts from left to right to get a result. 3 and sleep(30) just means that it will treat 3 as a boolean and if this boolean is True (which it is in case if 3) it will evaluate the right side of the and operator and thus execute sleep(30).


Why is the brute force search time for hashing algorithms 2^(num_bits / 2)?

When a hash function has an output of size n bits, then:

The generic algorithm for finding a preimage (or a second preimage) has average cost 2n evaluations of the hash function.
The generic algorithm for finding a collision has average cost about 2n/2 evaluations of the hash function.

By "generic" we mean "the algorithm that works against every hash function, however perfect that function may be". In the case of preimages and second preimages, the generic algorithm is also known as "luck" (we try input messages until we get lucky). For collisions, there are various smart algorithms that are all facets of the so-called birthday paradox. I wrote "about" because these smart algorithms also incur some RAM cost or some limitations on parallelism, so the actual cost of finding a collision cannot really be expressed as a single number; or, if you prefer, the mathematical cost does not translates exactly to a proportionate number of dollars, if you really want to do the computation.

Various protocols use hash functions for various reasons. It is hard to ascertain whether a given protocol is immune to collisions, or not. In some cases, an actual attack may require a preimage computation; or maybe a collision is enough; or the situation could be more complex. So, just to be safe, we usually assume the worst and thus look at the lowest resistance. Therefore, we rate a hash function with a 160-bit output to be of strength "80 bits" (or 280). We know that we may be overly conservative here; be we cannot be sure.


Is the root certificate issued from one Certificate Authority is same for all the requesting organisation?

Yes, your understanding is correct, and it highlights some of the odd behaviour of how PKI (Public Key Infrastracture) works.
I will summarize your questions:

Will Verisign's root certificate be the same for all companies that it signs certificates for?

If two different companies get their certificates from Verisign, do they share a root CA?

Answer: It depends what product you buy from them.
According to Symantec SSL's (formerly Verisign) page "Buy or Renew SSL & TLS Certificates", they offer a number of different types of certificates:

Most of these will be issued off Symantec / Verisign's public CA. As you mention in your 3rd question, if you host a public website, then you want your site to be trusted by Firefox, Chrome, Safari, etc.
The "Internal Network" option is a bit different; Symantec offers something called "Symantec Private Certificate Authority" in which you get your own dedicated CA hierarchy. This means your company's users will need to install your root cert into their browsers / OSes, but you get more control over the format of your certificates, and most importantly your internal certs won't be published in the Certificate Transparency logs.

As a SSL site owner, if I get my certificate signed by Verisign, do I need to share that with my clients? Most of the browsers come with pre-installed root cert from popular CA like Verisign.

Answer: Correct.
That is the entire reason that publicly-trusted CAs exist: the certificate served by your webserver will chain to a root CA that the browser already trusts.

Summary
In general, all certificates issued by Verisign / Symantec will chain up to one of their publicly trusted root CAs, however Symantec does offer a Private Certificate Authority service, so some companies that get their internal network certificates from Symantec may in fact have their own private dedicated root CA (which is hosted / managed by Symantec).


Is It OK If a Server Does Not Verify a Certificate?

It is indeed mandatory to verify the certificate of the person you are talking to.

However, it makes no sense for the server to verify it's own certificate. It would be like you verifying your home key still opens your door or if you did changed the locks. In normal operations, you should already know this.

Checking the certificate of the server server-side is only useful to alert you on maintenance work that has to be done. After this, you make an informed decision to present the certificate you want. You risk the client not authenticating you and refusing communicating (what should be his normal behaviour with incorrect certificate being provided).


What are the advantages to using a VPN over secured/trusted wifi

If you control the network, there really isn't an advantage (under almost any circumstances). What a VPN does is simulate having a leased line from your computer to the network the VPN server is on. If you are already on that network, there is literally no advantage (unless you enjoy encryption overhead).

There is one main exception: if you control the network, but you cannot fully trust it, and the VPN server is on a separate network you can trust. For instance, if at a school you're worried people might tap into the cables somewhere on campus, but the VPN server and the routers to the Internet are all physically secured, you might not trust the campus network. Likewise, my guess is that ISPs have intranets that are separate from their networks they sell to clients, and that an ISP engineer might VPN from the ISP network even though it's the network they control.

It's important to note that using a VPN just means you're virtually on the network of the VPN server. If it is better to be on its network than the one you are physically on, you should use a VPN (for instance, if there's intranet stuff you need to access). For security purposes, you should use a VPN if and only if you trust the VPN server's network more than your own; it provides absolutely zero security past the VPN server; the only part of your communications that is secure is the path from the local network to the VPN server. If you're using some VPN provider that you trust more than your ISP (not necessarily a good idea, incidentally), then it can give advantages. If you're not worried about someone tapping the local network and you don't trust the VPN provider (and their ISP) more than you trust your network (and your ISP), it's stupid to use a VPN.


Problem with Reverse Engineering GVM light, possibly encoding issue

First things first. After stripping the Ethernet / IP headers from your packets and interpreting the payload as an ASCII string, we come up with the following values:
4C540900205700000100287A ⟵ turn on
4C540900205700000101385B ⟵ turn off
4C54090020570002010bF771 ⟵ set brightness to 11%
4C54090020570002013f81A6 ⟵ set brightness to 63%
Next, I obtained a copy of the APK, extracted the DEX file, and disassembled it. Fortunately the code was not obfuscated and it was very easy to see how the values were being generated.
From what I can tell, the payload is a string consisting of the following components:

The string 4C5409
The device ID (00 in your case)
The device type (20 in your case)
The string 57000
The command (1 character)
The string 01
The parameter (2-4 characters)
The CRC-16/XMODEM checksum*

* the checksum is computed by taking the concatenated value of the preceding components and interpreting it as hexadecimal byte values
The parameters differ based on what command is being sent to the device:
0 ⟶ set state (parameter is 00 for on and 01 for off - go figure)
2 ⟶ set brightness (parameter is percentage of intensity; for example: 63)
4 ⟶ set temperature (parameter is temperature; for example: 4500)


The Diceware FAQ has two entries that address this:

Why are there so many meaningless words like abc, du, rrrr or 456 in the Diceware list?
An important goal of Diceware is to keep passphrases short. Based on the limited survey I did, I concluded that most people simply will not accept a 50 character passphrase that they have to type in several times a day to read, send or sign e-mail. Peter Kwangjun Suk had the clever idea that short non-words like "abc" "456" or "dn" are about as easy to remember as regular words and reduce the average length of a randomly selected password.
Also, I never heard of ncaa, boise or a&p.
The original Diceware word list is slanted somewhat to American English. Alan Beale has compiled an alternative list that replaces most Americanisms and many obscure words with more recognizable alternatives. You can find it at http://world.std.com/~reinhold/beale.wordlist.asc
There are some obscure words in both lists. If you passphrase includes a word you don't know, look it up in a good dictionary. Learning the word's meaning will aid you memory and your vocabulary.

You're not the first person to raise your objection, however, and plenty of people disagree with Rheinhold's criteria.  The simplest solution is to use a different word list.  For example, the Electronic Frontier Foundation designed and published alternative word lists based on criteria that agree with your objection:

The Diceware list can provide strong security, but offers some challenges to usability. In particular, some of the words on the list can be hard to memorize, hard to spell, or easy to confuse with another word.

It contains many rare words such as buret, novo, vacuo
It contains unusual proper names such as della, ervin, eaton, moran
It contains a few strange letter sequences such as aaaa, ll, nbis
It contains some words with punctuation such as ain't, don't, he'll
It contains individual letters and non-word bigrams like tl, wq, zf
It contains numbers and variants such as 46, 99 and 99th
It contains many vulgar words
Diceware passwords need spaces to be correctly decoded, e.g. in and put are in the list as well as input.

Note that several of these problems are exacerbated for users with a soft keyboard or other typing systems that relies on word recognition. Using only valid dictionary words makes this setup much easier.

If you like the EFF word list better, just use that.  You're going to be typing quite a bit more, which I think illustrates Rheinhold's motivation:

The words in our list are longer (7.0 characters) on average, than Reinhold's Diceware list (4.3 characters). This is a result of banning words under 3 characters as well as prioritizing familiar words over short but unusual words.

For a 6-word passphrase with spaces between the words, that's 47 vs. 31 characters on average.


Any residual effects after SQLMAP has been run?

The SQL Injection vulnerability should have been reported in the pen test report along with guidance on how to fix it.

I would go back to the pen testers and ask them if you have any worries about what was done, if they didn't go further than enumerating the databases then metasploit payloads shouldn't have been uploaded to the server but definitely go back to them and ask if you have any doubts.

You should be able to see in the report how they exploited the vulnerability and from the information provided you should be able to reproduce it yourself.


How can I ensure that an android app was installed on a physical device and not an emulator?

I'm not sure that there is a way.  You could examine the hardware configuration to see if it is using any of they typical emulated hardware, but if someone modifies their emulator, it could be setup to look very close to actual hardware.  That is, in fact, the entire point of an emulator.  I'm also not sure what you are trying to prevent by ensuring that it is running on an actual device.  There isn't anything in particularly that I can think of that you can do with an emulator that you can't do with a physical device, unless you are also checking that root is not enabled, though a sophisticated attacker could probably bypass most checks of root as well.

Fundamentally, you can't secure hardware you can't trust.  If it is that critical, offload the process to a server that you have control of.  You have to trust your user and your user hardware if you want to do anything important on it.  Otherwise, the best you can do is obfuscate, but that is then the same realm as DRM and provides pretty minimal security.  If the device can do it, a user can figure out what the device is doing.  The only way to prevent that for sure is to prevent the user from having access to the device doing the work.


The main argument for local storage seems to be this:

  it is easier to protect against XSS than protecting against XSRF

The argument for that is that XSS is supposedly solved by automatic input sanitation, while CSRF is difficult to understand.

The second point may or may not be true, but - as your source states - complete protecting against CSRF is relatively simple. If your application is restful it is simply a matter of checking all POST requests for a CSRF token*.

XSS on the other hand is not that simple. Input sanitation is not the solution, encoding the output is. And the problem is that this encoding depends on context. Different encoding is for example needed if you are in a JavaScript or HTML context.

While some frameworks do provide templating engines with automatic encoding, others do not. And automatic encoding generally only HTML encodes, but does not consider XSS in a JavaScript context. Adding to that that many developers skip the templating engines in some cases and output user inputs directly, I would argue that XSS is more difficult to defend against than CSRF.

* This is a bit simplified, and there are other things to consider. HTML injection for example may leak CSRF tokens, and the application may actually use GET requests to change the server state.

Conclusion

I would disagree that XSS is easier to defend against than CSRF. As this is the main argument for local storage, I would go with the cookie approach. It provides small mitigation for XSS and also has the added benefit of ensuring that relevant data is only send over HTTPS (via the secure cookie attribute).


Can hash functions be used with CTR or OFB mode?

Angelo Rosiello and Roberto Carrozzo proposed this exact scheme (hash based OFB) in a 2005 paper called "ARC: a Synchronous stream cipher from hash functions" and showed that it is secure as long as a strong cryptographic hash function is used and the hash function is pseudo-random.

But the question is: why use a hash function instead of a block cipher? Block ciphers such as AES have proven more resilient over time to attack compared to hash functions. AES is generally faster than a SHA256 HMAC. What advantage is there to using HMAC for this?


Randomness of hash of (password + suffix)

Most common hash algorithms are designed to produce outputs that are indistinguishable from random, and as a result, even related inputs are not supposed to produce related outputs.  Therefore, generating multiple hashes with related input isn't intrinsically insecure.  You can use KMAC (related to SHA-3) and BLAKE2b as MACs and they can be used securely with related inputs in this way.
However, MD5, SHA-1, and SHA-2 are vulnerable to length-extension attacks.  That means that it is possible, given a hash and the original length of the input, to produce more hash values with the same prefix without knowing about the original input.  Therefore, you would not want to use this approach with one of those algorithms, because an attacker could possibly compute and compare additional values to see if they match.  The SHA-3 algorithms and BLAKE2b don't have this problem.
If your goal is to hash a password, though, you don't want to use a simple hash function using any construction.  Passwords typically don't contain a lot of entropy, and so you want to use a good password hash such as scrypt or Argon2i with a large salt and suitable iteration count.  You can either create a new salt for each use or generate a single salt and append a fixed-length counter.
If your secret isn't actually a password but instead a randomly generated secret with enough entropy (at least 128 bits), then you're probably better off using something like HMAC with a strong hash function, or HKDF if you want a key derivation function.  You can then provide the secret as the key and the counter as the message to hash, and this will both avoid length-extension attacks and also has much nicer provable security properties.
And, of course, you would never want to use MD5 or SHA-1 for any purpose.  They are both broken and you'd want to use something like SHA-2 (if you don't need to worry about length-extension attacks), SHA-3, or BLAKE2b.


How are possible uses for X.509 (SSL) certificates denoted?

X.509 "Key Usage" defines what the issuer allows the certificate to be used for. Remember that not all applications follow this requirement however.


Determining if company is considered a business associate under HIPAA?

IANAL, however as far as I understand it, it would depend if the court reporting company received access to any HIPAA protected information or not.  You do not get a business association for HIPAA purposes unless you are exchanging HIPAA protected data.  If you are, then you need to follow the BA standards for protecting the data assuming you don't otherwise do anything with the data that requires further levels of protection.


but will this also ban other innocent users for 1 hour sharing same
NAT network with attacker ?

If you ban an address, you ban everyone using that address. So yes, you could end up incidentally banning a lot of users, especially on large NAT'ed networks (e.g. mobile carrier-grade NAT).

If I ban IP address and port combination, will the attacker just use
other port?

Typically, the client's OS networking stack will use a new, random source port for every connection. So an attacker probably wouldn't even need to try to bypass this restriction.


When you use Google Authenticator, you can scan the code into multiple devices (iOS or Android). That way, loss of a single device won't lock you out, because you can always fall back to the original. Personally I store them on a old Android phone I no longer use.

All services 'should' allow you to register more than one yubikey per account, specifically for this reason. You should always have a spare yubikey when you use them as your 2FA device, otherwise you're forced into a tedious account recovery process when you lose them.

You're right to be worried about losing access to your account the moment you lose your second factor. But you should have multiple devices that store your second factor physically to avoid such a scenario.

As a separate answer mentions, I forgot about the recovery codes. These are special 2FA codes that are not time dependent and can be used in case of loss of a device. These codes are generally to be printed out physically, or stored somewhere else -- do not lose them!


Can a firewall blocking a guest virtual machine secure the host?

There are two main ways by which a corrupted/evil guest VM may hurt its host:

By talking to the host over the network; this is similar to having an evil machine on the same LAN as the host, although there can be details, depending on how networking works in your particular VM.
By "escaping" the virtualization layer, a successful escape granting (for instance) read/write access to the VM process on the host, or hypervisor hijack, or anything of the same level.

The second way is what "vendor security flaws" are about. If the VM implementation is secure, then it ought to prevent such occurrences.

Firewalls act on the network side of things, so that is relevant for the first way only. However, if you are working with potentially hostile VM, then you must, indeed, do something about network-based attacks, and that may involve firewalls.

In a typical VM, the host provides network services to the guest. These services are configurable. For instance, if you look at what Virtualbox provides, then the guest may:

have no network at all (the VM engine does not provide the guest with a virtual network interface);
have a network interface linked with other VM under the same engine, but separate from the actual Internet;
have a network interface linked with other VM and with the host, but otherwise separate from the Internet;
have a network interface that the host sees, and for which the host provides NAT service (but this does not correspond to an actual ethernet card on the host).
have a bridged network interface, allowing the VM to send and receive ethernet frames as if it was another physical machine connected to the LAN.

In the first two cases, the VM cannot talk to the host and that's final. In the cases 3 and 5, the VM can talk to the host through what the host sees as a network card (a new, software-based card in case 3; its actual physical card in case 5). In case 4, the host OS does not see the packets from the guest as packets; they are array of bytes in the VM engine process, but that process translates them as connections to other machines, which may be the host itself.

Firewalls have nothing to do with cases 1 and 2. A firewall may work with cases 3 and 5, albeit on distinct ethernet interfaces; beware that in those cases the hostile guest sends arbitrary ethernet frames, which may not necessarily show up on the link as relevant to the IP address you believe the guest should use. You should handle these situations in the same way as you would for an hostile machine linked to the LAN -- if you prefer, assume that your host is on an open WiFi in a fast food restaurant. For case 4, firewalls are irrelevant, because any connection to either the host or any other machine will appear to the host OS to come from the VM engine process itself.

The above is about what happens with Virtualbox; details may vary with other virtualization solutions.


If a password repeats a sequence of characters, does it become easier to crack?

Not exactly. More precisely:

For any given human-generated password (based on a known word or character sequence), repeating character sequences from that base word to create a longer password makes that specific password just a tiny bit harder to crack than the underlying base word ...
... but the resulting longer password will be inherently weaker than other passwords of the same length that were created using a stronger length-extension method ...
... and it's hard for a password-strength meter to tell the difference.

To understand why, we need an understanding both of human password memorization strategies - and of the limitations of password strength meters.

A human password strategy like duplicating letters is a common way to meet password length requirements because the incremental cognitive burden for the user is low (only requiring the user to remember a little bit more information.) For example, if the minimum password length requirement was 12, then a password paaaaassword meets that requirement, with the user only having to remember two things:

My password starts with the word password as a base.
I then just repeat the a four more times.

Increasing password length with a "trick" only marginally improves attack resistance. While the raw Shannon entropy of the new password is higher, the effective entropy of the new password is only very slightly higher than the base word itself - because it's really only one more piece of additional information - which means that it can be easily used by attackers. Many password-lengthening strategies (adding digits, adding a couple of common special characters, doubling the word, etc.) are very well-known to password crackers. Most cracking software can try these strategies at very high speeds.

So strategies like adding repeating characters to a human-generated password are easy to implement in a password attack ... but they are much more difficult to implement in a password-strength meter.

This is why password-strength meters are notoriously inaccurate.  A meter can use broad general measurements of strength (complexity, composition rules), and approximate some of the basic attacks (masks, simple wordlists, etc.) ... but it is impossible for a meter to mimic the millions of combinations of base words and human password-generation rules ... without starting to behave more and more like a password cracking engine. And such meters need to be much faster than that, in order to give real-time feedback to the user.

So the strategy of repeating characters only marginally increases the effective entropy, which will fall to high-speed attacks ... but the password-strength meter can't use the same attack strategies to tell the difference.


Is a yubikey with OpenPGP applet more secure then saving the private key in a encrypted USB stick?

With Yubikey the private key does not leave the stick. Any cryptographic operations which need the private key are executed on the Yubikey itself. This is the same concept you have with other kinds of smartcards.

Contrary to an encrypted USB stick the private key is thus never accessible on the computer. If an attacker has compromised the system he can at most trick you into signing something you don't want with Yubikey plugged in. But with the encrypted USB stick mounted the attacker can actually steal your private key and thus use it whenever he wants even outside of your system.


What is the difference between Ghidra and Ida?

This is largely subjective, but:

Ghidra is free and open-source on GitHub, including the decompiler. IDA is very expensive, particularly when you start adding the decompiler licenses.
IDA supports some architectures that Ghidra doesn't, and vice versa.
IDA has a debugger whereas Ghidra does not.
Ghidra has the ability to load multiple binaries at once into a project, whereas IDA support for this is limited and mostly an ugly hack. This means that you can trace code between an application and its libraries more easily.
Ghidra's disassembler has data flow analysis built in, showing you where data can come from when you click a register or variable. IDA has "dumb" text highlighting to show other uses of that register. These features are slightly different implementations of the same concept and both have their uses.
Ghidra has collaborative disassembly/decompiler projects built in by design, whereas IDA requires plugins to do collaboration and the IDA database files are not designed to be shared.
Ghidra has an undo button! And it works! (IDA doesn't and it's super annoying)
IDA is way more mature and has a lot of little features that have been added over the years that Ghidra cannot (yet) mirror.
Since IDA is a more mature and ubiquitous product, there are a lot of open-source tools built around it.
Ghidra appears to have better support for very large (1GB+) firmware images with decent performance. It also doesn't have problems with analysing firmware images that declare large memory regions. IDA historicallly has had problems with this and it can be quite frustrating.
Anecdotally, Ghidra's support for disassembling Windows OS binaries (e.g. kernelbase.dll) is currently broken due to some bugs with the x86 instruction decoder. There are issues on GitHub talking about this.

These points are true at time of writing (March 2019) but may change over time.


Securing firefox to me means a vanilla copy of firefox which disables password and history collection, deletes cache and cookies after closing, no add on installation, and whitelists specified sites. The above can be done via Firefox's options.

To Whitelist sites:

Open Tools->Options...->General->Connection Settings...
Select "Manual Proxy Configuration"
Check "Use the same proxy for all protocols"
Type in a bogus host (0.0.0.0) for HTTP proxy
In "No proxy for", list your whitelist of websites

Source: http://forums.mozillazine.org/viewtopic.php?f=8&t=287280


Is it ok to use the same SSL certificate for both HTTPS and SOAP-level signing/encryption?

Ok so without wanting to answer with "depends", here's my thoughts on this.

Signing the SOAP messages with a certificate provides the ability for legal non-repudiation of the message contents.

You're right that having the same cert used means that you're potentially over exposing the key.

So this is where the "depends" comes in.

If your use case is to provide assurance that the message is being sent, unchanged, by who it's signed by, then you're doing this wrong, and you should use separate certs and treat them properly.

If your use case is more to simply verify that the message body has not been tampered with in general and that it's been signed by something that has access to this shared private key, then I'd be ok with it personally.

Cheers,
Pete


Google suspicious activity warning persists for 4 days despite my confirming I recognize it, does this indicate additional security issue?

Google suspicious activity warning persists for 4 days despite my confirming I recognize it

This behavior is intentional. If an attacker had gained access to your account, allowing the warning to be dismissed would allow the attacker to dismiss the warning before you were able to see it.


Password prompt before en-/decryption to prevent Side Channel Attacks on FPGA?

"FPGA" is mostly a red herring here.

Side-channel attacks try to exploit leaks of secret data element when a system uses the said elements. Leakage can occur in a variety of physical ways, such as energy consumption, processing time, emitted radio waves...

IF:

you have a system which contains a secret element;
AND that system may leak information when using the secret element;
BUT the system will refuse to work until an authorized owner has been duly authenticated;

THEN side-channel attacks won't apply even if the device has come under physical control of the attacker: the attacker won't be able to make the device leak the secret because the device will simply refuse to run the operations which could leak.

HOWEVER this is all relative to some core assumptions which are not necessarily true:

This assumes that the authentication mechanism cannot be broken, though that one can be exercised at will by the attacker.
This also assumes that the device is tamper-resistant: even if the device refuses to use the secret, it still contains it. The attacker has physical access to the device and may try to break it apart and plunder its contents directly. A FPGA is not necessarily tamper-resistant. Since it is a physical chip, it may have been shielded and enhanced with tamper resistance features, but that's not a given. Some FPGA claim tamper-resistance, to some extent (the Devil is in the details, as usual).

As for open-source FPGA implementations, they are not as widespread as their software counterparts, but there is a growing trend for that as well. See for instance OpenCores, which tries to aggregate information about available open-source designs for FPGA and ASIC.


Change from bcrypt hashes to sha1 or even plaintext, for performance

A 128-bit GUID v4 has 122 random bits. According to RFC 4122 § 4.4, six of the bits are fixed, with 122 remaining bits being random. Assuming the random number generator source you use is cryptographically secure, a key generated in this way will have a keyspace of 2122, which is plenty. If it is used as a key to authenticate to your service, you do not need to bring it through a slow KDF. Slow KDFs are designed to make weak human-generated passwords slightly harder to break. If the key is already too large to break, the only thing required when deriving the hash is the use of a one-way function. You can safely pass the key through a single round of SHA-1 or even MD5 (these hashes are vulnerable to collisions, but not preimages which are what matter in the context of password hashing). You do not need to use a salt either, since each key will already be be distinct.


What is stopping me from replaying an SSL certificate?

When a CA signs a certificate they encrypt a hash which includes the host name of the certificate target using their private key. When the client receives the certificate they decrypt the hash using the public key for the CA (which is baked into the client) and check that it matches the hash calculated by the client. If the hashes don't match then validation fails and the connection should be aborted.

If you modify the certificate to change the host name then the hashes won't match
If you try and sign the certificate again (ie. replace the hash with your own) then the client won't trust it because it wasn't signed by one of their trusted CAs.
If you try and present a legitimately signed certificate for another domain then obviously the validation will also fail because the domain doesn't match.

Of course the above assumes the client validates certificates correctly, which is not always the case.


Fingerprint FTP services without Banner message

The standard tool on Kali is nmap, specifically with the -sV or -A option.

If that doesn't detect your application or version properly, you can contact the developers.

You may be able to dig through the nmap source code to figure out how their detection works, but consider yourself warned: detection routines almost always includes a massive pile of regular expressions to puzzle through.

I've found nmap to be fairly reliable, but we don't run any of the daemons you've listed so I don't know if it can detect those.


There's two aspects to your question:

Is a JWT token exploitable if it can be signed with the "none" algorithm?

Absolutely, yes.

Does it matter in your specific case where only a certain type of information is handled by the token that you know to be safe if tampered with?

Entirely up to you. This is the context that weighs the business risk of a particular issue.
From a development point of view, I suggest you disable the "none" signature algorithm and save yourself headaches and potential compromise when in the future you use the JWT token in a slightly different way and forget about this issue.
Here's a couple of resources:

https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/
https://medium.com/101-writeups/hacking-json-web-token-jwt-233fe6c862e6


Can counter-based OTPs instantly be reused at multiple services?

Am I correct or am I missing something? How is this dealt with?

No. You're right. This is up to the backend to deal with. If it doesn't do anything about that then that's just the way that is.

To counter this you could e.g.

imagine something like keeping a centralized round robin database of the last five minutes of used codes. (Assuming that after 5 minutes or so, they're expired anyway and you can remove them from the database.

It seems that Drupal can do that:

  New table stores salted hash of accepted TOTP codes to prevent replay attack. TOTP plugin rejects codes that are stored. Stored codes are cleared on cron after 1 day,

It seems that FreeIPA also does this

  We will implement a watermark system which records that last interval used.

Only accept the TOTP via HTTPS, so it is harder to intercept in the first place.


Streaming over a webpage might not be a good solution. Because a web page can be accessed by multiple users at same time and if you are streaming data over it, There are chances that anyone can get access to it.

In my view a simple web solution could be using SFTP to transfer your files. But that again at the same time did not solve your problem to remove the audio file once this has been played. Because the other user will have a copy on there machine after file transfer.

But if that's not compulsory SFTP would help you.


How to defend vs. Image Remote File Inclusion, e.g. RFI using a .gif file (Apache/PHP)?

Your PHP code should never evaluate a data file. It may print out the content of an image file, but include()ing an image file is an insane use of code. I strongly assume that what you're doing is using PHP code to serve images, and because PHP doesn't evaluate anything that isn't between "<? ?>" tags, this works in most instances. That is definitely the wrong approach.

You may be looking for the readfile() function.

Other than that, don't write include statements that take external input.


When I try to SSH into my computer through its public IP the server's host key fingerprint is different?

Welp, I'm an idiot. It turns out I forgot to change the port I was connecting to from 22 to the port I set to port forward from on my router. Strange that my router accepts its own ssh connections on port 22 though.