Windows Firewall Connection Security with Certificate

I perused the Microsoft TechNet article here: http://technet.microsoft.com/en-us/library/deploy_ipsec(v=ws.10).aspx (googled "windows firewall certificate authentication") and a little bit lower it says that it doesn't cover: Guidance for setting up certification authorities (CAs) to create certificates for certificate-based authentication. For this information, see Active Directory Certificate Services (ADCS)(http://go.microsoft.com/fwlink/?linkid=110820).

That leads us to the AD TechNet article on the subject: http://technet.microsoft.com/en-US/library/cc770357.aspx

It looks like that you will need a domain to implement ADCS to authenticate with certificates. (The TechNet sources I found were all for windows server 2008.) Active Directory is a whole boatload of fun, (some sarcasm some not!), and it looks like you will have to go that route to configure the advanced security options in the windows firewall (at least for CAs).


Should web application for methods PUT and DELETE return the same response as for GET

Quite a lot of effectively static sites ignore the HTTP verb used, treating them all as GET, with the exception of HEAD, which only returns the headers for the response. This isn't necessarily a problem, if the site will never make use of the other verbs, but can contribute to a technical debt if you start using them at some point in the future.

For example, if you implemented an API which did allow the replacement of content via PUT requests, using the same code as your main pages, but forgot to restrict the use of PUT to the API, you could end up with people able to edit your main pages. This is a bit contrived, but this kind of thing does happen.

In general, it's just sensible to use an "allowed verbs" approach and to ensure that if you need something different for a particular section of your site, it only works there.


Does Heartbleed vulnerability affect other libraries (like BouncyCastle, .NET's SslStream, etc.)?

The so-called "heartbleed" exploit is a buffer overrun. A read overrun, to be specific: the attacked system is induced into reading and sending back bytes from a buffer which is much shorter than the read length, thus reading whatever bytes reside in RAM past the buffer. Since the bytes are sent back to the peer, this gives a window to peek into the target system RAM.

It is unlikely that any other implementation of SSL shares the same exact bug. It is plausible that other SSL libraries have buffer overruns of some sort (nobody really knows how to write bug-free code), but not exactly that one. Or, said otherwise, if another SSL implementation has the same heartbeat-related bug, then it probably is a spin-off of OpenSSL.

Moreover, for implementations written in a language where array accesses are systematically checked for bounds (typically Java or C# or Python or Scheme or OCaml or just about any language which is not awfully low-level like C), the consequences of a buffer overrun are different, and usually preferable: instead of reading the extra bytes and sending them back, the offending code traps, triggering an exception which implies termination of the thread or process or connection. The bug is still there, not the far-ranging exploit; the leakage of secret data has turned into a basic potential denial-of-service, which will often be limited to closing the affected connection, therefore not denying much service after all.


Local certification authority and certificate chain

If my local certification authority would be provided with a
  certificate issued by an internationally trusted CA, external devices
  would be able to reconstruct the certificate chain and so, in the end,
  accept the certificates I issued as valid?

Yes. This would turn you into an intermediate CA (provided the required key usages have been set), which generally should be trusted with all the responsibility that comes with that task.

Note that this basically turns you into a (nearly) fully-featured CA and you really don't want that. Besides that, there are companies that sell you your own PKI (presumably for automated server setup).


In the context of advanced electronic signatures, what does "sole control" mean?

I'm a Public-Key Infrastructure (PKI) developer, we definitely develop software for that use-case, so I can speak to the software side of your question. Complying with European law is more about how you write your corporate policies (and how you enforce them).

In a use-case like that, we would recommend that users have 3 keypairs (pairs of public / private keys):

An Encryption keypair for keeping documents confidential,
A Signing keypair, usually for user-login operations (called authentication) like signing emails, establishing SSL/TLS or VPN connection, etc,
A Nonrepudiation keypair for signing legally-binding documents.

While it's technically possible to have a single RSA keypair do all three jobs, we recommend three different keys because there are usually different policies around how each is handled. As mentioned in this answer, nonrepudiation keys usually have the strictest policies for what you are and are not allowed to do with them. These policies define what it means for a key to be "under the sole control of the signatory". For example:

Non-repudiation keys should never be backed up to a server.
Non-repudiation keys should only be used when the human to whom it belongs is sitting at the keyboard (ie no auto-logins like a VPN key would do)
Corporate policy should dictate that you should never share the password for your non-repudiation key with anyone else.
If two people do get access to the same nonrepudiation key, corporate policy should dictate that the key be destroyed and a new one issued to the rightful person.
etc...

As I understand it, each regional government has a list of key-management policies similar to the above that you have to follow in order for your digital signatures to be considered legally-binding. These policies are meant more for the administrators of your computer newtorks rather than for software vendors.

I'm no law expert, but my guess is that for your "document uploading" scenario, you'd need the uploads to be signed by individual humans rather than by a company-wide shared key. ie "This document was uploaded by John Smith, and in verifying his signing certificate, we can verify that he is an authorized document uploader for this company".


How to block foreign language UTF-8 characters in usernames?

Should I add a function checking with regex or something?

There are lots of unicode characters. Lots and lots of them. If you are concerned about weird characters in usernames, a blacklist will not solve the problem. You'll need to use a whitelist instead.

One solution is to go with alphanumeric plus some special characters like - and _. That could be done in a regex like this:

/^[a-zA-Z0-9_\-]+$/

If you want to be more permissive with the special characters you could allow all printable ASCII characters. They go from #32 () to #126 (~). So you would get this regex instead:

/^[ -~]+$/

Note that this will not give you any XSS protection - the username <script> would be allowed. Still, there are special characters this will forbid, like ¤ and £. If you want to include some, you can add them one by one to the whitelist.

  For example changing the default charset in php.ini back to the default and simply sending a header changing the charset when I'm outputting in another language?

Messing around with multiple charsets at the same time is a sure fire way of opening up XSS vulnerabilities and similar by mistake. Don't do this. Just stick with UTF-8 all of the time.


System-Level Network Security (Packet Classification and etc.) - SELinux and Libnftnl

Any form of network labeling for remote connections requires a robust Authentication system: SELinux uses IPSEC to achieve this;
though you can apply IPSEC without SELinux and local port labeling without IPSEC.... what are you trying to achieve?


How in-house certificate authority works (e.g. EJBCA)

What you are describing is basic Public Key Infrastructure.

When you run your own Certification Authority, you have to manage the root CA cert. For it to be recognised, you have to deploy it to your clients, which can be done using the "well known root CA" of browsers, but won't be until you can get recognised as a proper CA (see here).


First, we should look at what the name "Trojan" actually means:

In a 10 years long war between the Greeks and the city of Troy, the Greeks built a wooden horse and offered it as a gift to the city (or simply left the horse outside of the city while pretending to sail away - stories differ sometimes).

The inhabitants of the city pulled the horse inside, where nothing happened until the night. The horse actually contained soldiers, that slipped out, opened the gate to the returned sailors and murdered everyone inside the city of Troy, thus winning the decade long siege.

Therefore the metaphor for a "trojan horse" when it comes to computer security means "something that looks innocent, you put it into your computer where it stays dormant for some time until it activates something bad for its host".

Today, most trojans dont look like horses anymore, but can take totally different forms.

1) No, they dont need to be .exe-files only. They can be .bat (batchfiles) as well, MP3s and several different other formats. Especially on Windows-Systems the user can de-activate the extension to show up, so a attacker can name its trojan "InnocentWordFile.docx               .bat". The user will usually only see the first part and not the .bat-part.

The "shell" does not matter, the important part is "something, that has something else hidden inside".

2) I am unaware of a MP3-trojan. There might be vulnerabilities in certain players, but there is a better way of creating a MP3-trojan. Simply look at point 1): "MyHottestMixtape.mp3           .exe". When the user clicks this file, the trojan starts a player (either its own or a system player), plays the music while it does something else in the background.

3) Yes, because that is the definition of a trojan: It looks innocent from the outside, but contains something malicious on the inside. So code / software you load from a untrusty site might contain trojans.

4) I bet there are forms for a trojan that I am not having in my mind at the moment. In general you should install software from a trusted source (dont download .apk-files from "somewhere" for your Android-phone but from the Google-Play-Store) and have a virus-scanner handy.

You also can use virtual machines / sandboxes in order to test new software without infecting your machine.

But be aware, the time that a trojan takes to do something noticably can be large!


How to block some websites in a small office?

I believe that you can do this with OpenDNS.  You can probably learn enough of OpenDNS in a few minutes to do this, and as a side effect you'll significantly improve your overall security and quite possibly your reliability and speed.  Alternatively, depending on the router you have, you could flash it with dd-wrt (or CeroWRT or tomato).  This requires significantly more technical skill, but will result in a much more powerful tool. (and if your router doesn't support one of these, you can buy one that does for under $100).

Of course so long as the employee's have administrative access to their laptops and either a modicum of technical skill or the ability to follow directions on the internet, they can defeat all these measures.  Depending on how important it is to you that these sites be filtered, you need to detect violations as well as prevent them.  Much of the ultimate answer depends on how much assurance you need.


An option is to create a hash of the file and have a program (or script) regularly compare the stored hash with the current hash of the file. While it will not prevent modifications, it will detect changes and alert you (detective vs preventative control)


ClamAV detects virus in Modsec Audit logs

How does ClamAV work?

ClamAV works based on signatures. Many people often falsely believe that anti-virus software is based on hashes, but this is false. This answer by a guy working for an anti-virus vendor explains this more in detail.

The way signatures work is similar to how regular expressions work. It takes a pattern and tries to apply it to a file (or parts of a file) being scanned. If the pattern fits, then ClamAV will return a positive result.

If the file is actually malicious, then we call this a true positive. If it's not malicious, but was detected as being malicious, then it's called a false positive.

Why does ClamAV detect this file?

I decoded the signature for Win.Exploit.Unicode_Mixed-1 and it's as follows:

VIRUS NAME: Win.Exploit.Unicode_Mixed-1
TARGET TYPE: ANY FILE
OFFSET: *
DECODED SIGNATURE: jXAQADAZABARALAYAIAQAIAQAIAhAAAZ1AIAIAJ11AIAIABABABQI1AIQIAIQI111AIAJQYAZBABABABABkMAGB9u4JB

This sadly doesn't include any information regarding the nature of the supposed exploit. I tried to search for information, but only wound up with people having the same false positive. This answer explains the problem more in-depth.

What to do now?

The name Win.Exploit.Unicode_Mixed-1 implies it's an exploit specific to Microsoft Windows. Given that you are running a Debian environment means that this should not affect you. Further, this signature was found in a log file, which further leads me to believe that it's a false positive.

Given that this signature is rather dubious, I would disable the signature by running:

echo "Win.Exploit.Unicode_Mixed-1" >> /var/lib/clamav/whitelist.ign2

Please note that /var/lib/clamav/ is the default directory of ClamAV database files on my system. Your distribution may have a different path.


Can a botnet be used to effectively break encryption keys?

No, most cryptographic methods that are considered secure are based around assuming every computer in the world is working on the problem non-stop and it still takes to the heat death of the universe.

Sure it could be used to break less secure encryption, and in fact, using a super computer to crack such weak keys is effectively the same thing as using a bot net, but that bit length wouldn't be considered particularly secure if that would make a difference.

It is generally a safe assumption that government entities can put far, far more computing power in to trying to crack something than even the most powerful botnet could handle.  And there are far more profitable things for botnets to be working on.


If you want to use your printer, you cannot mitigate all risks. Even if it is at this moment not possible to hack your specific printer, that does not mean that it won't be possible in the (even near) future. So you need permanent subscription to security/vulnerabilities reports.

What is the worst that can happen? According to Columbia PhD student Ang Cui and Professor Salvatore Stolfo (look them up with google), HP printers can set your house on fire. Or print illegal material (and report you to the cops). Oh, and maybe as a stepping stone.

I am often puzzled by the security needs of people that buy simple SOHO printers. They go far beyond the requirements that medical institutions, banks or even intelligence agencies have for their printers. I hope that someone will explain these extravagant security requirements.

If your security needs are so elaborate, you must look into specialized printing devices (with their price tag) or put them in a Faraday cage (Mu copper, soldered with a centimeter overlap). If you think that is too expensive, than you probably don't want to mitigate all the risks.

At the time of this writing, there do not seem to be any known hacks to mobile printing, other than those that allow printing (of possible "alternative" content).


This is kind of an opinionated question.  I also think antiviruses are overrated, but its an interesting topic.

I think that malware/virus behavior is where things will go.  Creating signatures based on behavior rather than the binary itself.  So I think some kind of analytics will be the way antiviruses will go, whether it be in the cloud or not.

Essentially automating malware analysis by doing analytics on registry accesses, function calls, system file accesses.  Obviously this would take a lot of processing power if you're doing live scans.  So whether nightly logs of these get uploaded to a cloud for analysis, or you just have a ridiculous machine and run it anyway it'd be an interesting metric.  I'm not sure how much of this is going on in current antivirus software, and if it is please comment and let me know.

But signatures based on binaries is pointless in the ever changing/obfuscating malware world.  Looking for common behavior patterns is an interesting topic to go down.


Yes, there are libraries for most programming languages. For example, for PHP see: http://php.net/manual/en/mcrypt.examples.php for some examples.

I would also recommend that you start out with basic, symmetric encryption (both sides have the same, 'pre-shared' key), before starting on the complicated stuff with private/public key pairs.


Getting AVAST alert during program update/upgrade in Kali Linux

Kali Linux contains a ton of malicious tools, so it's expected that antivirus software complains about them. This can happen if it scans the network traffic during upgrade, which is probably the case now, as the upgrade uses plain HTTP connections. Some antivirus software might also scan the disk images of virtual machines. Both may cause problems to or break your Kali installation, so it might be a good idea to add some exceptions.
Despite technically malware, these aren't a security problem per se, but they are powerful tools that may cause problems if you don't use them wisely. You might end up weakening your security if you attack against your host machine.


"screened" means "has been verified to be good and strong and not deliberately weakened, by somebody who knows what this means". In practice, this means that the parameters have been generated with a NUMS method.


Phishing domain converting text due to special character?

Browser is doing this to follow the standard regarding hostnames containing non-ASCII characters:

  Non-ASCII domain names ("IDNA") rely on a special transfer encoding
  ("Punycode") to allow non-ASCII domain values inside the ASCII-only
  DNS nameserver hierarchy. Punycode encodes a domain name such as
  "faß.de" using special markup that looks like so: "xn--fa-hia.de"

This is done for all domains containing such characters, and has nothing to do with domain being phishing.

PS. Your "steạmcommunlty" domain name also uses lowercase L instead of I in the word "community".


You're perhaps conflating GMail API and Google Auth (which is used by GMail).

The site cannot see whether you're logged in or not (it can be worked out with a bit of trouble), and cannot access your email address, much less your inbox.

You can give Google permission to give the site information about your Google login. At that point the site'll know your email address (but still be unable to access your inbox).


Are there any known hacks using caller ID protocols?

I don't know of any bugs that specifically exploit caller ID handlers, but there have been a handful of very severe vulnerabilities that could be triggered simply by sending an SMS. An example was Stagefright, which exploited SMS messages with MMS attachments. It required no user interaction. Yes, more exist that are unpatched (that's true of all software), but it's not something you need to worry about coming from mere robocallers. If they are discovered publicly, they will likely be patched quickly.


I wouldn't recommend connecting any machine direct to the Internet if you can help it. There are too many attack vectors that you are exposing yourself to, many of which will be unknown.

In any case, doing so would be very unusual indeed. In almost every case, you would connect the server via a router that would have at least some basic protections built in. Things such as invalid packets and basic Denial of Service attack protection are common. You would also use that to limit the incoming open ports and forward incoming traffic to the correct internal IP address (NAT).

In addition, you need to make sure that:

The server & its software is constantly patched. Ideally, patches should be pushed from a trusted server deeper inside a protected internal network.
You are running anti-malware protection. At least Windows Defender.
You should turn off every process that isn't needed and uninstall all unnecessary software and services
You should move the RDP connection onto a non-standard port. You can do this at the router/firewall using port forwarding or on the server itself.
You can also configure the RDP server to use TLS which will provide additional protection over the standard RDP traffic.
You must make sure there are no default user names on the server and that any user ID's have very strong passcodes, especially admin users.
You should use another machine - preferably further inside a protected network - to grab logs from the server and those logs should be monitored for unusual activity. This should be done automatically using a monitoring system.

You might also want to think about denial of service attacks. If the application that is being served is a web service, you might consider using a smart CDN service such as Cloudflare to provide smart caching and DDOS protection. In that case, you can restrict incoming connections to the app port to only be from the CDN.

Of course, how much effort you put into this depends partly on the value of the information the server is handling. But you also have some responsibility to the rest of the Internet to ensure your server doesn't end up as part of a botnet.


someone trying to SQLi server using sqlmap

You can do an agent check, which will stop those who are dumb enough not to change the agent - block any request with an agent string that includes 'sqlmap'

However, I will note that if you are actually getting SQL errors, that is a sign that you may be vulnerable to SQL Injection.  If you are properly using parameterized queries / DAOs / PDOs, you should not get a SQL error.  An attacker should never be able to get your SQL to error - if they can, they may be able to change its execution.


Is there any reason to not show users incorrectly entered passwords after a successful login?

The primary issue is that incorrect passwords have to be stored in a way that allows them to be later displayed to users.  Which, as your dev pointed out, means they can't be cryptographically hashed first.  The result is that you store them either as plaintext (bad) or encrypted (better but not normally recommended).

The biggest risk is if this database of invalid passwords becomes accessible to attackers.  Either they compromise the server, perform SQL injection, or retrieve it in some other way.  Rather than cracking the primary passwords, which hopefully are strongly hashed and therefore tougher targets, they could decide to compromise accounts using the information in the invalid password history.  Either they access the plaintext passwords easily, or they attempt to find the encryption key that allows them to decrypt back to plaintext passwords.

A common source of login failures is minor typos during the password entry process.  So my password is Muffins16 but I type in mUFFINS16 because my caps lock is on.  Or Muffins166 because I hit the same key twice.  Or Muffina16 because my finger hit the wrong key.  As you can see these variations are close enough to the original that attackers can probably determine the valid password from invalid passwords by trying a few minor alterations or comparing wrong passwords to likely dictionary words or names.

This problem is exacerbated because most people use password choices similar to these formats and not random strings.  It is harder for an attacker to identify the typo if your invalid password is V8Az$p4/fA, although still much easier to try variations of that then guessing it without any info.

Another risk is that users may not remember which of their passwords they used on this site so they try their common ones.  Now this site is suddently a bigger target because an attacker might be able to not only compromise a user's account there but also on other sites with the handy list of 'invalid' passwords.

You can mitigate some of these risks by wiping storage of invalid passwords immediately after display following a valid login.  That should limit the window of opportunity for an attacker to access and benefit from the data.

The question you should probably ask your client is how they predict users will benefit from seeing their invalid passwords.  Is it so users can identify how they mistyped their password?  Typos aren't intentional so it's not likely that showing them their mistake will improve future login attempts.  So users can identify an attacker trying to guess their passwords?  Similar feedback can be provided by listing date, time, IP/geolocation or other info for invalid attempts without the attempted password.  So users know that they screwed up during password entry and don't blame the site's login system?  This seems like the only one with merit and I'm not sure it provides enough value to justify the risk.

My guess is that once you better understand what they're trying to accomplish with this feature you can probably suggest more secure alternatives.


32-bit Radio Voice Encryption, is it really that secure? If so, how?

I agree with your analysis of the reasons why police departments and other agencies would use "weak" encryption products with their radios: simply because as of the current day encryption crackers are rarely used by common criminals that listen to radio transmissions of such agencies (they perhaps use analog/digital radio scanners, but such scanners can usually be defeated by using encryption of any kind, even if weak and/or proprietary).

It is true, however, that 32 or 56-bit encryption of any kind is pretty weak and can be bruteforced with proper knowledge of the radios and communications protocols used in them. This is why most agencies that process anything related to "national security" or "classified information" (think DHS or FBI) do not use such forms of encryption, but instead use actual strong encryption such as AES-256-GCM (see 1 and 2). That, or they use their own proprietary encryption algorithms (eg. Type 1*) and modules.

*Motorola (which is a common vendor) has boards/modules that support Type 1 encryption (see the FASCINATOR module in 3 and usage of Type 1 in the section "2.2 Security Features" of 2).

References:

http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1752.pdf
http://www.crypto.com/papers/p25sec.pdf
https://en.wikipedia.org/wiki/FASCINATOR


How to block some websites and torrent usage in a small office?

Don't waste time with complex technical measures: make clear to the employees what your policy is, then simply fire the next person who torrents a film.


Google Authenticator - Showing someone my code

It should be safe, as the OTP will change quickly (don't show it on live-stream though) and OTPs are designed in such a way that knowing previous ones does not allow you to figure out the next. I would still not recommended showing it if you can avoid it, just to be safe.


Secure way of sending an email attachment in a user-friendly manner

In the past when dealing with non-technical people, or people in environments that preclude them from installing custom software, the lowest common denominator fallback has always been Encrypted Zip.

Nearly everyone has the builtin ability to double click an encrypted zip and enter the password.

This begs the question of how to exchange the password. Typical possibilities include:

Direct phone call
a Separate email

Hinted: The name of the person's cat we talked about
Direct content- Password:   OpenSessamee
An email from a third party


Sandbox escape of an isolated turing complete language?

Escape from sandboxes is done not on languages but on implementations. I have seen the following VM implementations:

pyethereum (Python)
go-ethereum (Go)
libethereum (C++)
EthereumJ (Java)
Ethereum JS (JavaScript)
Ethereum Client Haskell (Haskell)
ruby ethereum (Ruby)

Each implementation relies on the correctness of the compiler/interpreter and the correctness of the implementation itself. An attacker would want to escape from the Ethereum VM and to achieve this he'd have to exploit a combination of bugs in the compiler/interpreter/standard libraries and in the implementation itself. While a difficult task, it's by no means impossible (most likely, involving zero-days). I'd say libethereum is the most vulnerable one being implemented in C++...

In a few years, as Ethereum gains acceptance, there will come out a dominant implementation which will make the attacker's task easier (webthree-umbrella has the canonical Solidity compiler).

To provide defense-in-depth from such attacks, one would recommend running Ethereum sandboxes inside general-purpose VMs. Even then, the main method of preventing attacks will IMHO rely on checking contracts manually:

Go to EtherChain.org, get the contract's source code.
Get the bytecode you're being fed. Disassemble it yourself.
Compile the code and compare with the received bytecode. (See this question at Ethereum SE for details - turns out to be a PITA).
???
Avoid losses.
Start the hue and cry if you see a malicious contract...

Note: existence of two Turing-complete languages (Solidity and Serpent) and dozens of compiler versions (60+ Solidity legacy incarnations) at this stage makes it more difficult for the defender to detect malicious contracts.


Is it possible to DDos a http wan filterd router?

Yes, it's possible to DDoS even if no ports are open.

Keep in mind that a DDoS attack works by exhausting a resource. It can be processing power, storage, memory, or bandwidth. So if an attacker sends way more traffic in your way than your network can receive, your network access will be severely degraded. No matter if there's a service active to receive the packets.

The most effective way to counter such attack is to work with your upstream ISP and tell them to drop every packet assumed to be part of an attack. That is not cheap or easy, but is how most internet services protect themselves.

The other way is to increase the network bandwidth to have more resources than the attacker, but this is more expensive than the former solution.


There is no need to use physical isolation for ransomware. All you need to do is set your backup server to accept new data but not overwrite or delete old data. This can be done by correctly configuring rsync, for example, or by using a filesystem with snapshots like ZFS. Ransomware is not particularly sophisticated and is not going to waste a valuable 0day exploit just to bypass Linux access controls.

You can avoid natural damages, such as power surges, by using proper surge protection. If this is not built into your datacenter, you should get surge-protecting equipment to clean the power. Be sure to follow the 3-2-1 rule of backup: 3 copies of the data, 2 onsite with different storage types, and 1 offsite.


How do country's block politically charged spam?

They may use machine learning and data analysis techniques similar to those used for spam filtering to find seditious content. As with spam filters, if you chose your wording carefully, most likely it will get through (but you need to be aware of what wording they are filtering on so it might take some trial and error).

If you want to employ methods of communication which require you to send sensitive information you could opt using SMIME or PGP to encrypt your email's content (providing they let this true).


What information should I provide to third party pen testers - (black box penetration)

Given that the penetration testers have a limited amount of time (since you provide them with a limited amount of money) they can do a better job in that time the more information they have from start. Thus, if you are interested that they actually help you to increase your security you better give them all the details they want.

If instead you want to have a result which says that they did not find much in the time they had, then make their job as hard as possible and provide no information at all. But while such result might look good in a management report it will likely not reflect the true (in)security of your network.


Why don't digital signatures reveal the senders Private Key

There seems to be some confusion here about the difference between digitally signing and directed message encryption. If I digitally sign something I indeed need a private key to do so. But you can take my public key and verify that the holder of this public key did indeed sign this .

Where decryption is concerned. Yes a private key is required to decrypt say a message of some sort. However what we do is, before hand, exchange public keys with one another, and I encrypt the message with your public key not mine (or both depending on the algorithm or purpose). That way only the holder of the private key associated with that public key can decrypt it (i.e. you).

To make this a bit more clear they are different ways of using RSA alltogether, basically at a high level:

Encrypt(plaintext, publicKey) = RSA(OAEP(plaintext), publicKey) = ciphertext
Decrypt(cipherText, privateKey) = OAEP(RSA(cipherText, privateKey)) = plaintext

While signing is slightly different:

Sign(plainText, privateKey) = RSA(Hash(plaintext), privateKey) = signature [s]
Verify(plainText; s; publicKey) = RSA(s,publicKey) = output
if output == Hash(plainText) the signature is verified

This is crude, but shows the high level difference between them. The private key is never known by either party. But they can still decrypt and verify using their own private keys, and each others public keys.


Is it a bad idea to let the user responsible for his own symmetric key?

Given the alternative scenario, where you store the key, in order to ensure privacy you need to authenticate the user - so effectively the users password becomes a surrogate for the key.

It's quite possible to implement the key generation and encryption / decryption on the browser - which avoids a potential disclosure of the key in transmission / on your server. This also solves the problem of disclosure requests - working out what third parties are actually able to demand disclosure can be a bit of a problem. On the other hand, there is some value in providing a service where managed disclosure is part of the offering (e.g. individual accounts are set up as part of a group - e.g. a corporate entity - and the corporate entity can establish formal criteria under which the information can be disclosed to another member of the group).

i.e. whether its a bad idea depends on the business model.


How do I bruteforce a WPA2 password given the following conditions?

If we assume that your passphrase was randomly generated (not influenced by human selection factors), then some basic math and a couple of tools can get you most of the way there. Your restriction #3 (each character can be used only once) is the harder one, but probably wouldn't really reduce the total combinations space very much, so I recommend setting it aside for now.

Capturing the complexity

First, take a look at the policygen tool from the PACK toolkit. You can generate a set of masks that match your length and minimums.

You can also inform time estimation using policygen's --pps parameter.
This tells policygen how many passwords per second your target platform can attempt.

For example, if you have a GPU similar to my GTX 970 SC (which can do 185 kH/s for WPA/WPA2 using hashcat), you'll get something like the following:

$ policygen --pps=185000 --minlength=8 --maxlength=8 \
  --mindigit=2 --minlower=2 --minupper=2 --maxspecial=0 -o test.masks
                       _
     PolicyGen 0.0.2  | |
      _ __   __ _  ___| | _
     | '_ \ / _` |/ __| |/ /
     | |_) | (_| | (__|   <
     | .__/ \__,_|\___|_|\_\
     | |
     |_| iphelix@thesprawl.org

[*] Saving generated masks to [test.masks]
[*] Using 185,000 keys/sec for calculations.
[*] Password policy:
    Pass Lengths: min:8 max:8
    Min strength: l:2 u:2 d:2 s:None
    Max strength: l:None u:None d:None s:0
[*] Generating [compliant] masks.
[*] Generating 8 character password masks.
[*] Total Masks:  65536 Time: >1 year
[*] Policy Masks: 2940 Time: >1 year

$ wc -l test.masks
2940 test.masks

The resulting set of 2940 masks covers the set of all possibilities that match your constraints.

Estimating the time

Notice that policygen estimates the time to be more than 1 year. For closer estimation, you may not be able to predict when your specific passphrase would be cracked, but you can establish an upper bound and an average (half of that upper bound).

Using hashcat's maskprocessor tool, you can get the total number of combinations for a given mask. Running that against each mask, and summing the results:

for mask in `cat test.mask`; do \
    mp64 --combinations $mask; done \
    | awk '{s+=$1} END {print s}'

... yields the following number:

5.84746e+13

or roughly 58474600000000 combinations. Assuming 185,000 hashes per second, that's (5.84746e+13 / 1985000) / 60 / 60 / 24 = 340,95 days, or about one year to exhaust the entire keyspace. The average passphrase would be cracked within half a year (half of time needed to traverse the total keyspace).

Of course, this time estimate is tied directly to the compute power available. As you add more GPUs to the mix, performance will scale linearly with their performance.

Starting the attack

To try to crack it, you would simply feed your WPA2 handshake and your list of masks to hashcat, like so. Note that this rig has more than one GPU.

$ ./hashcat -w 4 -a 3 -m 2500 [your-wpa2-hccapx-filename] test.masks

hashcat (v3.5.0) starting...

OpenCL Platform #1: NVIDIA Corporation
======================================
* Device #1: GeForce GTX 1080, 2028/8113 MB allocatable, 20MCU
* Device #2: GeForce GTX 1080, 2028/8114 MB allocatable, 20MCU
* Device #3: GeForce GTX 1080, 2028/8114 MB allocatable, 20MCU
* Device #4: GeForce GTX 1080, 2028/8114 MB allocatable, 20MCU
* Device #5: GeForce GTX 970, 1009/4037 MB allocatable, 13MCU
* Device #6: GeForce GTX 970, 1009/4037 MB allocatable, 13MCU

OpenCL Platform #2: Advanced Micro Devices, Inc.
================================================
* Device #7: AMD FX(tm)-8350 Eight-Core Processor, skipped.

Hashes: 1 digests; 1 unique digests, 1 unique salts
Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates

Applicable optimizers:
* Zero-Byte
* Single-Hash
* Single-Salt
* Brute-Force
* Slow-Hash-SIMD

Watchdog: Temperature abort trigger set to 90c
Watchdog: Temperature retain trigger disabled.

[s]tatus [p]ause [r]esume [b]ypass [c]heckpoint [q]uit =>

Session..........: hashcat
Status...........: Running
Hash.Type........: WPA/WPA2
Hash.Target......: 8381533406003807685881523 (AP:ae:f5:0f:22:80:1c STA:98:7b:dc:f9:f9:50)
Time.Started.....: Sun Apr  9 07:30:31 2017 (1 sec)
Time.Estimated...: Sun Apr  9 08:08:54 2017 (38 mins, 22 secs)
Guess.Mask.......: ?d?d?d?d?l?l?u?u [8]
Guess.Queue......: 1/2940 (0.03%)
Speed.Dev.#1.....:   401.7 kH/s (403.50ms)
Speed.Dev.#2.....:   402.4 kH/s (405.15ms)
Speed.Dev.#3.....:   405.4 kH/s (402.24ms)
Speed.Dev.#4.....:   403.3 kH/s (400.39ms)
Speed.Dev.#5.....:   187.0 kH/s (283.22ms)
Speed.Dev.#6.....:   185.3 kH/s (285.72ms)
Speed.Dev.#*.....:  1985.0 kH/s
Recovered........: 0/1 (0.00%) Digests, 0/1 (0.00%) Salts
Progress.........: 0/4569760000 (0.00%)
Rejected.........: 0/0 (0.00%)
Restore.Point....: 0/456976000 (0.00%)
Candidates.#1....: 1234maMA -> 1618pqAN
Candidates.#2....: 1218pqAN -> 1667yzMA
Candidates.#3....: 1242yzMA -> 1631tgBA
Candidates.#4....: 1771seGO -> 1558paAN
Candidates.#5....: 1784jaAN -> 1816blON
Candidates.#6....: 1261tgBA -> 1523reGO
HWMon.Dev.#1.....: Temp: 63c Fan: 90% Util:100% Core:1822MHz Mem:4513MHz Bus:8
HWMon.Dev.#2.....: Temp: 55c Fan: 90% Util:100% Core:1809MHz Mem:4513MHz Bus:4
HWMon.Dev.#3.....: Temp: 56c Fan: 90% Util:100% Core:1822MHz Mem:4513MHz Bus:16
HWMon.Dev.#4.....: Temp: 50c Fan: 90% Util:100% Core:1822MHz Mem:4513MHz Bus:4
HWMon.Dev.#5.....: Temp: 54c Fan: 60% Util:100% Core:1379MHz Mem:3004MHz Bus:1
HWMon.Dev.#6.....: Temp: 58c Fan: 60% Util:100% Core:1366MHz Mem:3004MHz Bus:1

hashcat will start working through your list of masks, one at a time. Since policygen sorts masks in (roughly) complexity order, the fastest masks appear first in the list. So each mask will tend to take (roughly) more time than the previous ones.

You'll probably not want to wait around until it's done, though. :)


How prevent Javascript from obtaining my location

If you want to be anonymous and are worried about geolocation, don't grant websites access to your location.  You will be prompted about whether to allow a website to access your location before the website can use HTML5's geolocation feature to locate you; make sure you don't allow it.

More generally, follow all the standard strategies for surfing the web anonymously.  For instance, use Tor, and use it properly.  There's a lot already written on this topic on this site; use search to find it.  See, e.g., Different strategies for online anonymity and their +/-s?, How to be completely anonymous online?, How much can I trust Tor?,
What are the pros and cons of a VPN for privacy,
How can I use a VPN to protect my privacy,
How to browse the Internet safely?, Does Java applets reveal the real IP address, even when using proxy or vpn?, Improving the privacy of a casual Web user,
Is it possible to Identify a VPN user by finding relations in traffic?.


How long should 2 factor authentication codes be?

Yes, there is a reason - to reduce brute force guessing attacks against multiple accounts.

All 2FA implementations include an online component that enforces a limited set of retries, ensuring the account is locked out long before an attacker could try all possible passcodes.  The length of the 2FA passcode establishes the probability of a malicious actor guessing the authentication in the given number of attempts allowed.  For example, if the 2FA passcode is 3 digits long and you are given 3 attempts to enter it, the chances of randomly guessing it are 3/1000, or 0.33%.  If the 2FA passcode is 4 digits long, the chances drop to 3/10000, or 0.033%.

While this is certainly a low chance that he'll guess your specific passcode, imagine an attacker with a database of 10,000 accounts stolen from some server.  Attacking just one user account, he only has a 0.33% chance of guessing it, but after guessing three times each on 509 different accounts, the probability he'll successfully guess one is 0.5, or 50%.  By the time he's locked out 2,009 accounts, the probability he successfully guessed at least one valid passcode is .99, or 99%.*  Consider the attacker may not need to successfully attack all accounts in order to gain access - he may only need one success in order to log in to the site and establish a foothold.

Traditionally, detecting a brute force attack relied on recognizing the attacker trying multiple requests quickly with an automated script.  An IP address that is responsible for three or ten locked-out accounts in a row might trigger an alert.  But modern attackers know that by proceeding slowly they can avoid detection; recent advanced attacks have demonstrated this technique in the wild.  Consider an attacker using a botnet of 10,000 zombie computers.  He can command them to slowly launch one random request every few minutes from all 10,000 IP addresses without ever tripping a velocity alert or locking out any account.  It's only a matter of time before he succeeds.

Since detection of this attack is virtually impossible, the only protections left are to make it harder on the attacker, so the odds of correctly guessing a passcode must be reduced.  The two ways to do that are to increase the minimum length of a passcode (to 6 or 8 digits,) or to reduce the number of invalid passcode attempts allowed.  Since reducing the number of guesses would impact usability for the legitimate users, algorithm designers have little choice but to increase the length of each passcode.

* My math skills are not great, so these numbers may be off.  Some mathematically inclined editor should feel free edit this answer to include the proof by correctly using the Bernoulli formula.


Are Amazon AWS instanceIds security sensitive?

I personally don't feel that EC2 Instance IDs are a security problem. These IDs are only useful within AWS and this requires authentication and authorization.

However, there is another method. Tag your EC2 instances with unique information. Then provide that unique tag instead of the instance ID.

Tagging Your Amazon EC2 Resources


For all the hassle it brings, why isn't password management handled by the database?

It would be possible but:

It's not standard SQL (it would have to become a feature, part of the product)
All processing power will be centralized on the database
Not all webapplications use SQL databases

You're just shifting the problem, 10 years ago it would have been acceptable to use MD5+salt. So your database would implement MD5+salt right? Alright 10 years later, you as a developer need to use password again hashing on database level, now the database supports bcrypt, but you still will use MD5+salt because it's what you know right?

Why does it still need to support MD5+salt you might ask? Simply because you are probably still using the same application. The migration to the new scheme will still require developer intevervention, it won't happen auto-magically.

Making it a feature to just use an automatic password hashing algorithm isn't possible because you will have implemented an older scheme for older applications. This would then require the database product to suddenly implement an auto-migration feature. This is complex to implement.

So you can see, the problem shifts from it being a developer issue to a database developer issue.


What is the risk of leaking IMEI / IMSI numbers over a network

The IMEI is a unique worldwide identifier for the phone (the hardware element), while the IMSI is a unique worldwide identifier for the SIM card (so it more-or-less maps to the human user who owns it). See this page. Both are sent "as is" over the air, and thus can be obtained by any attacker with an antenna and located in the vicinity. Knowledge of the IMEI and/or IMSI of some user does not give extra ways to break into the communications of that user; they are not secret values.

However...

There may be a slight privacy concern about IMEI and IMSI, in that they allow to "track" user habits:

An application could generate a random unique identifier each time it is installed on a phone. However, by using the IMEI, the application can tell whether it is re-installed on a given phone; it can also be used to cross-reference the table of known installed application instances with cell phone locations obtained through passive radio listening from some base station.
The IMSI "follows" the user when he switches phones (he transfers his SIM card from his old phone to his new phone).

I can imagine an app which is linked to some "account" on a server; using the IMSI allows the server to more easily automate "relinking" the app when the user switches phones. By the same reason, users can feel that their privacy is breached in that they would like to be able to re-install their app and/or switch phones to "start anew" with a distinct account which is not linkable to their own account.

To a large extent, users can consider their IMSI to be the phone equivalent of their email address. An app which automatically send the IMSI to a server is as much a security or privacy issue as a software application which automatically sends the user email to a remote server; many people would feel uncomfortable at the latter, and it begs the question of why it is done in the first place.

Of course, if an app does something stupid like using the IMEI or IMSI as an authentication token, e.g. a kind of password to access data on a remote server, then learning the IMEI or IMSI opens access to that data. But that's what you get when you use non-secret data as if it was secret.


Does Chrome solve some kind of vulnerability by not allowing me to do what I am trying to do which would not have been possible to solve in any other way other then completely preventing me from doing what I am trying to do?

Yes, it does.

If web pages loaded from file:// were allowed to make requests to other pages under file://, they would be able to read any file on your computer, including sensitive files like SSH keys, browser cookies and saved passwords, and personal documents at known paths.

Changing this would mean that opening any HTML file on your computer -- including saved web pages, as well as HTML documents distributed as documentation or readme files -- could potentially exfiltrate sensitive data from your computer. Browser manufacturers have determined that this is an unacceptable risk.


You could look for all incoming tcp packets with the syn flag using tcpdump:

tcpdump "tcp[tcpflags] & tcp-syn != 0"

But is going to be very noisy. Great Penetration testers are also great programmers, and they often have to write or modify their own tools.


Possible XML based attacks are:

XML bomb (aka Billion LOLs attack). This is an XML file that uses a recursive custom entity type definition to attack a vulnerable XML parser. The XML bomb has a very small size on disk, but expands up to a huge size when parsed, potentially exhausting the available memory on the victims device.
External entity type that may not return. In this case the XML document defines an external entity type at a URL that either does not respond, or responds slowly. This could cause a DoS on the victims device.
External entity type that expose sensitive information. This is similar to point 2 (and is explained at the same link), but in this case the external entity type attempts to expose sensitive local files (e.g. file:///etc/passwd)

Whether any of these attacks could succeed depend on the installed XML parser on the local machine. I think applications like newer versions of IE, Firefox etc. protect against these, but older versions or some custom software might be vulnerable.


Kippo attempts to guess if the session was automated or a human. So the graph is a little more like "there were 90 possibly human attacks."


Verify whether the IP address is SQL Server

The IP address is just a location identifier of a machine- it does not discriminate as to the type of service running on the machine nor does the IP directly indicate the type of machine. This is like giving someone a street address- it could be a business, a house, even a Post Office Box, but you generally have no way of knowing until you see it in person or learn more about it (P.O. Box is generally pretty obvious).

You could have a dedicated machine running mySQL or some other flavor of a SQL service as a database and have that be its only job, but this doesn't mean that the IP is and forever will be a SQL server.

A way to aid in determining the machine's role is by running a full port scan to determine the open ports on the machine. Something like nmap -sU -sT -p- <target_ip> would produce a full port-scan. Once you discovered the open ports (let's say you find 3306 open, which is the known default of the MySQL service) then you can perform further enumeration and determine the services running behind these ports.

As it was mentioned in this post, it is important to note, however, that just because a port associated with a specific service responds to the scan (either open, closed, filtered, etc.), it does not mean that the associated service is the actual service running. This is where further enumeration and even interaction is needed to know with certain what service you are dealing with.


Why big websites don't secure their front page with SSL?

This says more about friction in enterprise processes than it does about technology.

For an enterprise to set up their website with https throughout, they have to sort out the certs and configuration up front. That requires a bunch of background management and security processes all of which add friction to the deployment project that is probably already under-funded and under pressure to deliver.

So it is conceptually easier for the project to implement a "standard" website then worry about the security once they have proved that the basic site is sufficiently robust and performant.

HTTPS does make some things more complex to manage and thinking about end-to-end caching strategies are a bit harder to manage.

None of these things are excuses really but that is my take, from experience, on the enterprise process.

It is changing and if you change the link to https you will find that it has actually been implemented so that might only be how the URL has been written and communicated - often by non-experts. http should be disabled of course.

Services such as the excellent Cloudflare are also helping since everyone can now present their site over https even without getting your own certificate (though you obviously still need at least a self-signed cert to help secure the traffic between your server and Cloudflare).


Maximally using available bandwidth to masking data transfer and mitigate VPN correlation attacks

if one were to maximally use your available bandwidth continuously, constantly maintaining an encrypted tunnel to a VPN provider (who we assume now is a good faith actor), would that be sufficient to mitigate significantly against correlation attacks?

It will be sufficient to get you kicked in short order by either the VPN provider or your Internet provider.

  I have little doubt that my ISP wouldn't like me actually using the bandwidth I'd paid for

You guessed it.

  I imagine that the moderately beefy VPN server I'd connect to could silently drop the NOP packets (or equivalent) with a minimal performance hit

But it will still affect their bandwidth bill.

  This seems like an obvious idea -- what is it usually called?

It is usually called a DoS attack.

  Is there an open-source implementation in, e.g., dd-wrt to perform it?

Don't try it, Anakin.


You are looking for secret sharing algorithms. Once such scheme was proposed by Shamir, called Shamir's secret sharing algorithm.

Quoting from Wikipedia:

  ... a secret is divided into parts, giving each participant its own
  unique part, where some of the parts or all of them are needed in
  order to reconstruct the secret.


How can I change windows security settings using python? i.e. Password Requirements / Require Ctrl - Alt - Delete to log in

You can set the registry key HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\DisableCAD to have value 0.  The following command should (untested) do the trick:

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v DisableCAD /d 0 /t REG_DWORD /f


For RSA there are special requirements on how to formulate a key. Primarily (pun not intended) you need the p and q values, which are large primes.

There are, however, schemes (see here and here) which can be used to deterministically generate asymmetric key material from a passphrase.

The easiest way to achieve such a goal is to take a known-secure PRNG design, then seed it only with data derived from the passphrase (e.g. bits from a PBKDF2 or scrypt hash), then use it in your RSA key generation when picking the p and q primes (this is quite well described in the RSA wikipedia article). This ensures that, given the same passphrase, the same random number sequence is always produced during key generation, leading to deterministic keys.

However, there are certain security drawbacks, primarily around key complexity and memorisation issues compared to the comparative entropy of more traditionally random key generation.


Can my SIP conversation partner identify my location?

SIP separates call signaling and voice data, to allow SIP routers to remove themselves from the data path. Some software does this, some doesn't, so whether the remote party is given your IP address depends on the SIP routers on the way.
In the easy case where your SIP client is running on a machine with a global IP address, it will open a random local port for voice traffic, and send an INVITE packet containing the global IP and the port number, which is forwarded verbatim to the client on the other side, which then uses it to establish a connection. This method works even if the other side is behind NAT, and routes actual voice traffic in the most direct way possible, but both sides of the conversation learn the IP address of the remote party.
If both sides are behind NAT, software may attempt to configure NAT traversal, if it succeeds, we're back to the first case.
If NAT traversal doesn't work and a proxy is available, or a router on the path is configured to route all traffic through a proxy, it will modify the address given in the INVITE message, do the same in the reply, and both sides will only learn the IP address of the proxy.
IP addresses are not accurate locations, but allow some educated guesses. IP geolocation is its own topic, so I've focused on the SIP specific aspects here.


How to safely store bearer tokens on server?

If requests from the third party to the OAuth provider have some other data that associates the request to the user, for example the user's name or id, the server could store the bearer token like a regular password with individual salts. However, if the third party requests don't have a piece of identifiable information, the server could store a salted+hashed version of the bearer token with a shared salt for all bearer tokens. Because OAuth tokens expire quickly a unique salt isn't nearly as important compared to a password which might never expire. If the token expires after 6-12 hours the attacker can't realistically crack the hash and use it to access a user account. The server could then periodically rotate the salt every week or so for additional security.


U2F protocol - Counter value & device cloning

Let's plot out a scenario:

T = 1     Authenticate Real, Counter = 20
T = 2     Device is cloned into Real / Dup
T = 3     Authenticate Real, Counter = 21
T = 4     Authenticate Dup, Counter = 21

Because the server saw the same counter twice, obviously it was cloned.

  The attacker could send a counter value bigger than the counter stored in the database of the relying party

Okay, let's try this, by e.g. adding 1000 to the counter.

T = 1     Authenticate Real, Counter = 20
T = 2     Device is cloned into Real / Dup
T = 3     Authenticate Real, Counter = 21
T = 4     Authenticate Dup, Counter = 1021

Seems fine...

T = 5     Authenticate Real, Counter = 22

Uh oh - 22 is less than 1021 - now the real key has been denied and the user knows something's up.


This website claims that password + cookie counts as 2FA

Your question is really more about definitions than about the actual real security of the system. So let's define some terms before getting to your question:

As I learned it, there are three broad categories of authenticators:

Knowledge (something they know) - passwords and other secrets
Possession (something they have) - access to an email account to retrieve the one-time PIN
Inherence (something they are) - usually biometrics like facial recognition, finegerprint or iris scan

Borrowing from the tag wiki for multi-factor (which I wrote):

  If you are required to provide a proof of identity from more than one of the above categories, then it is properly "Two Factor Authentication", or "Multi-Factor Authentication". If you are providing multiple items from the same category, then it's called "Multi-Step Authentication", which is obviously weaker than multi-factor.

Wikipedia seems to agree with this definition.

Cool. So as for your website,

  I login to a website and provide a UserID, Password and one-time PIN delivered via EMail or SMS.

Password = Knowledge
Email/SMS = Possession.

==> Pass! This is MFA.

  My question is, is the second login considered MFA (Password + registration cookie)?

Password = Knowledge
Cookie = Knowledge (of the text)? Possession (of the device)? Uncertain.

==> Questionable.

Arguments for "yes": if the cookie is implemented properly, then it counts as possession of the device.

Arguments for "no": possession-type factors really ought to be immune to record&replay attacks; with any kind of one-time codes - hardware tokens, apps, email, SMS, etc - the server won't let you use the same code twice. Same with crypto USB sticks / cards you need to insert into your laptop. In this case, someone intercepting your traffic to the website will snatch both your password and cookie in the same packet and then be able to log in as you somewhere else.

That said, it does protect your account against, for example, their password database getting stolen, or you re-using a password of yours from a different site that shows up in a leaked passwords database. Questionable.

On a technicality it probably is 2FA / MFA, and offers more security than either password or cookie by itself, but less than continuing to do the Email / SMS thing.


Are There Any Standards for building pin code authorization?

I think your boss may be misunderstanding the situation it a bit.  If a user is logging in a website using a web browser and convenience is a major factor to them, they will most likely have their browser/password safe save their username and password for them.  With this scenario, the user doesn't have to do anything but click a button in their browser.  All the PIN will do is make things more complicated for the user, annoy them, and will very likely make your system less secure (due to implementation flaws).

To answer your questions above:

The NIST is probably the best bet as far as standards go.  Since this
is basically a password, look for their password complexity
requirements (Note, a PIN will fail pretty much every one of these)
I  am not aware of any large websites using them.  The only place
PINS    are really used is on mobile phones, and they are a different
use    case all together.

The bottom line:  The proposed solution is going to cost money to provide no benefit, and will weaken your security and potentially leave the company liable to a lawsuit.


Surely I haven't won the lottery, but where's the scam?

I created a fake gmail account and emailed the address you posted.  I got back something that very much looks like it will turn into advanced fee fraud..  One of the Hallmarks I've seen is the spelling out all the dollar amounts in numerals, as well as words.  i.e.

  On behalf of the Management and Staffs of WORLD LOTTO MOBILE PROMO, We officially congratulate you as the beneficiary of the cash prize of €780,000.00 (Seven Hundred And Eighty Thousand Euros). My names are David Hoffman,

It goes on, trying to invent fake details to establish legitimacy, and continually mentioning large amounts of money in an attempt to get you hooked.

  This promotion is approved by the British/USA Gaming Board and
  licensed by the International Association of Gaming Regulators (IAGR).
  This promo is the 1st of its kind and we intend to sensitize the
  public about WORLD LOTTO MOBILE PROMO. Your Mobile Number attached to
  a reference, won you €780,000.00 (Seven Hundred And Eighty Thousand
  Euros) cash prize and your check will be issued in your name provided.

The MO is generally always the same.  Get the mark convinced they've won some large amount of money, but you juuust need this little amount of money to pay some fee associated with winning the money.

If you wanted to be certain you could likely just email back and forth with this guy, preferably from a fake email address.  Some people do this as a form of entertainment.


Will using unicode chars in my password increase security?

Yes,

In the sense you are increasing the entropy of your password, making it harder to perform bruteforce attacks against.

I am from a country where we use non-english letters. This allowed me to use characters not common used in a charset by a brute-force applications, but I effectivly locked myself out of my webmail when I used a computer without my regional keyboard settings.

Edit:

Googling NTLM + unicode shows that there is support for unicode as NTLM password.


The purposes of those accounts are different, and so is the data protected by those passwords. If only one password gets stolen, the attacker will be able to access both the services / data / accounts / etc. So to reduce the impact of a possible attack or at least to slow down the attacker, those passwords should be different. Even if the threat model makes you suppose that both passwords will be stolen anyway, there might be some cases where you will be able to detect the attack before both accounts are compromised, so having different passwords will help.

That said, in theory you shouldn't even be asking this question. Why? Because you probably already have tons of accounts with tons of passwords that should all be different, and to manage all this data you will probably have a password manager (or write them down somewhere, etc.). So it should not be a problem for you to use different passwords in this case as well.


This is accomplished via a revocation list vis. RFC 5280.  The client can request a CRL (certificate Revocation List) from the CA (certificate Authority).  The CRL is signed and timestamped by the CA. The client can check against this list during the handshake (note that certain browsers have been lazy historically about checking this because of increased latency).  To avoid added latency OCSP stapling is an option which passes the CRL to the client by the server during the handshake.

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

https://www.digicert.com/util/utility-test-ocsp-and-crl-access-from-a-server.htm

https://tools.ietf.org/html/rfc5280


Well, basically you now have VPN over untrusted connection. This should be fine, if VPN is implemented to deal with that (example that you list does not appear to be though).

If VPN correctly encrypts the data, then only entities in possession of keys (that would be you and your VPN peer) should be able to decrypt it.


Some do. keyserver.pgp.com does for example and it's a useful precaution. However, it would not be sensible to rely on this or you'd be able to publish public keys - and undertake a spoofing attack or man in the middle attack - if you were to compromise someone's email account only and then submit a fake key!

The best way to ensure ownership is checking the fingerprint by word of mouth or some other, trusted, channel.


Create https session between server and client

Yes, the client and server both need to support SSL/TLS.

All modern web browsers ship with this support baked in, such as NSS in Firefox. Unless you have a one off use case, I don't see you needing to worry much about the clients support for SSL/TLS.


Check SSLv3 in Apache Tomcat locally as well as on server on windows/linux

you can check your ssl-setup with either:

SSLLabs (your site must be online)
testssl.sh (cli-tool)
cipherscan (cli-tool)
ssllyze (cli-tool)

you should have a basic knowledge on how to interpret the results though

for disabling ssl in your tomcat please read (there might be interferences yiwth the JVM used):

Disabling SSLv3 and SSLv2 in Tomcat and JBoss Web

"When using Tomcat with the JSSE connectors, the SSL protocol to be used can be configured via $TOMCAT_HOME/conf/server.xml. The following example shows how the sslProtocol in an https connector is configured.

Tomcat 5 and 6 (prior to 6.0.38)

<Connector port="8443" protocol="org.apache.coyote.http11.Http11Protocol"
               maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
               clientAuth="false" sslProtocols = "TLSv1,TLSv1.1,TLSv1.2" />

Tomcat 6 (6.0.38 and later) and 7

<Connector port="8443" protocol="org.apache.coyote.http11.Http11Protocol"
           maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
           clientAuth="false" sslEnabledProtocols = "TLSv1,TLSv1.1,TLSv1.2" />

If the sslEnabledProtocols or sslProtocols attributes are specified, only protocols that are listed and supported by the SSL implementation will be enabled. If not specified, the JVM default is used. The permitted values may be obtained from the JVM documentation for the allowed values for algorithm when creating an SSLContext instance e.g. Oracle Java 6 and Oracle Java 7."


How do you perform SQL injection on a login form that checks for email address format?

Since you're confident that the SQL vulnerability exists based on your Burp results, I'm going to assume that you got that error message from your web client.

Either your input has a type attribute set to email, either there's a JavaScript snippet which checks that your input matches an email address format.

The easiest way to bypass both of these checks is:

Open the network panel of your browser's development tools.
Submit the loin form with a valid email.
Search the request in the log, and perform a "Copy as cURL" command.
Open a terminal, paste your cURL command
Replace the valid email by your injection
Run the command!


Yup, the password was sent.  You can tell from the content length header that the body was not empty.

Firefox shows the POST data in a separate tab when you select the request.


Does setting the cookie-path protect me from XSS from another context?

No. The JavaScript Same Origin Policy allows you to execute code in any document on a given hostname from any other document on the same hostname (+scheme+port).

Compromised code in www.example.com/app1 can interact with www.example.com/app2 through eg forms, iframes and AJAX, giving it an almost complete ability to pose as the genuine user - which is more than just a problem of leaking cookies. CSRF protection does not help you as the CSRF token can itself be read by the script code.

The path= feature of cookies is only of use for preventing accidental clashes; it has no security value. You should only reverse-proxy two applications into the same hostname if they fully trust each other.

Otherwise look at subdomains or full separate domains. (Subdomains prevent apps from reading each other's cookies, but don't prevent a domain= being used to make a cookie available to the other site. This isn't typically a security problem as such, but can be an annoyance when it masks a real cookie and stops the app from working.)


Password reset links: random value or authenticated message?

Creating a random token containing absolutely no information and linking it in the database with a username and an expiration time is by far the best solution.

Encryption (and hashing) is used to store and transfer data that absolutely must be sent.  If there is any way to do something without having to send that data, encrypted or not,  that provides equal functionality and security, you should use that method.  In other words, encryption should be a last resort for securing data.


Charging someone else's cell phone in my car

Since I don't know your car model but you seem to be concerned about information security and the fact that the possible attacker chose your car I make the assumption that the USB port in your car is not power-only.

The telephone could do anything on this USB port because every USB device can identify itself as any device (storage, keyboard, network, display, ...). Have a search for bad USB.

The most critical attack vector is the bus system in your car. CAN is the best known protocol but there are others which are based on it like UDS (which is still weak from a security perspective). You can imagine it as a network in your car where all components can communicate with each other with more or less restrictions.

Here are some possible scenarios:

The USB port could be dual used as a maintenance port which could allow full access to the car bus system.
The car media system could have a vulnerability which could allow privilege escalation to the bus system. (By design the media system should be isolated from the critical components on the bus but in practice all vendors fail to do so.)
If you car supports some kind of wireless features for unlocking and starting, this could be a part of some exploitation technique.
The car could be used as a bridge between the attacker device and your phone (if it's paired somehow with your car via Bluetooth or WiFi) for some kind of attack against your phone.
The car media system could be infected with some kind of malware targeting your smartphone or other connected devices.
Malware which targets your car directly (like ransomware for example) would be also possible but I really really hope that this industry is not at this point yet.
Just to have a sneak peek for some details or to distract you for some reason.

Just to name a few. However. This is a very interesting question and attack scenario. Maybe I would have given this person $100 just to know their real intent in exchange for not calling the cops immediately.


No. Anyway, depending on which version of NFS you plan to implement, you have more options inside Kerberos auth.

For example, if you use NFSv4. NFSv4 includes ACL support based on the Microsoft Windows NT model, not the POSIX model, because of its features and because it is widely deployed. NFSv2 and NFSv3 do not have support for native ACL attributes.


Security of deleted files and their traces

If you copy and paste files, you'll only copy files which currently exist. It doesn't matter whether you select them by clicking on the drive, by selecting them individually, or by any other method. You'll only get the files which Windows thinks are there.

In order to copy the remains of deleted files, you'd need to do a bitwise copy, which Windows doesn't offer as a standard feature. You can make such a copy with various bits of software, or by using a hardware drive cloner. Not all hardware cloners perform bitwise copies - it's possible for one to just copy files, although this actually takes more effort. If looking to buy one, look for ones which state "forensic copy" or similar, but most will perform bitwise copies since it allows them to clone any drive, regardless of format.

A bitwise copy is where the drive is accessed as a block device, ignoring any specific format applied by an operating system, and each bit from it is read and written to another drive exactly as found. If there is a "1" on the original drive, they'll be a "1" in the equivalent place on the clone.

If you only care about the files that currently exist, you can "clone" a drive through Windows explorer. If you want an exact clone, including any data marked as free space, or as deleted, you'll need a more specialized tool.


What are the risks of using non-ssl connection between server and (externally hosted) database?

As a good practice, the connection between the Server and Database should always be over SSL, whether the network/connection is exposed to the extra world or not. In this case, there could an MITM attack by the person having access to the network. Just remember the principles like 'Segregation of Duties (SoD)', 'Need to Know' and 'Need to Have'. Unauthorized should never have access to confidential information.


Can I use Authenticator instead of phone number for Gmail 2FA?

Google Authenticator worked for me - but it was a little bit tricky.

Go to https://myaccount.google.com/security and start the process of enabling 2FA
Google required me to enter my phone number - I could not find a way to enable Google Authentiactor without prior entry of a phone number. So do this and enable 2FA.
Once 2FA is active, you can add a second authentication mode (say Google Authenticator App).
Now you can make the Google Authenticator App your default and remove the phone number from the list of 2FA providers.

I don't know why there is no simpler way to enable the Google Authenticator App - this is really a bit strange. This answer is based solely on my own experience; it might be that I missed something.


nmap tests with uncommon kinds of email address specification where it explicitly tries to bypass filtering. mxtoolbox instead just checks with the common kind of address. Still, both only check the result of RCPT TO. While a failure at this stage indicates that the address is not accepted, it will still be possible to reject the mail at a later stage of SMTP too.
One can only be fully sure that this is an open relay if one is able to actually deliver a mail through the server and then receive this mail. Similar one cannot be sure that this is not an open relay if a single attempt failed - it might still work with a different address format, with a different sender or from a different IP.
Still, based on the result from nmap you better look into the configuration of the mail server to find out why it accepts these addresses. It might be fine if the mail will be rejected at a later stage but it might also indicate a problem.


Trying to understand why signatures in root certs "are not used"?

A root certificate is a self-signed certificate (by definition).

So how do you want to verify the signature of a root certificate? The root certificate is valid in itself, therefore you cannot verify it.

This is also the most problematic part of root certificates: they cannot be validated independently. If they are in the browser, then they are trusted.


Can malware infect more than one operating system?

Short answer: certainly.  Remember that once your system is compromised (step 1 in your question), and attacker can perform downloads and run ARBITRARY code.  A common approach is "fingerprint and drop", wherein the malware determines the characteristics of your system, and downloads appropriate payloads to execute the attack.

An example of a worm which runs on Windows but is designed to attack another system would be Stuxnet.

An example of malware which fingerprints and drops would be any exploit kit (for example, Angler) that uses drive by downloads.


How much more secure is encryption if the program requires random input from the user?

TL;DR:
None, really. Modern computers generate high-quality entropy ("randomness", essentially) fast enough that you wiggling your mouse is irrelevant.
More detail:
Programs like Truecrypt (and possibly older versions of things like ssh-keygen, gpg, and so on) that tell you to do stuff during key generation are operating on the assumption that the OS may not have very fast entropy sources other than user interaction and/or a very small entropy pool for its cryptographically secure pseudo-random number generator (CSPRNG). On old computers, especially without Internet connections or enough resources to run a lot of background processes, this was probably true at least some of the time.
Modern computers are pretty good at entropy generation and have relatively large entropy pools that can easily cough up enough pits to generate a key. Additionally, these days it is common to use CSPRNGs that support stretching entropy (on *nix OSes, this would be the difference between /dev/random, which pulls from the entropy pool directly, and /dev/urandom which can take a small amount of entropy from the pool and use it to generate a large number of slightly-less-random bits; /dev/urandom is, on modern OSes, still generally good enough for key generation). It's still theoretically possible to end up with machines that have predictable kernel entropy pools (a bunch of identical VMs running on identical headless machines running identical software versions started at the same time, etc. may sometimes have the same kernel entropy initially), but it's not easy. This kind of thing is why modern VM hosts have ways to feed some entropy to the VM guests based on the hardware states, etc. that are usually used in kernel entropy generation these days.
Most modern CPUs even have what amount to hardware RNGs based on things like the thermal state of the different parts of the CPU chip, which vary rapidly depending on things like exactly what instructions have been run recently and whether they caused cache misses or not, miniscule variations in voltage from the power supply, air movement in the room, and other stuff like that; the differences are slight, but taken together there's a lot of entropy there and the CPU has dedicated hardware for harvesting it and new opcodes for providing it to the OS. Many OSes mix this into their kernel entropy pool, along with other inputs, making it very hard to exhaust entropy under normal "user" workloads on a modern PC.
IMPORTANT:
There is no CSRPNG in the world that is seeded to any significant degree off of the system clock! The reason why is simple. You seem to think that "to the millisecond" timing is sufficiently random for crypto, but you're quite wrong about that. Let's take something like generating a GPG key pair as an example. Those generally have a validity period on their public keys, which tells me (I have your public key, it is after all public) when the key was generated, to the day. There are 86400000 ms in a day (ignoring the fact that I can probably narrow that down a lot by considering hours when a person is likely to be awake). Log2(86400000) is 26.36 bits. Your supposedly super-secure 4096-bit RSA key pair actually has less entropy than a decent-quality password! Brute-forcing 86400000 different possible key pairs to find the corresponding private key will take a while, but a hell of a lot less time than trying to factor a 4096-bit RSA public key. In fact, there aren't enough milliseconds since the dawn of electronic computing to produce a fully-random DES key (56 bits) by choosing from among them, and we can brute-force DES in under a day using off-the-shelf hardware (yes, RSA key generation takes a lot more work than just taking 56 bits and computing their parity for DES key generation, but it's still fast enough for this purpose).
Instead, any crypto program that isn't purely worthless garbage (and quite a few that are) use a CSPRNG (such as /dev/urandom on Unix-like systems, or CryptGenRandom() on Windows) for key generation. Similarly, most programming language standard libraries include at least two PRNGs: a fast but insecure one for stuff where it doesn't actually matter if somebody could theoretically predict the output (in Java, this is java.util.Random), and a cryptographically-secure one, usually either seeded by or directly just returning the output of the OS CSPRNG, for stuff like crypto (in Java, this is java.security.SecureRandom). No PRNG seeded by the current time, regardless of algorithm it uses, could ever be considered cryptographically secure; the search space is just too small.


In the context of SSL Labs where is the "trust store"?

Why are there two paths? Were do they come from, where are they configured?

A signature is created by using the public key of the issuers certificate. Two certificates can contain the same public key (typical after re-issuing a certificate) and this leads to alternative trust path if both of these CA certificates are included in the trust store.

  What is this "trust store" mentioned? Is it in my browser? On the server I'm testing? On the ssllabs server?

This is on the SSLLabs server where they try to use a trust store similar to the browsers. Of course the real trust store used by the browser depends on the browser and/or OS, so it does not reflect fully what happens in the browser.

  But chrome still complains:

Hard to tell what's really going on, but the signature of a certificate in the trust store is not relevant, only the signatures of leaf and intermediate certificates. It might be a false positive.


How to best prevent data recovery on a disk drive without physically destroying it?

Yes variants of this question constantly recur, nevertheless I'll try to do a quick and dirty answer before this gets closed.
A single pass over write of the raw drive with anything, zeros, random, whatever is sufficient to make data practically unrecoverable. This can be done via direct write or via the builtin security commands.
Magnetic force microscopes are not going to extract the data.
Wear leveling in Solid State drives would require disassembly and chip removal to bypass the wear leveling controllers. Custom chip analysis of the wear level swapped bits can extract unwiped old snippets but this would be expensive, time consuming and have very little context. Standard forensic shops won't do this.
Bad sectors won't be wiped, but if they are truly bad you likely have nothing significant worth the effort of expensive reconstruction of the bad sectors. Yes, bad sectors can be artificially created to hide data, but if you did this you would know it.
Similarly HPA & DCO hidden sectors will not be wiped, but unless you created them and put data there, there's nothing of your's present.
Official classification standards require physical destruction to avoid even the most unlikely release.
Wipe with zeroes then check for non-zero content afterwards to verify. It won't meet military standards but it's a 99.9% solution.
Since you are looking for a simple "Do This", I suggest Eraser, or DBAN.


I'll start by mentioning the usual piece we do when security testing tools are used, which is that it's very important to only use them on sites which you are authorized to test.  Running security tools on sites you're not authorized to test can be a criminal offence depending on your jurisdiction.

That said, I'd say that Nessus is likely reporting that based on the mention of the SQL Exception in the error message, it does imply that the SQL query on that page was modified, although I've seen false positives with that kind of error before.

In terms of how it could be vulnerable, the query behind that kind of page is likely to be a SELECT statement which compares the values supplied for login with the ones stored in the database for that user.  If the page is taking the values directly from the user and putting them into the query then there's the possibility that its vulnerable.

If it is vulnerable, then an attacker can modify the SQL query being run on your site then bypassing the login is one possible outcome, along with an attacker damaging the underlying server.

A good way to test this in a non-destructive fashion might be to use the quote characters and string concatenation.

First check to see if you can reproduce the error.  Enter a single ' character into the field along with valid data in the other fields in that form.  If it throws an error then it's possible that its vulnerable.

Then if you have a valid value for the codetextbox field (lets say it's abcdef) try entering

  abc'+'def

as the value in that field along with valid data in the other fields.  If the application logs you in, it either stripped non-alpha characters (possible but it wouldn't explain your error message) or it concatenated the two strings together, which implies that you have SQL Injection.

At that point your best bet is to look at the source of the page to confirm.


Why is it better to use ports 20 and 53 as source ports when portscanning?

You guessed correctly.
According to the Nmap Reference Guide:

--source-port <portnumber>; -g <portnumber> (Spoof source port number)
One surprisingly common misconfiguration is to trust traffic based only on the source port number. It is easy to understand how this comes about. An administrator will set up a shiny new firewall, only to be flooded with complaints from ungrateful users whose applications stopped working. In particular, DNS may be broken because the UDP DNS replies from external servers can no longer enter the network. FTP is another common example. In active FTP transfers, the remote server tries to establish a connection back to the client to transfer the requested file.
Secure solutions to these problems exist, often in the form of application-level proxies or protocol-parsing firewall modules. Unfortunately there are also easier, insecure solutions. Noting that DNS replies come from port 53 and active FTP from port 20, many administrators have fallen into the trap of simply allowing incoming traffic from those ports. They often assume that no attacker would notice and exploit such firewall holes. In other cases, administrators consider this a short-term stop-gap measure until they can implement a more secure solution. Then they forget the security upgrade.
Overworked network administrators are not the only ones to fall into this trap. Numerous products have shipped with these insecure rules. Even Microsoft has been guilty. The IPsec filters that shipped with Windows 2000 and Windows XP contain an implicit rule that allows all TCP or UDP traffic from port 88 (Kerberos). In another well-known case, versions of the Zone Alarm personal firewall up to 2.1.25 allowed any incoming UDP packets with the source port 53 (DNS) or 67 (DHCP).

A 2005 answer in Seclists.org provides a quote from a previous version of the Reference Guide:

--source_port <portnumber>
Sets  the source port number used in scans.  Many naive firewall and packet filter installations make an exception in their ruleset  to  allow DNS (53) or FTP-DATA (20) packets to come through and establish a connection.  Obviously this completely subverts the security advantages of the firewall since intruders can just masquerade as FTP or DNS by modifying their source port.   Obviously  for  a  UDP  scan  you  should try 53 first and TCP scans should try 20 before 53.  Note that this is only  a  request  -- nmap will honor it only if and when it is able to.  For example, you can't do TCP ISN sampling all  from  one  host:port  to  one host:port, so nmap changes the source port even if you used this option.  This is an alias for the shorter, but harder to  remember, -g option.


Can the System Admin (the main guy with all the permissions) decrypt confidential data from the server?

Answer to your title = YES

Answer to your body question = NO

as an IT Manager, I can confidently answer your question with a no. It is not possible to prevent cypher keys from being stolen by bar or anyone else who have access to the server.

The only counter measure would be storing the keys on a different server but still needs someone who should keeps an eye on and guard. (which goes in a loop)

So in a conclusion, it's a matter of trust no more - the whole thing.

Extra

Anyone who have access to the specified server can decrypt whatever data on it assuming that the encryption keys are stored there too.
also note that a user who has access to the specified server (with unprivileged powers) can work it around using some local / shell exploits in order to get root privileges/access allowing him/her to manipulate and steal or view sensitive information / data, also can implement a backdoor for later on access.
It is impossible to remotely prevent such thing, because if i'm the sys admin of that server, means i have ssh access to it, means i can use an ssh tunnel to work and do the evil stuff behind the server's IP address, so nor firewalls nor anything can block me or prevent me from stealing whatever i want.


A "hardware" random number generator for mobile phone

Without lots of research and public scrutiny, home crypto tends to be very vulnerable to many attacks. You will do better using your phone's secure PRNG.


I read that uuid does not bring any security advantages

This entirely relative to a given context. So it's neither true or false.

  Consider that right now the session id is encrypting the auto-increment id (no uuid is used). If someone manages to know how the session is encrypted, then he can impersonate all the users: encrypt "1" and set the value as sessionID, encrypts "2" and set the value as sessionID, etc.

Session identifiers work if they're long random pieces of information. They do not encode or encrypt any information, these tokens are used by the server to locate information pertaining the established session.

In a typical scenario, client A connects to server B for the first time. They have no information or session id at this point. Server generates a new session id and sends it to client. Potentially authentication occurs and some data is stored on the server pertaining that particular session. Every subsequent request from the client carries this identifier so that the server can match the data relevant to that particular client during this particular session. Notice the data is stored on the server, all the client does is issue requests of whatever kind and tack on the session identifier as a way to maintain state in a stateless system.

Simultaneously other clients are doing the same. The server can maintain multiple states since every client uses their own unique session identifier. If the sessions weren't random or easily guessable, then an attacker could calculate or guess them and hijack established sessions.

So a randomly generated UUID is no better or worse than a randomly generated session identifier for the same length of random data.


Mature CIRTs gather intel on their attackers. What sources & methods are used for this?

Then: Time Well Spent

I used to run an IRT back in 2000-2002 and at the time, the (perceived) greatest threat came from local script kiddies.

We used whiteboards and raw RDBMs (with no GUI or application on top) to track individuals, their nicknames, known successful attacks, group affiliations, internal rivalry, etc.

We knew a lot more about these people and what they'd done, than we would ever be able to prove in court - but they didn't know that, so it was helpful to sometimes participate in various IRC channels. We estimated that we spent less time tracking and "reminding" them of our existence than we would have spent cleaning up after them.

Now: Consult your risk assessments

While I prefer regular sleep over IR these days, I suspect it makes much less financial sense for mature, corporate IR teams to track attackers today. Many attackers are criminal gangs or intelligence outfits located far away. The time required to research individuals and liase with appropriate LE would be counted in weeks or months instead of hours or days.

So, I don't think corporate IRTs gather intel on their attackers and if they did, I'd probably challenge their risk assessment. I have a hard time imagining a scenario where a corporation would be the least bit interested in spending money on knowing who is trying to attack them.

The cost/benefit analysis is obviously very different for commercial/for-hire IR shops, LE and intelligence agencies but none of those fit the term 'mature CIRT' in my book.


gnupg keys and pass database - Protecting both from unauthorised access and loss

While I'm not sure there can be a concrete "correct" way of using pass, what you've described is a reasonably safe setup and I think your assumptions (except maybe #5) are accurate.

To use pass to manage your passwords you need to access(from each PC you might use)

A copy of your /password-store/ directory
Your gpg private key

To protect the availability of your passwords you need to back up

Your gpg private key (public is included in the gpg --export-secret-key process iirc)
your /password-store/ directory

While your password files are encrypted and it's (theoretically) safe to leave them in the open I personally wouldn't leave them in an open GitHub repo. If you don't have a paid subscription with them there are other providers that offer private repositories for free (or you could spin one up on your own hardware/VPS).
Another thought I'd add is to consider using a smart card to transport your secret key. It's a convenient way to get the key between different machines you may want to use it from that

Can't be copied as easily as it could be from a regular flash drive.
Doesn't leave the key on the box when  you're not using it (it lives on the card).


Is Template Toolkit safe against arbitrary code execution?

No, Template Toolkit suffers from multiple different ways to arbitrarily execute code, like this one used in CVE-2019-1978
[% template.new({ 'BLOCK' => 'use Data::Dumper; print STDERR Dumper(\%ENV); die' }) %]

Do not trust user-provided templates.


For failed logins, what information should be given to users?

There is no absolute security. When we are talking about security, it is important to understand what are the threats, what are the risks and what security is enough to mitigate these risks.
User permissions are bound to the user name (login name, account name). So user name is not a secret within a web site. Where as user password remains unknown even for the web site itself (assuming web site is keeping password hash only). That's why the strength of the resistance of the web site to brute-forcing depends not on the fact if user name is known to the attacker, but on the strength of the password only.
What is bad in displaying too many details in case login failed? If you display message "incorrect password", you implicitly confirm that the user name is valid. In case the web site provides online banking, the information that particular user name is registered at this web site can be used by attacker for frauds and attacks. In case the web site represents some political organization, disclosing that particular user name is registered at this web site can lead to reputational problems for particular person.
So should you always provide a very generic message? No. It depends on the context. For instance, if the web site provides some services to the members of the local bowling club and all members are known to everyone in the town, then disclosing that some user name is known (or is unknown) to the web site would not give any new information and thus will not cause any harm to the users. In this case it can make sense to display more detailed message thus providing better user experience.
In you particular case only you (or your users, your customers) can decide what is more important - security or user experience.