Does error checking for SPF Records make sense? I've made an SPF Record for my company domain and I took great carefulness to have it done properly without any errors.

I've also set up our mailgateway to check SPF Records of all incoming emails from 3rd parties.

The mailgateway checks two things:

Is the SPF record valid (i.e. does it have errors) and if not
Does the mail connection match the defined addresses in the SPF Record

My general problem now is that it seems as if an overwhelming majority of 3rd parties that send emails to us seem to get their SPF Records wrong. (about 90% of rejected emails are based on syntax errors, wrong use of options, etc.).

For example:

v=spf1 a mx a:mail.company.com~all (where there's is a space missing therefore mail.company.com~all cannot be resolved)
v=spf1 a include:mail.company.com ~all (where the include can't resolve an SPF Record from that domain and a:mail.company.com should have been used.)

and other things like that.

I'm kind of getting annoyed at telling other people how to fix their records. Especially when it happens with pretty big companies (at least for my country)
So I'm asking myself, does it even make sense to check the record for such errors?

Or should one treat those records as if they do not exist?

On the one hand I think I should check them, by having a SPF Record those Domains "ask" me to validate everything so I feel compelled to do so when receiving a mail, if someone tried to forge an email from that company with something like a payment notice, they obviously want me to check that the mail is in fact valid. On the other hand, it seems as if they do not really care or they would have checked everything themselves.

The RFC for SPF addresses this case: an invalid SPF record will result in a PermError.

But there are no clear rules how to deal with a PermError: the mail might be rejected (thus making the sender aware of the problems) or it might be forwarded. In the latter case it might be useful to include the information into the mail, i.e. add an Received-SPF header with the PermError status so that spam filters upstream (like in the MUA itself) can take this SPF status into account.

Given that according to your information you deal with lots of invalid SPF records even from major companies rejecting such mails is probably a bad idea. I would thus suggest to forward the mails but include an Received-SPF header with the PermError status and details about the error as comment.


gpg ignores passphrase on my key stored on yubikey 5 nfc I just set-up my yubikey 5 nfc with 3 seperate subkeys (S, E, A).

While encrypting and decrypting works fine (self-tested), I'm questioning the fact that gpg only ever asks me for the yubikey's pgp pin when performing decryption operations, but never actually asks me about the passphrase I protected the master key with (which I understand should have been inherited by each subkey).

I'm on windows but have already tried manually settings max cache times in gpg-agent.conf to 1, so as to "force" no-caching.

Can someone please shed some light on this behaviour?

Cheers

Encryption with GPG works using Public-key cryptography. All encryption is done with your public key (hence no password required here).

The password of your GPG master key is only used during creation of your subkeys. It works more like a CA here verifying that your subkeys are validated by your master key.

You're probably referring to guides like this where it says

  The Master and subkeys will be encrypted with your passphrase when exported.

Which is true for your exported keys as a file.

So basically what you'll end up with after setting up your YubiKey like that is some GPG smartcard protected with your YubiKeys pin.


Is there a john doe of the internet (not anonymous)? Anonymous is one of the most interesting things in culture these days (imo), but if one were to make anything and put the name "Anon" on it, it might come off as either undesirable to the loosely organized Anonymous, or self targeting as part of a larger threat.

Is there a more name like, possibly comedic, widely used filler for unknown people?  Something like "Bob Dole, or John Madden, or John Doe."  Where it's not "legion" political but is still used enough it's hard to glean anything from it?

Maybe some past famous hacker...

Basically, something anonymous that isn't "Anonymous"

Alice and Bob are widely accepted placeholders for describing interactions in an information security context.

Bob and Alice are generally legitimate entities, but there's a whole suite of associated names which are attached to certain types of attackers or involved parties. For example Mallory is used for a general malicious entity or Eve for a man-in-the-middle (eavesdropper).

I wouldn't use these terms to describe a specific unknown entity in a specific scenario, but if you were describing the sequence of events in abstract terms then they might be appropriate.


Can you secure a web app from FireSheep without using SSL? Assume that you want to give some web users privileged access to your website, but that you are unable (or unwilling) to offer SSL to all of them - at least past the initial login page.

In this instance, is there some way to manage the user session that will negate FireSheep, but not create a painful user experience?

You could avoid the current Firesheep via some "security thru obscurity" scheme involving authentication via dynamic session management as discussed here.  You can use "Digest Authentication" (RFC 2617), but that is still vulnerable to a MITM attack, degrades the user experience and requires the server to store your password (or a password equivalent) in the clear.

But avoiding SSL/TLS would not get around the two fundamental problems that without encryption: (1) all the private content is shared in the open, and (2) a determined attacker could figure your scheme out and defeat it.

See some cute examples of active attacks, mythbusting about performance penalties, and specific advice on deploying SSL from EFF: How to Deploy HTTPS Correctly.  Note also the Stack Overflow meta discussion on why it hasn't been fixed on Stack Overflow (yet).

Note that the exposure for common sites is worse than I initially thought.  E.g. note this wrinkle as the Firesheep author explains in a great post

  You can’t simply avoid visiting the
  sites that are being attacked here.
  There’s an enormous amount of mixed
  content on the web today, such as the
  Facebook “Like” button, Digg’s “Digg
  It” button, twitter widgets, and even
  embedded images that are hosted on
  Flickr or other photo sharing sites.
  Every time you access any web page
  that includes any of this content,
  your browser also sends any
  authentication cookies you have with
  the request to pull down the widget.

You can at least fix the errors he discusses there (like actually invalidating session cookies when a user logs out!!).

You can also advise your users on how to protect themselves to some degree from these "sidejacking" attacks, e.g. to use a VPN or find a WPA2 wifi network (but see WPA2 issues here).

Thanks to @D.W. for a link to the best-thought-out interim approach I've seen: SessionLock Lite by Ben Adida.  It at least prevents persistent hijacks by passive attackers: Benlog » keep your hands off my session cookies.  Just don't stop there - engineer an SSL deployment....


In Diffie-Hellman, why is the shared secret guaranteed to be the same? In general, I understand the principle of Diffie-Hellman key exchange. What I don't understand is what is so fundamental about primitive roots modulo p that guarantees that the shared secret is the same. I'll use the notation similar from the Wikipedia Diffie-Hellman Key Exchange article,
Alice has private key, a.
Alice generates her public key, A = g^a (mod p)
Bob has private key, b.
Bob generates his public key, B = g^b (mod p)
Alice sends her public key, A, to Bob.
Bob sends his public key, B, to Alice.
Alice generates the shared secret key, s = B^a (mod p) = [g^b (mod p)]^a (mod p)
Bob generates the shared secret key, s = A^b (mod p) = [g^a (mod p)]^b (mod p)
(I'm aware that Bob and Alice only have access to capital A, and B, respectively, just expanding out the expression to show the private key inputs)
Why is it necessarily true then that:
[g^b (mod p)]^a (mod p) = [g^a (mod p)]^b (mod p)
?
Maybe I just don't understand the "rules" of modular operations. Does the (mod p) just come outside the exponents somehow? Then you just get g^ba (mod p) = g^ab (mod p), which would make sense.
Any good references for this? Been searching around and not finding a clear cut explanation.
Thanks.
Edit: Left out some of the "mod p"'s in the expressions. I have since learned that the public keys A and B are guaranteed to be coprimes of p, so it more or less boils down to the question: "why are coprimes of p, raised to some power (a or b in this case) then divide by p and get the remainder, guaranteed to be equal?". Also if this isn't the right place for this question, please let me know. I know it leans more math side but the math resources I'm looking at don't seem specific enough to answer my question.
Edit 2: I understand the principle behind Diffie-Hellman key exchange; specifically, I'm asking if anyone intuitively (or verbosely) understands the rules of modular arithmetic enough to explain why the secret key that's generated on both sides is guaranteed to be the same.

I found an answer to my own question here on math SE (so this can be deleted, or left for reference):
https://math.stackexchange.com/questions/61358/prove-equivalence-of-diffie-hellman-shared-secret


Why does Google prefer ECDHE-RSA-AES128-GCM-SHA256? I want to configure my new mail server secure as possible and wondering about the used cipher while connecting to Googles SMTP server.

I'm curious why they prefer the cipher ECDHE-RSA-AES128-GCM-SHA256 before ECDHE-RSA-AES256-GCM-SHA384? Isn't this weaker?

When I test with openssl s_client -connect gmail-smtp-in.l.google.com:25 -starttls smtp -cipher ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256 the connection negotiates with cipher ECDHE-RSA-AES128-GCM-SHA256.
If I present only cipher ECDHE-RSA-AES256-GCM-SHA384 to the server it uses them.

The most important question: is there a way to force postfix to use only the strongest cipher? If I exclude AES128 via tls_policy it gets even worse!

AES-128 is not in practice weaker than AES-256. AES-128 is sufficiently robust that it won't be broken through exhaustive search on the key (see this answer for some details), and an algorithm cannot be "less broken" than "not broken", so there is no additional benefit for security from cranking up the key size to 256 bits.

(There are benefits for marketing, though: longer keys can woo the non-technical minds.)

On the other hand, there is a practical disadvantage to using AES-256: it uses 40% extra CPU when compared to AES-128. This may matter for a server that has very fast network connectivity (say, 10 Gbit optic fibre) or has a feeble CPU. I suspect Google's SMTP server is of the former kind: powerful, but handling lots of incoming data.


Should I redirect http request to https from my system's application or from DNS or other? I want to create a web server that does redirects HTTP to HTTPS. What is the simplest method to do this but also secure? Should the DNS handle this? (For example, Route53)
I used to do this with my app built from Node/Express but now that I am using a compiled language, I want to be able to do this by hand instead of relying on a framework.
If I configure DNS to redirect http to https, is that more secure than the server program? (My thinking here is that since the server never sent a response, the potential attacker's req never arrived and thus has no message to receive.)
Would it matter which DNS does this? (For example, if you purchased your domain from domain.com but your server is on AWS linked through Route53?)

DNS cannot do this because DNS doesn't know anything about the protocol. It just turns a domain name into an IP address, so has no way to know whether the person making the request is using HTTP or HTTPS.
If you don't want to worry about handling this redirect in your application then you could handle it at the load balancer which (depending on the details) can be protocol-aware.
For AWS (which I bring up because it seems like you are using it) this means using an application load balancer (ALB) which can perform the redirect natively without additional infrastructure. It will also act as an SSL termination endpoint for your application.
From a security perspective there isn't much of a difference here - it is mainly about what is most convenient for you to maintain


Someone has my ip address and is threatining to find and leak my personal information I was posting on a website forum. A person that doesnt like me on there managed to find out my ipv4 address.

I called my isp and asked them to change it, they told me to unplug my router and wait. I checked and my ipv4 address is still the same but my ipv6 address is different.

Am I in danger of being hacked or a signifigant security risk? I dont think I can do anything to stop them from finding my personal information but im worried that they might try to hack me or tell someone else to. What should I do?

I went into my router settings and changed the password as well as making sure all the firewall settings were selected and on max security.

Don't worry too much

It is relatively easy for someone to get your IP address, they just need to get you to visit a website they control. Some forums let people include links to images, which your browser will automatically load and reveal your IP address.

Normally this doesn't let them do much. They can work out your ISP and approximate location, but usually not any other personal information. Potentially they can connect your IP with other online activity, but that's more a Google/NSA thing than some guy on a forum.

You are absolutely right to lock down your router. Knowing your IP does allow them to try to attack your router. Even with a strong password, many routers have had vulnerabilities that allow compromise. But if your router's firewall blocks all ports, you should be ok. You can verify this using an online service like this.

If revealing your ISP and approximate location troubles you, I suggest you use a VPN. They are pretty cheap and easy to use.


How can winlock virus change Windows Registry without admin permission? When you try to install program you'll always asked about administrator permission. Same thing when you try to user 'regedit' command.

So I'm interested in how does this virus works. How can it edit Shell and userInit in registry without asking any permission?

The user part of the registry(HKey_Current_User) is writable by unprivileged applications.

The machine part of the registry (HKey_Local_Machine) is only writable by privileged programs.
Some subkeys might require different permissions, but this is true for most keys

To change the shell for the current user, you can modify HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell, which is in the user part of the registry, and thus probably writable by unprivileged applications.


Ways to hide injected dll? So if I inject my dll to a pprocess (or all running processes, including AVs) and it hooks some functions, why can't I just simply hook the functions (WinAPI functions) that could detect my injection and hook process? But the thing is, I don't know what API does AVs use to detect it. Do you know any? Or does AVs even use WINAPI to detect these hooks? or injections?

Just some questions:
 * What possible WinAPI can be used to detect injected dll's or unknown threads (from CreateRemoteThread?)? Like, maybe an API that enumerate's all dll process or threads.
* If I hooks those functions, should I be able to hide my hook?

What I'm talking about here is that, can't I hook the functions that AVs use to detect my malicous activity?

The chief problem with your approach is that a process doesn't need any API to check its own address space. It can just read from it; that's pretty much the definition of its address space. So an AV product can set up a "bait" process which knows what should and should not be running in its address space, and catch unexpected code.

Would you know how this bait process looks? Not realistically. The AV code can generate this bait process on the fly, so it's different every time. For another AV product this would look awfully fishy, hence the advise to never run two AV products in parallel.

There's one slight complication with this method: your hooks could be somewhat stealthy, and actually be generated on the fly via an exception handler. But this exception handler itself has to exist, and can be detected instead.


Is there any authoritative classification of vulnerabilities? Is there any classification of vulnerabilities ?
As we know, there are many vulnerabilities, such as:
SQL injection vulnerability, File upload vulnerability, File contains vulnerability, XSS, SSRF, XXE,  database leak  and so on.
but I did not find an authoritative classification of vulnerabilities.
who can give authoritative classification of them?
such as category about Operation System / Web application / Networking.
and under the Web application vulnerability, there should have XSS/SSRF/XXE....

You may review security testing frameworks and methodology; the group you mentioned falls under The Open Web Application Security Project® (OWASP).
https://owasp.org/www-project-top-ten/
For non-web control such as Human, Physical, Wireless, Telecommunications, and  Networks, you may consider the OSSTMM framework.
Both OWASP and OSSTMM are security testing methodologies; OWASP is considered BlackBox testing, whereas the OSSTMM is gray-box testing.
The vulnerabilites can be scored using for example

CVSS common vulnerabilities scoring system
CWSS common weakness scoring system
CWE Common Weakness Enumeration

Please note:
At the end of any of the testing practice of VAPT, you as tester need to include the scoring system in your report, so you can grantee unified understanding of the risk between you business owner the coming integrator.


Safe way to backup Bitcoin hardware wallet On official site they (Trezor) emphasize that you should never store your recovery seed digitally. But this seems to me absolutely strange. First of all we live in 21st century. And paper (or even steel) backup is easy to lose and you cannot easily password-protect them.

So I was thinking about using a separate keepass database that is stored on multiple devices and clouds, BUT is decrypted only in safe environment. For safe environment I choose live Tails system.
I believe such approach is good because:

Much harder to loose my seed
Much easier to store
Still cannot be hacked, decrypted not by me, keyloggers won't work
This db is supposed to be used only in emergency case, so it is feasible to spend like 30-60 minutes just to recover my seed, because it won't happen often

The only risk is to forget encryption password since I am not going to use it often - so I will create some schedule to recall & check it like once a week.

Are there any drawbacks I don't see?

There are other risks, for example your hardware may be compromised. Purism attempts to mitigate the vulnerabilities popping up in intel chips as just one example, but do they succeed? Hard to say, intel chips are not open hardware. The idea of chips that can be remotely exploited when your computer is 'turned off' is kinda scary, but I'd caution this is only one example.
https://puri.sm/learn/avoiding-intel-amt/

One thing hardware wallets attempt to do is to mitigate risk of malicious hardware (other than the wallet itself of course), so just be aware that trusting your key to other hardware extends your trust also to that other feature rich, and thus target rich software AND hardware stack. Whether that risk is ok or not is of course a judgement call.

There is another approach I've been tempted by, but BIP 39's use of SHA-256 for a checksum gets in the way. I'll ask Trezor if they could add optional hex bypass (sans checksum) to BIP 39 during recovery, for advanced users.
http://ben.mord.io/2017/11/paper-pencil-seed-generation-from.html


Alternate Workstation Lock mechanism We're all aware of the need for physical security. Everytihng from locks on doors to locking your computer when you leave it.

I'm having trouble with some people leaving their stations up as they head away from it. I can mess with settings like timeouts but then it sometimes times out while they're reading etc... Any suggestions for a way to make these stations know when the users (HR Manager, President, Manufacturing director....) get away from the terminal?

I saw Securing Windows 7 using Bluetooth ,but I've tried this and it doesn't work well and requires a headset connection to a device like your phone. Kludgy solution at best. Suggestions?

You want a system which can somehow detect the difference between:

The user is on the chair in front of his computer, looking intently at the screen (for "reading") but not otherwise making his presence known to the computer.

and:

The user is on the chair in front of his computer, looking intently at the back of his eyelids, because he is taking a quick nap.

Said that way, it becomes rather obvious that the problem is hard. You could imagine plugging a Webcam to the computer, focused on the user's face and able to detect whether his eyes are shut or open... this seems kludgy. However, such a product is apparently on the market. You might want to give it a try -- not for automatic login (it is too easy to fool a face recognition system with a life-size photograph of the user), but for the automatic lock when the user leaves the room. Of course, this requires Webcams. Laptop computers have them.

The normal way to deal with unsolvable problems is to change the problem until it matches a solution. The common method, in this case, is to "empower" the users. This takes the form of a tradition of users jumping on each other's machines: if you find an unlocked workstation, then you send an email to the whole floor in the name of the workstation owner. The said user is then "forced" (through social pressure, not contractually -- it would probably be illegal) to pay for cookies or beers for everybody on the floor. If done properly, then the rate of unlocked workstations can significantly drop.

Unfortunately, this does not work well with people whose hierarchical level is higher than their sense of humour. The same people will also be uncooperative with any technological constraints. For instance, you could enforce smart card logon (with USB-token form factor, and automatic locking when the card is extracted) and have the users keep the smart card tethered to their wrist of belt at all times. It can be easily predicted that the users will not keep the USB token attached.

This issue is widespread. As an example, the French government just recently issued a reminder to its own ministers that they are not supposed to use "not approved" smartphones, and yet they do. Similarly, Barack Obama, upon becoming president, adamantly refused to let go of his phone, to the dismay of the Secret Service.

For people at the top management positions, the most practical method might be to simply hire an underling whose job is to type Win-L whenever his boss leaves the room. If that employee is decorative enough (which, in many cases, means that the employee is a she and is young) then such a plan will meet user approval, and be effective.


Vulnerability management benchmarks Despite the continuous effort in our company to resolve vulnerabilities,  we are still reporting a significant number of vulnerabilities after each scan we perform.

We would like to understand if there are industry benchmarks or ratios, like number of vulnerabilities per asset out there that we can use to compare ourselves with.

Is any of you aware of any industry benchmark in this regard?

I think you are asking the wrong question. Consider the following:

If you fix fewer vulnerabilities than emerge between scans, then the number of vulnerabilities will only go up (10 vulns - 3 fixes + 4 new vulns = 11)
If you do not fix all vulnerabilities, you will never get to 0
Scans can have false positives that you need to verify
Some vulnerabilities you might never fix or choose not to fix

So, the relevant question is "why is the number not going down the way you like?"

"Industry averages for vulnerabilities per asset" is impossible and a little silly. Printers, Windows 10, Windows XP, and Linux, for example, are a vastly complex set of assets that you cannot compare to each other. Strictly speaking, if the scanner's results are not false positives, you should get the vulnerabilities down to 0.

BUT

Are the existing vulnerabilities a problem for you? Just because the scanner reports something does not mean that it needs to be fixed. The vulnerabilities might not apply to the asset in the context you have it in. That's why a risk-based approach to assessing the vulnerabilities is required.

For example, I have organisations that are running Windows XP on business-critical systems. We can't change them. Scanners light up like a Christmas tree when they scan them. But the vulnerabilities cannot be "fixed". We put in other mitigations to protect the organisation. The "vulnerability" metrics will never change for those systems, but we also have accepted that reality.

In short, don't look to "industry benchmarks". You need to set the benchmark that makes sense for your organisation, based on risk, context, and your ability to resolve vulnerabilities.


Port-Forwarding insecure? I was going to do port-forwarding to create a gaming server with an old PC. I the found out that it makes more things visible to the internet. Is port-forwarding a bad choice considering its insecurities? Also, how will I able to protect my internet and computer if I were to port-forward?

Tehcnically, yes..

Port forwarding allows external internet connections to contact your router, which then will FORWARD the connection to your computer's internal IP address. After the connection reaches your IP address, it will give input to the server you're running on your computer. So the security will be dependent on how secure the game server software is.

.. But not likely.

I wouldn't be too concerned. From my experience of hosting game servers and helping manage them for years, you're hardly ever targeted, and when you are it's usually just a DDoS attack. It would be very out of the ordinary for an attacker to have some exploit for your game server.


Diffie Hellman Key Exchange in a messaging application I'm currently a student that is trying to develop a messaging application on android using java that will implement diffie hellman key exchange in order to ensure that they both will be able to calculate a secret key to decrypt the content that are send within the text.

I have looked for various sources online, but I could not find a library or able to made my own diffie hellman key exchange occur within the app itself. Such as if I use mobile A to generate the key, how does mobile B receive that data and know that it is the public key? Also, once the public key is received, how does he generate his own private key based on the public key?

I have looked at the various sources such as
https://stackoverflow.com/questions/34237971/conducting-diffie-hellman-between-java-and-crypto-c
http://docstore.mik.ua/orelly/java-ent/security/ch13_07.htm
http://www.java2s.com/Tutorial/Java/0490__Security/ImplementingtheDiffieHellmankeyexchange.htm

and many more, but it seems like the codes that they provide is more for running within the app where there are 2 users in the device, and not within the app, but 1 user per device.

Sorry for the trouble, thanks!

To get a good picture of the Diffie Hellman Key Exchange some diagramatic representations may be helpful.

The common approach for messaging applications on Android (or any other client devices) in Java (or any other language) is to utilize TLS usually in conjunction with HTTPS to authenticate, authorize, and securely communicate the plain text message through a secure stream containing the cipher text representations between peers.

The likelihood of implementing a secure homemade version of a Diffie Hellman Key Exchange without a few years of experience is small.  One fact that may clarify the bigger picture is that security in private-public cryptography relies on Certificate Authority involvement as part of authentication.  JSA (Java Security Architecture) gives you some options to employ all that between peers and in the absence of a web server, but at a higher level.

The relationship between the private and public key is designed such that the private key cannot practically be calculated from the public key, so don't bother trying to find a way to do that.

Another highly secure alternative would be to use a one time pad, which will probably not be practical for your application at all.

If both devices have the same secret (which was agreed upon in advance) you could simply use a symmetric algorithm on both peers, but it would require a strong password to be stored on both devices or remembered by both users.


Is it safer to use a PGP key encrypted with a password than just the same password separately? I'd like to encrypt some master passwords that I want to store with added security outside of KeePass, instead as just a normal record in the database. I was considering storing these passwords in an encrypted RAR file, but now I think that could not be a very good idea since it could be possible that there is some bug/backdoor in the RAR library that could make cracking it easily.

I'd like to consider encrypting the master passwords with GnuPGP (AES) with a combination of a key instead of plain passwords. Now I'd like to know if it would be more secure to encrypt the master passwords with the key instead of with just AES and the password. Because wouldn't it be more resource intensive to bruteforce an encryption key to retrieve the password that it's encrypted with than just to bruteforce the AES encrypted file to find out the password?

depends on your key length, but think of a key as the first "long"(hashed) version of your password (used in proper used cryptographic that is) so, in short its impossible to answer.

But when used with a appropriate long key file, it can be a lot more secure than a password.


I tried to break my WiFi: is 8 uppercase letter strong enough? My Wi-Fi WPA-PSK password looked pretty weak: 8 uppercase letter. I have checked with another router from the same provider and the pattern is the same.

To see how weak this is I tried to hack it myself, under the assumption that I only knew the above.

I have never done anything like this but I am a decent Linux user, so I tried following an online tutorial using the Aircrack suite and captured the handshake. Then I set off to write my own dictionary (generating all combos of 8 uppercase letter). I soon realized that the file needed to store it would require 26^8 * 8 * 1 byte ~ 2 TB. A bit impractical for casual intruders without some dedicated hardware (e.g. me right now), and I'd figure that one could easily make the number unbearable rather quickly by allowing numbers, cases and symbols.

Does this make such a password quite secure from most amateurs? Or are there ways to circumvent this (smarter attacks, compression of the dictionary file, having a software that streams the dictionary rather than storing it on disk etc.)?

Personally, I don't think that 8 character (uppercase) is strong enough to withstand a determined attacker. Using only uppercase characters we have,

268 = 208827064576 possible permutations.

If we add lowercase to the mix we can increase this to

528 = 5.3459729e+13 permutations.

As you can see by increasing the character set we increase the amount of time required to bruteforce by a massive amount. I personally recomend using an alpha-numeric PSK that is 12 characters minimum.

Researchers show the practical implications of weak PSKs in the following entry with a budget of only 200(Euros),

https://www.exploit-db.com/exploits/34307/

The biggest bottleneck most people would have is the harddrive size however it's relatively cheap to buy harddrives large enough to make this feasible. Using modern hardware and a bigger budget it would be trivial to bruteforce an 8 character uppercase PSK assuming the attacker can capture a successful authentication.

So as people, and yourself, have mentioned this will stop ametures from brute forcing the PSK. Anyone willing to put in the time to do this attack over the span of a few days will very likely not be an amateur.


What is the risk if I don't have a passphrase associated with CA private key? I understand that it is better to use a passphrase for SSH private keys so that even if someone accesses your machine, they can't simply SSH into a protected machine using your keys.

My question is specific to a certificate authority. Suppose I have an application which takes user keys and signs them using the CA key and returns a signed certificate, what is my risk if I don't have a passphrase associated with the key? No user(except for the admins of course) would have a direct access to the private key.

I don't mind creating a key with a passphrase (it is very easy) but I was just wondering about the risks associated.

So, the cost of loosing control of your CA is that you would need to make the compromise public, eliminate that CA from all trust stores, and reissue all certificates that are currently valid and signed by that CA.

So... how certain are you of any given security control on the key pair in light of that expense?

The answer varies widely due to the risk/value/scope of what you are securing with your CA.  If this is three servers in your basement and three mobile phones used by you and 2 friends, the scope is much different from a commercial grade CA system, a corporate CA system or a defense system...

In most of my experience, the cost of securing a CA key pair is minor in comparison to the cost of loosing face, having to reissue every cert (that includes refreshing CRLs and OCSP servers, if applicable), and having to update every trust store... not to mention contacting any other parties who were relying on your trust store, or going public about a data breach in your security infrastructure... but then I like high stakes systems.

In my experience, the CA systems I work with go a lot farther than a password on the key pair.  Root CA keys are kept offline and under two man physical access control with heavy auditing.  Intermediate CAs are heavily secured behind firewalls, DMZ's, heavy auditing of access, separation of control, and FIPS grade hardware that keeps the key on a box that is tamper resistant and TEMPEST secure.  But I admit - I work with CAB certified, or govt. grade systems... I don't run small scale CAs.

Mileage always varies depending on risk.  If it was a 4 hour job to rekey/reset trust and you think it will be 1 hour of pain every week when you've forgotten your key pair password and had to go crack it or dig out a locked up password... then if you only estimate rekeying due to break-in as a once a quarter event, you probably save yourself the hassle by NOT setting a key password.  (1 rekey = 4 hours, 1Xweek for 12 weeks of lost password recovery = 12 hours... )


Is SubjectAlternativeName in X.509 always used for DNS Names? X.509 certificates as of RFC5280 offer the two fields "Subject" and "Subject Alternative Name" that can be used to describe the Subject of the certificate (e.g. a Domain example.com).
Section 4.2.1.6 of RFC5280 reads:

  The subject alternative name extension allows identities to be bound to the subject of the certificate. These identities may be included in addition to or in place of the identity in the subject field of the certificate. Defined options include an Internet electronic mail address, a DNS name, an IP address, and a Uniform Resource Identifier (URI). […] Whenever such identities are to be bound into a certificate, the subject alternative name (or issuer alternative name) extension MUST be used; however, a DNS name MAY also be represented in the subject field […]

My understanding is that in all X.509 conforming certificates the contents of the subject field must also be included in the "SubjectAlternativeName" field.

In which case is it necessary to check the "Subject" field of a certificate?

Do I, for compatibility reasons, need to check the "Subject" field? Do (non-conforming) X.509 certificates exist in the wild that don't use the "SubjectAlternativeName" field?

I'm interested in this question in general, but if you have specific knowledge about how this is commonly handled in wifi security (e.g. PEAP), please include it in your answer.

There are X.509 certificates in general and there are X.509 certificates as used with HTTPS. For HTTPS just using a common name is long considered obsolete and browsers like Chrome insist on having a subject alternative name. Also, as defined in RFC 6125 and RFC 2818 if a DNS subject alternative name exists the common name should not be checked at all.

Anyway, this is just HTTPS. For different use cases different requirements exist. But I'm not aware of any use case where common name or other parts of the subject should be checked even if a subject alternative name already matches.


How can I understand this extract, concerning basic heap overflow? Unfortunately, I dont seem to understand one minor concept in the "Art of Exploitation" book, concerning heap overflow: a new root shell is being added to the passwd file. From page 168:

However, the nature of this particular heap overflow exploit won’t allow that exact line to be written to /etc/passwd, because the string must end with /etc/passwd. However, if that filename is merely appended to the end of the entry, the passwd file entry would be incorrect. This can be compensated for with the clever use of a symbolic file link, so the entry can both end with /etc/passwd and still be a valid line in the password file. Here’s how it works:
reader@hacking:~/booksrc $ mkdir /tmp/etc
reader@hacking:~/booksrc $ ln -s /bin/bash /tmp/etc/passwd
reader@hacking:~/booksrc $ ls -l /tmp/etc/passwd
lrwxrwxrwx 19 2007-09-09 16:25 /tmp/etc/passwd -> /bin/bash

Now /tmp/etc/passwd points to the login shell /bin/bash. This means that a valid login shell for the password file is also /tmp/etc/passwd, making the following a valid password file line:
myroot:XXq2wKiyI43A2:0:0:me:/root:/tmp/etc/passwd
The values of this line just need to be slightly modified so that the portion before /etc/passwd is exactly 104 bytes long:

I understand the part when the author states that  /tmp/etc/passwd can be used to link to /bin/bash, but I don't understand how this really works (there is no explanation of mkdir, ln -s etc)

Also, this is probably very simple, but why does the author state that: "the values of this line just need to be slightly modified so that the portion
before /etc/passwd is exactly 104 bytes long"? Why was /tmp omitted in the previous line (i.e. why isn't it stated: "the portion before /tmp/etc/passwd is exactly 104 bytes long" ? On the next page, the new root account is written to /etc/passwd, but why not to /tmp/etc/passwd? I've checked, and there are 2 different etc folders on the system; why is this the case?

There is an explanation in the actual book (maybe this 'leaksource' site isn't reliable ;-).

You type commands: mkdir /tmp/etc; ln -s /bin/bash /tmp/etc/passwd
(A)The heap contains two buffers and 104 bytes is the maximum distance between the first buffer and the datafile allocation buffer. (B)/tmp was not omitted, /etc/passwd will be appended to the end of the string shown in bold. The last part of that string shown in bold reads :/root:/tmp. So when completed with the above it will write …:/root:/tmp/etc/passwd to the first buffer and /etc/passwd will overrun into the buffer datafile @ 0x804a070 as shown on the next page. (C & D) It won’t write to /tmp/etc/passwd because that is only a symbolic link to /bin/bash.

The overall idea is to append the /etc/passwd file that has a User ID of 0 so you can be given root privileges. The way this exploit is carried out: “the overflow needing to be the destination file “/etc/passwd” doesn’t allow for us to append the file using myroot:XXq2wKiyI43A2:0:0:me:/root:/bin/bash (if we used this as part of the overflow it would write to /bin/bash). You are creating /tmp/etc/ for two reasons:

to have an overflow into the datafile allocation buffer of /etc/passwd (i.e. the file you want to write to).
to have a valid login shell for your entry into password file WITHOUT ruining the target system & actually messing up your whole password file.

A blog post that might help you out. If you aren't familiar with the linux commands like mkdir and ln, let me recommend CodeAcademy's Command Line Course or a command line tutorial out of many you could google.


Is it realistic for a script kiddie to remotely hack into a jailbroken iPhone? If my iPhone was jailbroken and I plugged it into a computer controlled by the hacker, unlocked the phone, and clicked "trust this computer" to share photos with it, would it be realistic for a typical script kiddie to hack into my iPhone or is that something only a more sophisticated hacker would be capable of?

EDIT: "Script kiddie" defined as someone who doesn't understand that you can't use a rootkit on a Bitlocker protected computer without being detected.

A key point of definition of 'script kiddie' is that they can run scripts but don't necessarily understand how or why the scripts work.

So yes, absolutely. If you have a vulnerability on your phone, your attacker can run an exploit that will gain access. They may not know how it works; they may just try a bunch of exploits hoping one will succeed.

There is very little any more that is only breakable by a "sophisticated hacker" because they sell packaged exploits to unsophisticated attackers.


What personal information is safe to share publicly? What personal information is safe to share publicly (online)? I have a CV online with my email address, mobile number, land line number, ID number and year of birth (not date of birth). I live in South Africa where there is a lot of physical crime, so I recently took off my street address to prevent potential burglars from finding out if my house is uninhabited or not (by calling the land line) before attempting a break-in. Am I giving away too much personal information?

IMHO, the less the you share online the lower the risk of being targeted in some by spammers, hacker, identity thieves, phishing scams, ex-boy/girl friends,thieves etc.

Given the context (an online CV) lets look at each piece of data, and determine its risk/requirement for the context of an online CV.

  email address

I would strongly suggest you do not provide your primary email address here, as you will certainly be targeted by email spammers, and your inbox will suddenly be filled with Viagra offers, lottery 'winning' notifications, urgent parcel delivery notices, PayPal refund notices, etc etc.  All spam or phishing attempts. You do want to be contacted by prospective employers, not by spammers. Lower the risk Use a Disposable email address service here, and you are safe.

  mobile number, land line number

Again on an online CV, a phone number is nice, but not absolutely required if you have posted a disposable email address.  This again invites possible spam SMS messages, unwanted phone calls, and loss of privacy - assuming its your home phone, I would treat that like my home address: nobody gets that unless they are actual friends/colleagues/family.

  ID number

Careful with this one. In the US anyway, our ID numbers are Social Security numbers, and are really not shared.  SSNs any are primary identifies associated with tax returns, bank accounts, credit reports. etc. Even when communicating with trusted providers that have my account information, they will only ask for the last 4 digits for identification purposes.

  year of birth

This data is fine I suppose, but again, why provide it in this context? One can simply guess your age based on your educational and work history, usually. I like to keep them guessing a bit on my age anyway.

In summary, name and a disposable email is all I would share.  If you used LinkedIn, that type of data is always good to see on a CV.

Perhaps I am paranoid, but I would only offer Name and Email as data.  If they like your CV, all they need to do is send an email! You provide more details as needed.


safely changing distribution, is there a strategy to get an distro iso image untampered? I can check that an Ubuntu iso file is indeed untampered using the public keys already present and trusted in my Ubuntu system.

Now I want to switch from Ubuntu to Arch and I wonder how I can start trusting that the image downloaded for setting up Arch has not been tampered?

I know that I can use cryptographic hash functions like sha256,sha1,md5 even though that these are transmitted via the same channel (hence an attacker would just switch the hashes to fit to the tampered iso).

Now is there a strategic way out? i.e. do some distributions cross-sign their isos or public keys so that I can verify isos without leaving a trust-chain I already bought in?

As an alternative, should I redownload the md5 from different sources, on different machines and at different times to make an attack more troublesome?

is this the suggested procedure?

https://www.archlinux.org/download/ has the SHA1 hash for the ISO image as well as the distribution's PGP key. Use that to verify the authenticity of your Arch Linux download.

Since that page is hosted on an HTTPS site, that should be a reasonable guarantee that it comes from the organization to which the SSL certificate was issued. (It is possible that the website has been hacked and those checksums and signatures are false, but that would be a huge problem for The Arch Linux project.)


Why does WebRTC need the local IP? This question Why is my internal IP address (private) visible from the Internet? highlights that the Local IP can be accessible from a website because WebRTC needs it.

However it does not answer why WebRTC needs it. From the wiki page of the STUN Protocol :

  When a client has evaluated its external address, it can use this as a
  candidate for communicating with peers by sharing the external NAT
  address rather than the private address, which is not reachable from
  peers on the public network

It says nowhere that the Local IP needs to be disclosed. Indeed if both peer have exchanged the the public IP of their respective NAT with the corresponding port that has been assigned to them, they can now communicate and no Local IP is involved.

Could someone provide a simple explanation or situation where the local IP is legitimately needed ?

WebRTC doesn't require Internal IP Address for P2P communication. It's the STUN server that retrieves it. The purpose of webRTC is to let the client discover its public IP Address.

On the cloud side, STUN server has following work to do:

Discover client's private & public IP Address
Discover Internal and external ports
Behind what type of NAT client is sitting at

There is no way STUN server can be able to discover behind what type of NAT you are sitting at unless it knows your Int IP:int Ports.

You may feel that discovering type of NAT is unnecessary but for STUN protocol it is important. If STUN finds that you are behind a symmetric NAT, the P2P session cannot be initiated.

STUN server reports this to webRTC and webRTC switches from STUN to TURN using RTC Peer Connection Object API. It happens in case of symmetric NAT.

So, basically it's a STUN server who wants to know your Internal IP and not the P2P protocols. Your Internal IP is only visible to those sites who are operating the STUN server.


How to use password salt the right way I understand the basic idea of password salts.

You generate a 'random' string of data
prepend this data to a user password
store password and salt (salt maybe even in 'clear' form)

Like in the following scenario:
You have a client side mobile application and a server application with a database. The user registers with a username and password using the mobile app. The password gets a prepended salt and is stored hashed on the server side. The salt has to be stored on the server side too, because you wouldn't trust the mobile client at all. And the salt should somehow be connected to the right user account. So let's assume, it is stored in the same user table right beside the password.

How could using a salt in this case prevent any attack (e.g. dictionary attack)? If the attacker already has access to the database server it would be easy to get the salt. If the attacker uses the interface of the server application in a proper way the salt would also be applied to his 'attack attempts for login'. Maybe I'm missing some important point how this kind of attack is usally carried-out. Or would this system only be secure if salting and hashing would be executed directly on the client?

Salting by itself does not prevent a dictionary attack against the password itself. But it makes rainbow-table or common password attacks against the hash much harder. If you use a PBKDF instead of a simple hash o HMac, a dictionary attack against the password may become infeasible, too.

P.S.: The salt is nothing to be kept secret. Its only purpose is to randomize the hash and make it unique to another factor other than the user-chosen password.


PCI scope for credit card forms that talk to Stripe, Braintree, etc I client of mine is using a custom credit card form, which talks to Stripe, Braintree, etc

To make this acceptable for a PCI audit, currently they do the following:

They host the files in a separate repo + deploy train

They expose the form via an iframe, which is talked too via window.postMessage

Now the problem:

From a developer and product perspective this is unideal. They now need to manage a separate deploy train, and the code is more susceptible to bugginess (making an iframe appear seamless is tough).

My initial assumption was:

Why can't we just host it in the same deploy train + same repo, and have custom git rules on who can edit those files?

The response was:

Technically, any js on the same page could use the DOM to access that information, which means everything would have to be under PCI scope
Hence they had to have separate deploy + iframe to avoid this.

From research I think having our own form inputs would make us SAQ A-EP

Question for you:

What would the ramifications be for ditching the iframe?

Would we now need to make sure that the whole frontend repo is SAQ A-EP compatible?

i.e could we just PCI-scope those files, or is it a must to have an iframe?
What are the alternative options?

There are three FAQs on the PCI SSC website that will help you to answer this question.

https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/Why-is-SAQ-A-EP-used-for-Direct-Post-while-SAQ-A-is-used-for-iFrame-or-URL-redirect

https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/Why-is-there-a-different-approach-for-Direct-Post-implementations-than-for-iFrame-and-URL-redirect-what-are-the-technical-differences-and-how-do-they-impact-the-security-of-e-commerce-transactions

https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/How-is-the-payment-page-determined-for-SAQ-A-merchants-using-iframe

And also a helpful guidance document "Best Practices in Securing eCommerce -
https://www.pcisecuritystandards.org/pdfs/best_practices_securing_ecommerce.pdf

Simply it is harder for a criminal to attack an IFRAME'd payment page than it is to skim cardholder data out of the DOM if you host all the payment form fields yourself. Securing your website to A-EP is harder and will cost more than if you redirect or IFRAME. If that cost and risk is worth the benefit you’d get from hosting your own form fields then that's a reason to change. Personally unless your business is payment card data security, I'd always recommend giving the problem to someone else.


Is it possible that my home ADSL router firmware was hacked? I'm using a TP-LINK TD-8817 ADSL home router with a customized firmware from my ISP.  When using the modem in router mode, I often redirected to a specific link owned by ISP.  This is interesting because I never have this problem in my old router. So I used tftp to retrieve router firmware (a file called ras).  Then I used binwalk to extract LZMA compressed data from that file.  Looks like this ADSL home router use ZynOS.  Then I searched for interesting strings.

I was surprised when I found several spelling mistakes, for example:

00301380  3e 3c 62 6f 64 79 3e 00  74 65 78 74 2f 68 74 6d  |>.text/htm|
00301390  6c 00 00 00 48 54 54 50  2f 31 2e 31 00 00 00 00  |l...HTTP/1.1....|
003013a0  20 33 30 32 20 4d 6f 76  65 64 20 54 65 6d 70 6f  | 302 Moved Tempo|
003013b0  72 61 72 69 6c 79 00 00  4c 6f 63 61 74 69 6f 6e  |rarily..Location|
003013c0  3a 20 00 00 43 6f 6e 6e  65 63 74 69 6f 6e 3a 20  |: ..Connection: |
003013d0  00 00 00 00 4b 65 65 70  2d 41 6c 69 76 65 00 00  |....Keep-Alive..|
003013e0  43 6f 6e 74 65 6e 74 2d  54 79 70 65 3a 20 00 00  |Content-Type: ..|
003013f0  43 61 63 68 65 2d 43 6f  6e 74 72 6f 6c 3a 20 70  |Cache-Control: p|
00301400  72 69 76 61 74 65 0d 0a  00 00 00 00 54 68 65 20  |rivate......The |
00301410  64 6f 75 63 6d 65 6e 74  20 68 61 73 20 6d 6f 76  |doucment has mov|
00301420  65 64 20 3c 61 20 68 72  65 66 3d 22 00 00 00 00  |ed here....mult|

The word doucment should be document.  It raises my suspicion to find such mistake in a router produced by big company.

Worried about this, I tried to flash this router using its default firmware. But I get the following error:

newFlashSupportFlag = 1
new FW version is 0
new flash can not support old firmware

The box shows that the version for this router is 2.1 and sys ver output is:

RAS version: 3.0.1 Build 110402 Rel. 02846
System   ID: $2.12.35.0(UE9.C39)3.11.2.175 20110402_V005 [Apr 02 2011 14:11:13]

I'm unable to flash this router (to use default firmware) till now.

To avoid the redirection problem, I use this router as modem (by using bridge mode). I just feel that I often get suspicious packets such as in Why there are uninvited incoming packets to my ADSL connection?.

It maybe just me being too paranoid, but is it possible that my router was hacked?

Probably not hacked, but your ISP seems to use some kind of DNS redirection to make some additional money (especially if you are beeing redirected when you type in a wrong adress or something like that).

You should be able to change the DNS the router uses, simply switch to a alternate DNS like OpenDNS (http://www.opendns.com/)


How background services perform token based Api Authentication? I am implementing JWT token based authentication for our WebAPI in order to restrict data access through the API (e.g. client sends username / password and the api provides a jwt token valid for x hours). We currently have recurring background processes that need to access that data. What is the best practice related to this scenario?

I read somewhere that since the service is a confidential type of client that we can store the credential in code similar to access-key/secret. I don't like configuring or hard coding passwords but this seems like the valid approach for the use case.

NOTE: this question has been suggested as duplicate for where to store private keys but the crux of the question is more on ideas on which approach is better for authentication related to background services.

The best solution will depend a lot on what you store in your token.

if you store confidential information in your token, you will need to encrypt it and use a JWE token. In this case, you will have no choice but store a private key somewhere your service can access it.

But in most case, your API endpoint doesn't need an encrypted token: all you need is a signed one so you can verify that the data in the token is valid and therefore you can use a JWS token instead.

In this case, you have 2 options again: use a HMAC based token (in which case you'll need to store that HMAC key in a secure manner) or use an asymmetrical algorithm instead (RSA or EC-based). In that later case, all your API service will need need is the public key that matches the signature: you need that key to be store on your server in a way that makes it difficult for the key to be changed but you do NOT need the key to be secret.


What parties have access to the *full* requested URL of a website accessed via the HTTPS protocol? What parties have access to the full requested URL of a  website accessed via the HTTPS protocol?

Here are some possibilities I can think of, and there could be more:

local device accessing the website
router
modem
local network provider (wired or wireless)
ISP
each hop along the internet to the destination
big brother
destination ISP
destination local network provider (typically wired, but can be wireless)
destination modem
destination router
destination host

Note that this question is specifically about the full requested URL, which would include the specific page being accessed as well as all parameters being passed via the URL.

Also, are there any steps along the way that would not have access to the entire HTTPS request header?

Only the TLS endpoints1 can read the the full URL because HTTPS provides end-to-end encryption.

HTTPS wraps the full HTTP protocol, including the request line, request/response body and all the headers. The request URL is just one part of HTTP that gets encrypted together with all the other components. If any party was able to read the URL, they would naturally also have access the full HTTP traffic.

Just to be clear, there are still a lot of ways the URL might be inadvertently disclosed:

When moving away from a site by clicking a link, your browser will by default send a Referer header containing the previous URL - which is therefore disclosed to the site you're browsing to.
Browser plugins might send your visited URLs somewhere for analysis or to sell them.
Security products or corporate firewalls that do "legitimate" HTTPS interception (implying you actively installed and trusted their root certificate) could read your HTTP traffic and thereby learn the URL.
The host of the target site (but not the full URL) would routinely be disclosed to a potential eavesdropper due to HTTPS SNI and the client's DNS query.

But assuming a correct setup without any side channel leaks, the request URL just goes through the TLS tunnel like everything else that's transmitted.

1In your example, these are most likely the local device (1.) and the destination host (12.). As @Bob points out, the TLS connection could also end at a load balancer or some other form of proxy.


Should CSRF token without session cookie work? Let's say that the website example.com has CSRF protection.
They send a CSRF token in a custom header and in hidden input fields.

For example to add a new folder, your http request needs to contain CSRF token.
What I've observed is that if you make the same request, with CSRF token but withou a session cookie it still works.

Should it works that way, that I can create a folder without session cookie, but solely with CSRF token?

Generally speaking, no.

CSRF protection and session authentication are typically supposed to be separate concepts entirely. The responsibility of a CSRF token is supposed to be a one-time key for a request - nothing more, while a session ID or session token is supposed to merely identify a user that has permission to perform the action in the first place.

You should have both in place unless the CSRF token holds both responsibilities somehow (which honestly, would indicate someone tried to be too clever with their security design, and failed).


Spam Mail Related to my Browsing I was searching google to find a good printer to buy. To my horror, the next day I got a spam mail with theme "Print smarter at low price". Is this a coincidence or is my PC breached? What should I do? No alerts from Anti-Virus. Or can that webpage I opened install some malware? I didn't click on anything there.

It is impossible to offer a definitive answer given the current information (call it an undecidable problem, if you prefer). Both of your suggestions are possible: it could have been a chance, or the spam email could have been triggered by your searches.
As some comments above mentioned, your activities online are monitored and targeted by advertisers. This is (unfortunately) the norm, so your computer can hardly be considered "breached".

No alerts from Anti-Virus.

This is expected: receiving spam emails is not malware. An antimalware solution cannot raise this as a positive event, unless the email itself contained some malware.

I didn't click on anything there.

Generally speaking, it's enough for you to view the ad. The ad networks tracks who clicks on what ad, but also who and how many people actually see the ad. The only way to lower the chance of this happening is to run an adblocker in your browser (or, arguably even better, at the network level).


Do CA Public Audit Records increase the visibility, and risk of attack? Does the CA feature of Public Audit Records increase the visibility of my hosts, and therefore the risk of host-specific attacks?

Would the only mitigation be to only enable this for wildcard certificates?

Wildcarding your certs as a countermeasure would be considered security by obscurity and as such is not really helpful.

Your sites can be listed in other databases and there is only finite number of IP addresses out there anyway so it doesn't really matter how hard you try to hide.

Eventually they'll find you and you have to be prepared for them. It can be either a random attack which usually isn't that bad for you to protect from it by obscuring the way to you or it can be a directed attack from someone who knows the way already.

I'd say there are much more important consideration when it comes to securing your host.


Easy protocol for email authentication I'm cooking up a very simple system to send commands to a remote server via email. Everytime an email is sent to do_something@mydomain.net, the server runs a python script that does something different based on the recipient do_something, and uses the email content and metadata as parameters for whatever task it will perform. This will be used to provide services through email for a specific set of users that don't have direct Internet connection must of the time. Users don't write emails themselves, but use a small application that generates all necessary metadata.

It is of course very important to authenticate users reliably. I could implement some public key cryptography protocol, but a friend suggested me the following idea, which is very easy to implement, and seems reliable enough for me:

I generate a password for each user (identified by his email address), say a random string of size 2K. The server knows the password for each user, and each user knows his password. The user application generates an email for the corresponding task with all necesary data. After it has finished, it concatenates some of the email metadata (say sender and timestamp to avoid collisions for the same user) with the user password and computes a secure hash (I'm currently using SHA-512). It then attaches this hash to the generated email. The server gets the email and calculates the same hash (remember it knows the supposed sender password). If it matches with the hash attached in the email, it is considered authenticated.

Now suppose that I can reliable make each user get his password (not by electronic means). Is this mechanism secure? I know I'm probably reinventing a lot (rather old) of wheels here, so please forgive my ignorance on the subject. I do know that SHA hashes are virtually irreversible, and that is the main reason why I think this strategy might work.

Thanks in advance.

You are trying to use a MAC. Applying a hash function on the concatenation of the password and some other data is a custom MAC, and not a very good one with usual hash functions like SHA-512 because of the length extension attack. That's why HMAC was invented.

Using HMAC with a shared secret is a good authentication method. However, due to the inherent insecurity of emails, you would probably want some encryption, too, and for that you should just use OpenPGP (with its OpenSource implementation). Using a software system which already exist is both safer and easier than reimplementing your own system.

Regardless of the authentication method you use, you should add an anti-replay attack: an attacker could send a valid email (which he observed in transit) a second time, thus triggering the email effect again. Replay attacks laugh at MAC and encryption. To defeat them, the server must "remember" past emails and discard exact duplicates.


Did US and UK spy agencies defeat privacy and security on the internet? This question is meant as a canonical question in regard to the US and UK spy agencies compromising end nodes and encryption between nodes to spy on people they suspect to be terrorists. However, this has the side effect of significantly elevating the risk of exposing innocent people's personal data.

Recently an article was published by the Guardian detailing:

  US and British intelligence agencies have successfully cracked much of
  the online encryption relied upon by hundreds of millions of people to
  protect the privacy of their personal data, online transactions and
  emails, according to top-secret documents revealed by former
  contractor Edward Snowden.

What is the impact of this and have they really broken all of the crypto out there?

There will be a lot of speculation regarding this question. I will try to provide as much information as stated in the articles. I will also update the answer regularly with facts provided in the comments.

Relevant articles to this answer:

NSA: How to remain secure against surveilance
The US government has betrayed the internet. We need to take it back
US and UK spy agencies defeat privacy and security on the internet

First of all I would like to say:

Is this threat real?

Depending on how well we can trust the papers, it should be considered a real threat in the sense that security agencies have succesfully implemented backdoors in software or at encryption end-points. I believe this is probably true as three reputable news papers were kindly requested to not publish  the article. This means that there is a high likelihood that at least part of the story is true.

Have they really broken crypto?

As far as we can tell from the articles they mainly have three strategies:

Use supercomputers (clusters) to brute force encryption protocols. This probably means they can efficiently bruteforce encrypted files.
Implement backdoors into the software which does the encryption.
Make technology companies comply with their demands, some of which may include #2.

Option 2 and 3 suggest that they have not succeeded at real time decryption of, for instance, SSL. As Bruce Schneier stated:

  The NSA deals with any encrypted data it encounters more by subverting
  the underlying cryptography than by leveraging any secret mathematical
  breakthroughs. First, there's a lot of bad cryptography out there. If
  it finds an internet connection protected by MS-CHAP, for example,
  that's easy to break and recover the key. It exploits poorly chosen
  user passwords, using the same dictionary attacks hackers use in the
  unclassified world.

They still require people at either end node to implement a backdoor covertly or make the technology company help them in decrypting traffic passed through their systems. Chances are high they have the encryption/decryption/signing keys of some of the Certificate Authorities, which would allow them to setup proxies and perform man-in-the-middle attacks. Due to the trusted certificates (because they can sign them themselves), these attacks will not be noticed by the users they spy on.

Note that they have proposed a system to perform real time decryption but there are not indicators that they have actually succeeded in building this. All we can do, at this moment, is speculate.

There has also been one case where they, allegedly, backdoored a random generator (according to Wired) used by encryption algorithms.

Please note: Encryption standards are public which means anyone who wants to scrutinize them can look into them. The NSA has made it a lot more difficult to review them though. (Implementations are a whole other thing though.)

Note that for option 2 it seems they specifically target commercial software. If you want to be more confident you're not using compromised software, you should use open-source products and compile the binaries yourself. (Although, theoretically speaking, the compiler could also be backdoored.). The code could be peer reviewed, or you could review it yourself. (Unfortunately, the latter is often not feasible or practical.) Furthermore, this quote from Edward Snowden would also suggest that they haven't managed to crack strong crypto:

  "Encryption works. Properly implemented strong crypto systems are one
  of the few things that you can rely on," he said before warning that
  NSA can frequently find ways around it as a result of weak security on
  the computers at either end of the communication

What are the consequences?

The NSA endangers everyone on a certain system by deliberately installing backdoors. They are not just risking the privacy of those they are investigating, but everyone using the system.
Open source software is less likely to be compromised. It's clearly stated they attack commercial, closed source software. Backdoors are much more likely to be spotted, and spotted more quickly, in open source software.
Commercial software, especially those published in the U.S., are more likely to be backdoored than any other software. (This is personal speculation, but I believe that it would be harder to do in many other regions - e.g.: the E.U. - due to more stringent privacy laws and the fact that multiple governments would often need to be involved. However, this is still no guarantee.)

It also seems that they want to compromise as many internet nodes/hubs (tier 1 providers probably) as possible. This is logical because most traffic on the internet will pass by the tier 1 providers at some point.

The biggest risk is data leaking because of their negligent practices with introducing backdoors. If the NSA is really after you I doubt some crypto will help you to save your ass. They will probably just round you up at some point and make you disappear. The NSA is not generally going to come after copyright infringers or script kiddies/hackers. They're more interested in the hard-core, dedicated (cyber) terrorists. I highly doubt that, unless the have indicators that you are a terrorist, they will use their information to sue you or even pass that information to another agency.

The danger within the NSA is however when someone like Snowden, but who has bad intentions, decides to leak all your private data or use it for personal gain (or any other purpose that is not in the interest of the citizens the NSA tries to "protect"). They have very limited oversight - and much less so publicly - at the moment, which greatly serves to facilitate abuse of the system.

What can I do?

Start by reading the article NSA: How to remain secure against surveilance written by Bruce Schneier.

My personal opinion is that the NSA probably has access to tons of sensitive data and that, even when using strong crypto, they still will be able to get access to sensitive data due to backdoors they introduced in systems or because of the cooperation companies give the NSA.
There are some precautions you can take:

Use strong passwords
Use strong cryptography (websites with SSL certificates should be verified to be running a secure, strong version of TLS)
Use VPN/proxies/Tor (not located in the US or UK - maybe not even Europe - though even they can still be backdoored)

We also need to open up software and protocols, as Bruce Schneier said:

  We can make surveillance expensive again. In particular, we need open
  protocols, open implementations, open systems – these will be harder
  for the NSA to subvert.

My 2 cents

It's also an illusion to think the NSA are the only ones doing something like this. It would surprise me if the Chinese and the Russians (or any other state with a large secret police budget for that matter) didn't have similar programs. For the Chinese we already have indicators (APT-1)  that they are involved in similar practices as the NSA. Does this make it any less wrong/hypocritical of the US/UK? Probably not. As Bruce Schneier said:

  I am saddened to say it, but the US has proved to be an unethical
  steward of the internet. The UK is no better. The NSA's actions are
  legitimizing the internet abuses by China, Russia, Iran and others. We
  need to figure out new means of internet governance, ones that makes
  it harder for powerful tech countries to monitor everything. For
  example, we need to demand transparency, oversight, and accountability
  from our governments and corporations.


Did ZTE put a backdoor in my router? How can I remove it? I have a ZTE router model ZXHN H198A.

Recently, upon connecting to it with Telnet (with some default username-password, of course), I decided to go around the filesystem. Then I noticed that they have a Dropbear SSH server installed in /etc/dropbear. Upon further inspection I saw that an authorized_keys file exists.

The file content is:

  ssh-dss AAAAB3NzaC1kc3MAAACBAJa07l9167yfS6MyvmU9KLFCcazA81w1046fsy6wDpuOPsxdhy3S57ScJI4PaJKUBe9n3JMnhoixFHgxvBC6aEDuxCv/5uBZUaJmLNTItVxtdf53tW+RF+t+JrDt8NbBSXK0CANLSa1TNW8QBqjGOkYpwjgLcWxqJAd0JMKkxe57AAAAFQCUjTtXIlXxcM5Dm0janESDSGxrBQAAAIAYz8yZgJJPUhQR6uVQDBWHtqI/92xnRV4zWx+RFf2qF3+YVnbew9NIOCb8PzweeC2Gij3QytMFvJchkqKB1BDJiN9y/GxbgZb73DZnM6brlb6ZCb8m/xEmVqK6HX/PJlbwj7uHdzqaBERsvc6CJrZlQVfh0H5ymIDJbfyZeE4CfwAAAIA3aX33tPW0rxpXxX2LYSXHVGzh1UPYkjf5WWF6nWaxK4JwZdSxRorj+uRTMXrx0otPs2DzQx370KlUvfwXQdD+PEKsXlYSxx/KwZ4QzS3PYierbWbPOzVVxmSSaBEh2MFkZ+L5GMnkTL3foWDN0HDjtPvjNhwLHEkL6+HslXM2Ug==
  xiekun@localhost.localdomain

  ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEA3R0au/8rJR9Kr7WZkCzG8Dne7Hf5VpOt7UYUxtytbyUJlAq+FrUZBP1mAxYgdwSBKQbkTcnTodj6RuHQ777d1aCdODvcOI6ntqbHRAQ0LLpIAlg5C4R6JlNmCNA3XUl2oht/40d7xbdUsRIsFMnaARAYa8SSmB1irCstEG8g10k=
  xiekun@localhost.localdomain

If you look closely, you can see that the user is xiekun@localhost.localdomain in both public keys. This file was last modified when the firmware was installed, comparing it to other files.

By the Chinese name, and seeing at least one more record of this public key online - I came to the conclusion this seems like a backdoor used by ZTE developers which allows them to connect with SSH to any router they wish.

By the way, upon further testing, the router is actually accessible from the internet (with SSH and Telnet).

What do you think is going on here?

Anyway, I tried to remove it but it seems that the filesystem was mounted as read-only fs. How can I remount it?

It is likely that there is a backdoor for the devs/support (ZTE) to connect to [of course we would all like if they would stop doing this...].  As for being open to the internet that is the fault of your ISP.  They can and should lock down the device itself so that the telnet, http, https, and ssh logins are only accessible from the ISP's CPE management VLAN.  It is however sadly common for ISP's to poorly harden their CPE (customer premises equipment).

Vendor backdoors for residential routers is not a new thing:
https://w00tsec.blogspot.com/2015/11/arris-cable-modem-has-backdoor-in.html

Specifically for ZTE it is not a new thing:
https://github.com/stasinopoulos/ZTExploit/blob/master/ZTExploit_Source/ztexploit.py

Since you have access you could harden the device yourself.  But this may lock your ISP out from doing updates/troubleshooting (but they probably aren't doing updates anyway).


What is client side non-DOM XSS? I've been reading on the new categories of XSS. According to OWASP, they're no longer just reflected, stored and DOM-based XSS, but rather server/client side, and then subdivided into reflected/stored.

According to the site, DOM-based XSS is just a specific section of client-side XSS. I'm not following the distinction between DOM and non-DOM client side XSS. Every client side XSS I can think of involves the DOM. I understand how I can have persistent and non-persistent DOM client side XSS, but what would be an example of non-DOM client side XSS (reflected and stored)?

I'll try to explain using a few quotes from the OWASP page you linked. First, what is DOM based XSS?

  ...the source of the data is in the DOM, the sink is also in the DOM, and the data flow never leaves the browser.

Client side XSS does not always fulfill this definition. Even though the data is inserted into the page at the client, the data can come from somewhere else, lika an API response from the server:

  [For client-side XSS, the] source of this data could be from the DOM, or it could have been sent by the server (via an AJAX call, or a page load).

So (my highlight):

  With these new definitions, the definition of DOM Based XSS doesn’t change. DOM Based XSS is simply a subset of Client XSS, where the source of the data is somewhere in the DOM, rather than from the server.

An example of non-DOM client-side XSS would be if the client makes an API call, retrieving some untrusted data, and pass it straight to innerHTML without any sanitation.


Bcrypt SHA-256 implementation i need bcrypt to create encryption keys and also for authentication hashes, but entropy of delivered output from password has to be >256bit (which clearly can't be achieved by hashing 196bits with SHA256).

is there any bcrypt implementation that use SHA256 in KDF? if not please help me how to do that myself

Scrypt is more preferred but android phones don't have that much RAM. is there anyway to use low RAM in Scrypt?)

By construction, bcrypt is its own function, and does not use a hash function like SHA-1 or SHA-256. You may be confusing it with PBKDF2.

Your requirement on "entropy" is, at best, severely misguided:

As long as your attackers cannot convert the whole mass of the complete friggin' Galaxy into energy to run some humongous computation, 256 bits of entropy are the Mother of all Overkill. For any practical situation which does not involve battling with hostile extraterrestrial entities, 128 bits are more than enough.
You won't get 256 bits of entropy or even 128 bits. You said "bcrypt": thus, you are processing a password. A password which can be chosen and remembered by a human being cannot reach that much entropy. For typical users, you can consider yourself lucky if you reach, say, 32 bits of entropy; most people cannot do even that. No matter what you do and how many hash functions you throw at it, you will never get more entropy on the output than you had to begin with, entropy being "what the attacker does not know", i.e. the password.

(The important point here is that entropy does not equate length.)

What you really want, here, is a password-processing function which extends a password into as many "key bits" as you need for whatever cryptographic purpose you envision. For instance, you want 256 bits because you do password-based encryption and need 128 bits for symmetric encryption itself, and 128 more bits for a MAC. This is done in two steps:

Hash the password with a password-hashing function which includes the features specific to password protection, which are ways to cope with the inherent weakness of passwords. Namely, salts and configurable slowness. Bcrypt is fine for that. See this answer for details.
Extend the password hash with a deterministic Key Derivation Function. If you just need 256 bits, then just hashing the password hash with SHA-256 is perfectly fine: SHA-256 works well as a KDF as long as you do not need more than 256 bits of output. For arbitrarily long outputs, you may need something a bit more complex; SSL/TLS's "pseudorandom function" is a thoroughly studied example.

Beware that typical bcrypt implementations output a string which encodes the 192-bit output but also the salt and other parameters; for key extension, you want to process only the 192-bit output.

PBKDF2 is a "password-based key derivation function" (hence the name) which combines both operations.


How to crack (get secret from) Android Keystore System I am looking for the best way to protect sensitive data in Android devices, e.g. secret or private keys, and found Android Keystore System. Based on the documentation, key material may be bound to secure hardware (e.g., Trusted Execution Environment (TEE), Secure Element (SE)) of Android device. It implies that not all of the Android devices support this. Some articles named this method as hardware-backed storage. If the device does not support secure hardware, it is stored in internal storage, some articles named this as software-backed storage.

Based on this article, software-backed store is placed in /data/misc/keystore/user_0 which means it is exposed in rooted devices. Is there any PoC that this is not secure for rooted device? Specifically, how to extract secrets in these software-backed secure storage?

Strong box, hardware backed keystore and software backed keystore cannot protect sensitive data from getting compromised by root user. Keystore saves cryptographic blobs of apps for encryption, signing, attestation and authentication. Any app with root privileges can impersonate other apps and have their sensitive data decrypted or signed by the keystore by issuing a legitimate request on behalf of other apps and system.
It doesn't matter how sensitive data is secured, it has to be loaded in memory in order to be used by the app. A code injection by root user can dump anything in memory which is supposed to be secured. What hardware backed keystore and strong box can do is to securely verify device integrity such as whether chain of trust is custom, whether bootloader is unlocked, hash of OEM public key, hash of /vbmeta image, etc. Then they can certify this information using their private key and send it to the web service. Root cannot tamper with TEE signed data without knowing its private key or without Google certified public key.
If the device integrity is broken, web service can refuse service to the client. Software backed keystore cannot verify device integrity as its private key is not secured in tamper-resistant isolated storage. Software backed keystore keys can be found in /data/misc/keystore/user_0/. The keys are encrypted with the screen lock pin/pattern/password but if you remove this lock the keys are decrypted. Software backed keystore is deprecated from android 7+.


Nessus Plugin "HTTP Smuggling Detection" failing due to support for http/1.1 - how to overcome? A new Nessus plugin (140735 - HTTP Smuggling Detection) was very recently incorporated into Tenable's PCI template and is now beeing flagged as a "medium" vulnerability and causing scans to fail.
The only info in the scan report is:

A web server was discovered on port 80/443
The below information could make the Web server a potential candidate for HTTP Smuggling

HTTP/1.1 is supported.

I'm hoping this isn't saying that mere support for HTTP/1.1 is grounds for a failing scan, but having trouble determining what else is triggering it.
We provide software to public schools and their constituents, and still have a high % of traffic from older browsers like IE 11 and Android 4.4.4's Chromium-30 based web view, so disabling HTTP/1.1 isn't an option (nor do I see that as a configuration option offered by our web server (UWSGI) or cloud hosting provider).  I've also scanned a standard CloudFront endpoint for a static site and the scan fails for this as well.
If anyone is familiar with this plugin and/or can assist with how to overcome this vulnerability (as flagged by this plugin) w/o disabling HTTP/1.1 (which really isn't an option at this time) would be very much appreciated as we are stuck, and imminently facing missing our quarterly ASV. I've read the article attached to the plugin's landing page but the scan seems overbroad vs. the actual vulnerability described in the article.

According to here, this issue will show up if you have paranoia enabled. Did you purposefully enable paranoid scans?
Paranoid scans turn up with a lot of weird plugins like these. Another example of paranoia false positives I have seen was something along the lines of "Port 4444 is open, therefore there is a backdoor on this machine," which isn't necessarily true.
If you do need paranoia set to On, next, you then need to verify the validity of this plugin. In that case, I would recommend using Burp Suite (community edition is fine) and then running the HTTP Smuggler addon against your "vulnerable" host. It will do a much more thorough test on it than Nessus will.
Should you discover that your host IS vulnerable, then you should investigate patching your application. Generally speaking, this is not an issue with your code -- it is almost always a vendor patch for a web server or web appliance. Note that, due to how HTTP Request Smuggling works, you also may need to investigate and patch all other infrastructure which is attached to that application. Namely, that would probably be a load balancer or some type of middleware.


Is it possible to exploit this Zookeeper instance? I was performing a security test for a client when I came across a Zookeeper installation on xx.x.x.xx:2181. Trying NetCat revealed that I'm able to all the following commands:

dump: Lists the outstanding sessions and ephemeral nodes. This only works on the leader.

envi: Print details about serving environment

kill: Shuts down the server. This must be issued from the machine the ZooKeeper server is running on. (Haven't tried this one)

reqs: List outstanding requests

ruok: Tests if server is running in a non-error state. The server will respond with imok if it is running. Otherwise it will not respond at all.

srst: Reset statistics returned by stat command.

stat: Lists statistics about performance and connected clients.

I'm not familiar with Zookeeper so please excuse me if this sounds like a stupid question but is Zookeeper supposed to be accessible without authentication? and also what are the implications of having this application exposed?

Any help is really appreciated, Thank you

First of all, I'm also not familiar with Zookeeper at all but I could give you some general advice from a security perspective.

The Zookeeper commands you listed sounds like administrative functions, that means that they probably should only be accessible after authentication or should, for example, be only accessible inside a private network or accessible from certain IP addresses only.

If you are testing a controlled testing environment I'd suggest to contact the administrator and plan a moment to test the kill command, this will verify if it will really work in such a way. If it does I can imagine something like locating all Zookeeper servers in a cluster and kill them all, causing a shutdown of the service. Security professionals will likely call that an availability risk. Ethical hackers and script-kiddies will likely call that a defacement.

Again I don't have any knowledge of Zookeeper but I could imagine the following theoretical risks.

dump shows the sessions, depending on the exact session information that is exposed, you might be able to confuse the system when trying to spoof such a session. Possibly affecting integrity.
envi depending on the information showed you could use that to get a better view of your target and possibly widen the scope if other related systems are found by that information.
kill as noticed before, availability risk and probably the biggest risk of this list of commands.
reqs information disclosure and depending on the information a possibility of confusing processes by spoofing things.
ruok simple information disclosure, I can't imagine any risk unless there are some Zookeeper specific vulnerabilities known that will only work when it's running in a non-error state. Again error-state/non-error-state is a 50% chance that a "state specific" vulnerability will work. Knowing the actual state increases that theoretically to 100% when the versions and everything match.
srst depending on what statistics it resets exactly, you might be able to clean traces after a hacking attempt. Erasing your tracks.
stat information disclosure. Giving unnecessary insights in the system and possibly infrastructure and can possibility be used to widen the scope.

My general advice would be. Prevent this system from accepting that kind of commands from anyone. Possibly adding an authentication layer like VPN and/or IP restrictions or enabling authentication features within Zookeeper (if they exist). This will make sure that information is not unnecessary disclosed and mitigates the possible availability risk caused by of the kill command.

While kill itself is not a vulnerability, it is a risk. Using the CVSS scoring system, if kill actually works and depending on your exact attack background and factors I'd estimate a CVSS of the availability risk on something like 7.1 (high), (AV:N/AC:M/Au:N/C:N/I:N/A:C).

Also, you might want to check out this:

http://www.cvedetails.com/vulnerability-list/vendor_id-45/product_id-27453/Apache-Zookeeper.html
https://nmap.org/nsedoc/scripts/hbase-master-info.html


Chrome torn down the TLS connection after received server ChangeCipherSpec I met a strange issue that the TLS connection is always torn down by Chrome after received server ChangeCipherSpec. The sequence is as following:

  Client                     Server
  SYN-->
                          <--SYN, ACK
  ACK-->
  ClientHello-->
                          <--ServerHello, Certificate
  ChangeCipherSpec-->
                          <--ChangeCipherSpec
  FIN-->
                          <--ACK
                          <--FIN
  ACK-->

Why FIN is sent instead of Application Data?

Your sequence is weird. When the client sends the ClientHello, then the server will respond with a ServerHello, and then:

either the client and server reuse an existing session, and do the "abbreviated handshake", in which case the server sends its ChangeCipherSpec and then a Finished message;
or the client and server do not reuse an existing session, in which case the server must send its Certificate message and a ServerHelloDone, in which case the client will send a ClientKeyExchange, then a ChangeCipherSpec and a Finished message.

See this answer for a description of the SSL handshakes.

In any case, if you observe a Certificate message from the server, then this is not an abbreviated handshake, and there should be at least a ServerHelloDone from the server, and a ClientKeyExchange from the client. The logical conclusion would be that your network capture tool does not see all the traffic. Therefore, it may miss the "application data" records that you expect.


Does the length of each word of a passphrase matter? Since they won't brute force a 19-char password,
I was wondering if the attacker's dictionary is simply sorted by frequency? could these passwords have roughly the same strength?

carp ably feud whir
mailless larksome blameful girasols

No. If you're using multi-word (diceware-style) passphrases composed of actual words, the length of each word doesn't matter.

If you assume the attacker is aware of the method you used for generating your passwords (which you should, per Kerckhoffs's principle), then you can expect that the attacker will attempt to crack your passphrase with a dictionary attack and therefore the word length is irrelevant; only the number of words and the size of the dictionary you randomly selected them from matters.

If you assume the attacker isn't aware of your scheme and is just using brute force, then you can expect the attacker will take many orders of magnitude longer than they otherwise would using a dictionary attack, therefore since your password is designed to stand up to a dictionary attack it is also safe against brute force.

To make that more concrete, assuming you chose "carp ably feud whir" randomly from a 7776-word diceware dictionary, the attacker must try an average of 77764/2 ~= 1.83 quadrillion passwords before cracking it. If instead the attacker used a brute force of lower-case letters and spaces, you'd instead expect this same attack to take (26+1)19/2 ~= 786 billion quadrillion tries on average. Since 786 billion quadrillion is greater than 1.83 quadrillion, you can safely conclude that the brute force attack isn't worth worrying about, as the dictionary attack is a much more significant threat, and therefore the length of each word doesn't matter.


Tails OS doesn't erase video memory As stated succinctly in the Tails "Known Issues" page:

Tails doesn't erase the video memory yet. When one uses Tails, then restarts the computer into another operating system, that other operating system can see what has been displayed on the screen within Tails.
Shutting down the computer completely, instead of restarting it, might allow the video memory to empty itself.

How big of an issue is this vulnerability? Does it pose a realistic security problem for users?
It also states that it completely shutting down might allow the VRAM to empty itself. Is there a way to ensure that it will definitely empty the video memory? Is this based off of the host system, or some other aspect of Tails?
If Tails is running in a virtual machine, and I exit the virtual machine (a simulated shutdown, in a sense), how does this affect the VRAM vulnerability?

I'm not an expert, but I believe they say it might allow the VRAM to empty because typically volatile memory is erased when power is lost. To be sure the VRAM is clear, you'd want to turn off the PSU and press the power button to ensure no residual power is present in the system.

You ask, "How big of an issue is this vulnerability?" That depends entirely on who is using Tails, what they are using it for, and what other security controls they have in place. That said, this would be exploitable given physical access or arbitrary code execution, so it definitely is a vulnerability.

If you are running Tails in a VM, it will depend on the virtualization kernel whether the VRAM gets erased. Note that one exception would be if you pass through the GPU to the VM (ESXi does this quite well), in which case the VRAM will not be erased because the physical device is never powered off.


Is it good practice to let Node/Go/... act as a frontend webserver? I'm used to writing web stuff in PHP and let Apache or nginx handle the actual HTTP handling  and load my code via whatever means (mod_php, fcgi, fpm, ...). I'm under the impression that this is a Good Thing(tm), as there have been years and years of hacking, patching and improving these webservers, so they are "battle tested".

Now, with "newcomers" like Node or Go, I am faced with the question of what's the best way to write real-life, production web applications. I'm hesistant to just let Node listen on port 80, as I fear its HTTP handling mechanism isn't as well tested as that of Apache/nginx (I'm thinking of evil clients, floods, DoS attacks etc.). My admin "confirmed" this by only letting Node apps run behind a reverse-proxy nginx.

Is this fear rational? Or is it totally fine to skip having a dedicated webserver and do the entire request handling in my app (including TLS?)?

Well-tested code helps to reduce the risk, but even PHP keeps issuing patches to remedy security issues.

The problem is not with "newcomers" but with appropriate protections and controls over any type service that you expose. PHP/Apache/etc. behave (and fail) in predictable ways, but we can predict their behaviours because we have experience with them and know how to respond.

Whether you use the oldest, most maintained codebase on the planet, or your own custom-made product of a "hack-a-thon" weekend, you still need to make sure you have all the appropriate protections in place. From that perspective, your admin's "fear" is perfectly rational: add extra protections around that which you do not fully understand, even if that means you end up being heavy-handed. Then, you can tune, refine, and adjust the controls to an appropriate level.

It's your admin's job to protect the server and the infrastructure so that all services can provide value. It's your job (I'm assuming) to provide a valuable service to the stakeholders and customers. You both need to work together so that everyone can be served.


Setting up router password AFTER malware infection? My home network used to be completely unsecured. I'm not sure if there was a firewall, though I did almost nothing through it. Last week I added a password to the Wifi connection, and yesterday I changed the router admin password.

If there had been any keyloggers or sniffers on the router previously, would new passwords have helped at all?

As always, it depends. The right mitigation depends on the situation. In your situation (home user), I'd say just overwrite the firmware with the latest original version and reconfigured everything with a administrative password in place.

Configuration

During configuration consider things like "Strength of Wifi and administrative password? Is uPnP necessary? Or WPS? DMZ? Do I use WEP/WPA instead of WPA2? Setup a scoped Guest network? What Firewall options do I have?"

Back to basics

Make sure it's the original firmware you've downloaded (using a checksum check). That basically ensures that you have the original firmware running and not another version with a backdoor.

Risk (likelihood / impact)

Was it a router in a highly confidential area? Then, I'd calculate the risk based one the likelihood and impact (possible damage) and possibly consider to throw the router away and setup a new one.

What's next?

Also keep in mind that not only the router here is the potential risk. Make sure you audit the configurations and scan all your devices in the network accordingly.