Secure forgot password page: Is a server-stateless implementation viable?

Your question is well written, and you clearly understand the issues well. There is nothing fundamentally wrong with the crypto token approach you describe. Some things to be aware of:

Most sites these days are database intensive, so storing a password reset token is little additional overhead.
You should throttle the number of password reset emails that can be generated (e.g. max of 2 per 30 mins, for each email address) - which requires writing to the database.
You are reliant on k remaining secret; this could be copied by a malicious administrator (or brute forced, if weak) - while database tokens avoid this single point of failure.
A common (albeit minor) weakness with password reset schemes is the leakage of the token to external sites in the referer header. Having the token be strictly single use can help with this - although you can fix this weakness with crypto tokens as well.

There is a similar choice with generating session cookies - using crypto or the database. In fact, the performance considerations are much more significant for session cookies, as this work is done for every request. Despite the overhead, most sites use database tokens, for the minor security advantages.


Best Option for SSL Certificate for 2 Domains + All Subdomains

You can place wildcards into the Subject Alternative Name (SAN) field of a certificate, so it's entirely possible to wildcard multiple domains.  There are many CAs that will issue this under a name like "multiple domain certificate".


Using a Public-Key-Encryption browser side to avoid PCI compliance

(Disclosure, I work at Braintree)

If a server is providing a form that customers will enter credit card numbers into then that server falls within PCI scope. This is regardless of if you encrypt the data in the browser. The reasoning here is that an attacker can modify the page that is sent to the browser to siphon credit card data out of the page DOM before encryption.

You would need to work with a qualified security accessor (QSA) or your merchant account provider to know what your PCI process will look like. If you're processing under 1 million transactions then it would likely be a self-assessment process. The determination of which self-assessment questionnaire (SAQ) to fill out is based on how much access to the cardholder data you have and if you store it.


How can I help catch an email scammer who is contacting me?

Forget about it, just report to police (local and in Spain) and let them deal with it.


Can my phone be hacked just by being called?

Any site that claims to be able to do that is a scam.  Such technology would have to exploit some kind of backdoor, and if such a backdoor exists, it would only be known to law enforcement.  If knowledge of such a backdoor leaks, you can be sure that there would be a media frenzy over it, and the vulnerability would quickly be fixed.

Phone monitoring software exists, but all of the legitimate ones require either physical access to the phone to install, or finding a way to deceive the owner into installing it.


A tale of two sources: Is TLS *defense* against Man-in-the-Middle, or not?

To cite the important part from the article you refer to:

  The disadvantage is that this kind of security is applied separately on each hop in the communication path, making the communication susceptible to a man-in-the-middle attack.

TLS is used in different use cases. Some of these cases involve a single end-to-end transport of the message, for example by having a client sending a message to a web server which then gets directly processed by the server. TLS successfully protects against man in the middle attacks in this case.

But TLS is also used when multiple hops are involved. In this case the transport is only protected with TLS between these hops but a man in the middle on any of these hops can intercept the unencrypted data. This use case is typical for mail (i.e. SMTP) but you also find it with HTTPS when using a reverse proxy, content delivery network or similar. In these cases TLS provides only hop-by-hop security but not end-to-end security. The latter can be achieved by encrypting the message before transport and decrypting it after the full transport (i.e. all hops) is done. For mail this is usually done with PGP or S/MIME.


Clarification on an email about a security breach

What a salt does is it renders rainbow tables useless, which does slow down bruteforce attempts on the password.

Definition of rainbow table:

  A rainbow table is a precomputed table for reversing cryptographic
  hash functions, usually for cracking password hashes.

Without a salt, an attacker could easily use a pre-generated rainbow table containing millions of passwords and their hashed equivalent and compare it against the password.

With a salt, every password requires the attacker to generate an entirely new rainbow table.

It has no impact on dictionary attacks - easy, obvious dictionary based passwords like password will be cracked easily with or without the salt. Brute forcing the password will also eventually recover the password.

Password cracking is all about time/effort. No password/hash is invincible. It is all about forcing the attacker to spend more time than he is willing to spend on your password tables.

If there is a potential compromise on the site, you might want to consider changing passwords.


Is there any way of recover a locked drive using TPM?

Many TPMs will allow a backup to be stored of the key either prior to loading it on to the TPM or via some kind of export.  As long as you have the key, you can reload it on a new TPM if the TPM fries.

I actually had this exact thing happen with an IBM ThinkPad with an early TPM where the TPM circuit fried and I had to replace the system board.  I was able to reload the key from a backup and get the system back up and running without significant issue.


With browsers that have certificate pinning, user-installed root CAs are normally exempted from pinning requirements; if the certificate received doesn't match the pinned certificate or key but is signed by a custom-added CA, the browser doesn't complain. This is done to support the exact scenario here, as well as the scenario where a user decides to MitM themselves (to, for instance, inspect all of their own network traffic). Source (the blogger in question, Adam Langley, works on the Chrome network stack and Google's HTTPS infrastructure).


The basic principle looks pretty good.

A few thoughts:

When a token is used, don't delete it. Mark it as used, store a "used" date, and delete old tokens after 6 months. Otherwise the same token serial number might be re-created by accident, because the system has no record of it ever existing.
Can any single instance of this prepay system run across multiple physical sites? If so, you're going to have to take synchronisation of data into account, otherwise a user might re-use their token on another machine.
If each vendor system needs to communicate to some kind of base station, they'll need a secure way of doing so. Physical security in the way of an ethernet cable is OK in small stores, but it pays to be secure - make sure you implement SSL for such traffic, with client and server certificates installed on the appropriate machines.
You'll probably want to tie each code to a specific vendor, whose ID is randomly generated. Otherwise a store assistant could print off a bunch of codes and go shopping at another vendor that uses your system. Make sure the ID generation uses a high quality random number generator!
Make sure appropriate security provisions are taken for the system that runs the database. Lock the machine down with group policy, enable and properly configure Windows Firewall, install an anti-malware package (Microsoft Security Essentials is good if you don't like the idea of running 3rd party solutions), etc.
Properly configure your database server software. This includes making sure that it only listens locally (don't bind to 0.0.0.0) or only uses local pipes if possible. You should also use strong credentials for the server, and minimal privileges. If at all feasible, reduce all queries down to stored procedures and only allow the account to access those procedures - give it no privilege on any table.
Make sure you implement an auditing system that logs the cashier that performed the transaction, the time, the order ID that it belonged to, the total price of the transaction at the time (product prices change!), the store ID, and the plaintext code that was used. You don't need to secure the code at this point - it's useless.
In the case of a refund where the customer is to be given back their token, generate a new token. Don't ever re-use the old token number.


GnuPG works by using two different kinds of keys: a private key and a public key. When you use the software, you create both a public and private key (called a keypair). You make your public key, well, public. Anyone can use it to encrypt arbitrary data, but that data can only be decrypted by using the corresponding private (aka secret) key. If it says there is no secret key, that means the file was not encrypted with your public key. In other words, it is not intended for you and you will not be able to decrypt it. You can only decrypt things that have been encrypted for you.

Is it possible that you want to verify the file instead of decrypt it? Since you mention a file with SHA-256 hashes, is this some sort of software you are downloading that came with a .sig file? If so, you need to import the public key with --import (you can usually find it on the download website for whatever you downloaded) and then use --verify instead of -d. See also:

Instructions for encrypting and decrypting
Instructions for signing and verifying


Anything particularly wrong with putting an auth code in marketing emails?

I have personal experience of a system that did pretty much this. I didn't develop it, I just had to handle the fall-out when the "instant login" went horribly wrong :)

The problem we encountered was that some users forwarded the emails to other people, not realising that the email effectively had a credential embedded in it. So when the person who got the email forwarded to them clicked the link, they were logged in as the original user.

You could argue that it is the fault of the original user, but to me, it's not at all obvious that clicking a link will automatically log you in as someone, so it's not reasonable to expect users to be particularly careful when forwarding.

Referring to the comment on @ideaman924's answer. I think users are more likely to recognise the risk of forwarding a password reset link to someone, than an opaque "instant login" link.

A better solution in my opinion would be to have a normal login page, but then have a session cookie that lasts a reasonable length of time, including after they close their browser or navigate away from your site. Then if they return within the cookie expiry time, either by clicking the email link or by any other route, they will be already logged in.


Am I a Hosting service provider in a sense of PCI-DSS SAQ D Appendix A?

Are we a shared hosting/service provider?

The PCI SSC defines what they mean by "shared hosting provider" under the PCI DSS requirement 2.6. The guidance section states:

  This [requirement] is intended for hosting providers that provide shared hosting environments for multiple clients on the same server. When all data is on the same server and under control of a single environment, often the settings on these shared servers are not manageable by individual clients. This allows clients to add insecure functions and scripts that impact the security of all other client environments; and thereby make it easy for a malicious individual to compromise one client's data and thereby gain access to all other clients' data. See Appendix A1 for details of requirements.

From your description, you probably are a shared hosting provider but its not clear whether multiple unrelated clients are accessing and storing data on a common set of servers, e.g. 12 clients accessing or running separate instances of your web application one a single web server.

This is exactly how my company operates and we are evaluated for PCI compliance as a shared hosting provider. We have multiple physical servers that run multiple virtual servers on each physical server. While some clients pay for ftp access, that is sand-boxed and will be replaced by a new mechanism within the year. Uploaded files are highly restricted by type, scanned by antivirus, and more. Databases are separate but on shared SQL server instances. In one component, a DB that is considered ours and not the clients' has client data mixed with other client data but essentially every record has a unique key, so only that component knows how decode that client's data for that client.

If this weren't allowed, even PayPal couldn't function because they would need a separate physical server for every merchant client.

The referenced Appendix A1 contains 4 specific sub-requirements, summarized:
A1 - Protect each entity's hosted environment and data, per A1.1 - A1.4
A1.1 - Ensure that each entity only runs processes that have access to that entity’s cardholder data environment.
A1.2 Restrict each entity’s access and privileges to its own cardholder data environment only.
A1.3 Ensure logging and audit trails are enabled and unique to each entity’s cardholder data environment and consistent with PCI DSS Requirement 10.
A1.4 Enable processes to provide for timely forensic investigation in the event of a compromise to any hosted merchant or service provider.

The latter 2 can be the toughest, depending on how your logging and forensic data are done.


Does Rehashing a weak hash with a strong algorithm make it strong?

Yes, hashing it again with bcrypt is a good idea. Do note, though, that it will not give your login code more entropy, it will just make it take longer time to crack. So if it is really low entropy to begin with you might need a very high cost factor to make it unfeasible to crack.

On a side note, in general it is better to just hash with one good hash function than playing around with many, as explained in answers to this question. But you don't have that option, so the arguments there are not really valid for your case.

As for using a pepper, I would recommend just encrypting the hashes instead. It gives the same kind of protection, but offers more flexibility. But it is no replacement for salting.

This and this might be interesting reading for you. Also, Roshan Bhumbra has an interesting suggestion about rehashing with just one function after the first login.


Can my email account be accessed without the password? How secure is it?

Typically, your email provider (Yahoo, for example) can read everything in your email without knowing your password.
And they will, as required by law and potentially in other circumstances, provide copies to Law Enforcement and Government.
It is also possible that an attacker could compromise Yahoo's servers and access your email that way.
And an attacker might be able to get hold of your password in various ways, in which case the attacker can gain access to your email.  Or, an attacker might be able to guess the answers to your security questions, which also is sufficient for the attacker to gain access to your email account.
Lastly, it's important to mention that emails are not just documents on your email server; they're also on the email server of the person who sent it to you, and maybe cached on your client, and maybe on their client, and backed up in various places, and they travel over the network. Lots of copies mean lots of places where an attacker can get hold of a copy. (Your question hints that you might just be storing documents in email without sending them, in which case this is less of an issue.)

Now, all this sounds very scary, but it's important in security to understand the level of risk and what your risk appetite is. Nothing is 100% secure - so you have to ask yourself:
 - How valuable is this data to me? What will it cost me if there is a breach?
 - What kind of attacker might try and get it? What resources and capabilities do they have?

If the data is not very valuable, and anyone who is likely to want it is not very capable, then you don't need a lot of security.

I'm not sure this is very practical, so here's some simple tips will help you improve the security of your stored email:

Choose a good password - not in a dictionary, not a name or a date, as long as possible, with a mixture of lowercase, upper case, symbols.
Don't use that same password anywhere else; don't write it down or tell anyone, and use something random that isn't connected to you.
Be careful about your answers to security questions, to make sure that no one will be able to guess them.  If it looks like someone might be able to guess one of the answers to one of your security questions, you could consider lying (pick a random answer that will be unguessable), and write it down somewhere in case you ever need it.
Consider encrypting the documents (with a different password to the one used for your email). There are lots of good tools for this: I like http://www.sophos.com/en-us/products/free-tools/sophos-free-encryption.aspx. Don't rely on built-in passwords in Word or WinZip, use a dedicated encryption tool.


Recommended length for WPA-2 password in 2020

For a slow hash like WPA2, that 2012 advice ("12 random ASCII chars is good enough") still holds, including the accompanying entropy/keyspace analysis. From the real-world attacker perspective, I can tell you that such plains, hashed with WPA2, are beyond reach in most realistic threat models, due to the sheer number of combinations.
For UX (ease of typing, ease of telling a visitor, etc.), you might consider using a passphrase of equivalent entropy (or more intuitively, number of possible combinations) instead.


How dangerous is it to use textmods from internet sources?

Without knowing about the precise game/mods involved, it's only really possible to discuss the risks in abstract.

From what you've said the application processes a file (textmod) which is downloaded from a 3rd party. So to process any data an application is going to need to open the file, read it, parse it, and then act on the instructions therein.

If there is a bug in the parsing code, for example, depending on the language the original program is coded in, you may get something like a buffer overflow or other undesired condition.

Assuming that this occurs, you then would look at impact which in the case of a game being run by the user, is likely to allow the malicious program to execute code with the privileges of the application (likely user-level).

In terms of mitigation, well at a basic level you could open the text mod files and see if they appear to be well formed and lacking obvious attack signatures (e.g. writing much larger quantities of data than might be otherwise expected in a field)

At a more advanced level it would be possible to write code to parse and validate the correctness of the file (assuming that there's a specification available) which could use to check textmods before loading them.


somebody can load their own operating system and see unencrypted files, right?

Yes. If you are not using encryption and an attacker gets access to your hardware, they get access to all your data.

  Should we store web application files when we are constantly developing in encrypted directory?

That really depends.

If this is a larger company, there should be a policy in place about this. Ask the relevant people about it.

If this is a small company and you are the one responsible for the decision, you need to weight the factors.

What is the cost of stolen source code? ie: How important is your source code? Is it open-source anyways? Is it something someone else could actually use? Or is it highly specialized software that is unlikely to be useful for anyone? Do you depend on the source being secret for security reasons (security through obscurity)? If the source is stolen, can you use other measures to punish the thief (legal avenues, etc)?
On the other hand, what is the cost of encryption? Have you measured the performance (my guess is that with decent laptops, it shouldn't be a problem)? How many hours would your developers loose if you used encryption?

After you weighted these factors, you should have an answer.

You could also try to find a middle ground. Eg have two laptops/computers. One encrypted which developers can take where ever they want, and one unecrypted that can only be in the office (ideally a desktop computer, so they are not accidentally removing it). This assumes that the source isn't so important that someone would break into the office (but if we assume that someone would to that, we could also assume that someone might tamper with an encrypted laptop to log the password).


I solved the problem by having the vendor send the public certificate as well as a digital signature along with the signed text.

The server would then verify the digital signature by using the certificate's public key.


Shamir's Secret Sharing Scheme - how standardised?

There is no really "standard" implementation, let alone output format, for such tools. Whatever you use, you'd better keep around its source code so that it may be recompiled or at least ported on the machine you will have twenty years from now.

I note that the code uses GMP, to make computations with big integers -- which means that it uses big integers, which implies that the code does not do things the easy and simple way. This is not, in all generality, a good sign. A good and practical implementation of Shamir's Secret Sharing should:

Use the sharing on a byte-by-byte basis.
Do computations in the finite field GF(256) (values fit in one byte, there is no bias or other similar issue, porting to any other language is easy).
Store shares in files, instead of strings to be typed and/or pasted.
Not be limited to 128 characters, which is sloppy. If you do the sharing on a byte-by-byte basis, you can split files or arbitrary length.


Authenticated encryption (Symmetric encryption) for .NET applications


How insecure is it to use the same private key for multiple x509 certificates?

Let's start by being clear on what they are doing: forcing you to compromise the security of your device so that they can man-in-the-middle all of your HTTPS traffic, decrypt it, read it, then forward it on to the real server (presumably re-encrypted using proper HTTPS to the server, but you have no guarantee).

So they are using the same keypair in all of their fake certs. Points for you that you noticed this red flag and got curious about it. Let's take a closer look: In a normal TLS certificate setup, you get one cert per server and use a unique keypair fr each server. The reason is that private keys are supposed to be private, but now there are multiple copies of this private key on multiple machines so that a compromise of Server A also compromises Server B. Bad. In this case, all the certs belong to the TLS proxy machine, so whether all the certs were using the same key or not, hacking into that machine would give you all the keys anyway.

And finally, back to the opening point: why would they need to worry about doing things securely when the whole point is to break the security of your BYODs wide open?


C1 and C2 are just terms from the Orange Book for levels of protection (where C2 has more security than C1). You can read the actual definitions online in the TCSE itself:

Here it is:

  Class (C1): Discretionary Security Protection

  The Trusted Computing Base (TCB) of a class (C1) system nominally
  satisfies the discretionary security requirements by providing separation of
  users and data. It incorporates some form of credible controls capable of
  enforcing access limitations on an individual basis, i.e., ostensibly suitable
  for allowing users to be able to protect project or private information
  and to keep other users from accidentally reading or destroying their data.
  The class (C1) environment is expected to be one of cooperating users
  processing data at the same level(s) of sensitivity.

  Class (C2): Controlled Access Protection

  Systems in this class enforce a more finely grained discretionary
  access control than (C1) systems, making users individually accountable for
  their actions through login procedures, auditing of security-relevant
  events, and resource isolation.

So C2 is a superset of C1, which does additional logging and finer grained access control (for example, there would not be a group login - logins would be individual).

Also, these terms (C1 and C2) are broader than just database security; they really refer to the security of an entire computing environment.


What are best practices for implementing Remote Desktop within a corporation?

Defense-in-depth, patching policy, audit lots, and the standard security spiel are a good starting point.  The risk isn't that there was a critical vulnerability as much as it is having mechanisms to prevent or detect unauthorized access.  There are vulnerabilities that are known and exploited well before a tracking code (MS, CVE, BugTraq) are assigned.

The Center for Internet Security publishes hardening checklists for various devices.  There are likely other organizations that publish similar checklists too.

You can easily disable RDP, but that may not necessarily increase your security posture (say if you're running a vulnerable/unpatched version of IIS with a publicly available exploit package).  Protecting against 0day is a bit tougher, but there are ways to detect intrusion and prevent data exfiltration.


How can attacker bypass this dom xss filter?


Incremental charset with no duplicate adjacent letter

Managed to get it working with crunch. This will be over 1 TB....

./crunch 8 8 -f charset.ls ualpha -d 1@ -o wordlist.txt

8 8 = Set the minimum and maximum length both to 8
-f charset.ls ualpha = Set a character set of uppercase alphabet
-d 1@ -  Will print all combinations with 1 or less adjacent uppercase duplicate.
-o = the output of the file.


Password strength of random words and brainflayer

I wrote brainflayer and gave a talk about it at DEFCON. Neither Thomas Baekdal's article nor XKCD's comic apply well to modern offline attacks. I read Thomas's article and his FAQ about it, and it may have been marginally reasonable when he wrote it, it no longer is. A key point is that password cracking attacks have gotten much better since then.

  Q: If I cannot write "this is fun" because of the spaces, can I not just write "thisisfun"?

  A: Absolutely not! The reason why "this is fun" is 10 times more secure, is simply because it is much longer (11 characters). By removing the spaces, you reduce the length and the complexity substantially. The spaces are effectively special characters, which in itself makes the password much more secure.

  Use "this-is-fun" instead.

Password crackers don't try long brute force attacks much - it's all about cracking ROI. A smart cracker will try word combinations with various delimiters, so using spaces, hyphens, underscores or nothing all ends up providing about the same security. Today's cracking methods use wordlists - which can include phrases - and large corpuses of previously compromised passwords along with popularity. This is combined with rule-based permutation and statistical models. Ars Technica posted a great article detailing modern techniques mid-2013, and attacks only get better.

I am also of the (possibly controversial) opinion that it is pointless to talk about guesses per second for offline attacks. A much better way of thinking about it is guesses per dollar. If you want to be pedantic you could add a one-time guesses per second per dollar cost, but the operational cost will tend to dominate. Brainflayer's upper bound on operational cost is 560M guesses per dollar, based on EC2 spot instance benchmarks - with zero one-time cost. It's possible to make these costs many orders of magnitude higher with a "harder" hash function like bcrypt, scrypt, PBKDF2 or, once it is finalized, Argon2.


bootp enabled by default on dhcp reduce security?

DHCP supersedes BOOTP; you keep BOOTP around only to help old hardware and software which does not know DHCP. Anyway, both are about offering a service to whoever asks (namely, IP address allocation and publication of network configuration) so they are no more, and no less, a security issue than what their definition entails: by running a DHCP or BOOTP server, you make it easy for people to plug in and get network connectivity.

Neither is more secure than the other, but if you offer both then you must mind both when it comes to controlling access to that service (e.g. MAC filtering). See this page for a comparison.

The usual security stance applies: if a service is not needed for operations, then don't enable it. To know if a service is needed for operations, disable it and see what breaks. In that case, deactivate BOOTP, and if you can live without it (which is probable), just leave it deactivated.


How source port field in firewall rule is used

One example where source port with TCP is necessary is active ftp. In this case the client (inside the firewall) listens on a kind of random port on the client for the data connection and notifies the server about this addr+port using the PORT command. The server then connects from port 20 - and this is the only restriction you can set if you need to allow active ftp.


Can a user verify the quality/safety of pregenerated SSH moduli parameters?

Thanks to @StackzOfZtuff for the linked articles.  Using those, this is what I've pieced together by now:

The generated parameters can probably be trusted as long as they are regenerated frequently.  For a higher security, one would have to check for reused parameters, which could be a sign that something fishy is going on.  It's still safer to generate parameters on ones own machine.

As the name suggests, safe primes work well when generating DH groups, as they guarantee a certain size of the resulting group.  So deliberately bad primes, resulting in reduced group sizes, are not a problem with the scheme described in the question.

The one possible attack I see is that the generating entity could chose specific groups and precompute as much as possible to solve the discrete logarithm problem using the natural field sieve.  This would make it a lot simpler for an attacker to break any DH using that group.  Naturally, the precomputation step is computationally expensive, so the attacker would want to reuse any broken group as much as possible.  This could be detected by keeping track of previous groups.

Instead of doing checks for recurring groups, just calculating one's own parameters is probably simpler.  Using DH parameters generated by others, without any nothing-up-my-sleeves guarantees, requires some trust in the entity providing those new groups, regardless of whether the underlying primes are safe or not.


How did DNSChanger rogue name servers work?

The DNSChanger trojan had all the sophistication right in the name: it would simply change the DNS server entries on the victims' computers to point to their own rogue DNS servers.

The rogue DNS servers were probably a regular BIND installation providing recursive lookups that was authoritative for zones they found interesting: other advertisers, anti-virus update sites, etc.


LSARPC is really a set of calls, transmitted with RPC, to a system called the "Local Security Authority". This used in the Microsoft/Windows world to perform management tasks on domain security policies from a remote machine. The protocol is described in MS-LSAD. The transport medium is RPC, a part of the "Server Message Block" protocol (MS-SMB, MS-SMB2).

So, while LSARPC is a protocol used to manage things that impact security, as a network protocol it is "merely" a sub-case of the Microsoft generic SMB protocol, whose security can be described as "questionable" (not irremediably doomed, but apparently hard to implement properly, since they got it wrong many times). On the bright side (or dark side, depending on your angle), LSARPC is no less secure than most of the network activities occurring within a Windows domain, since most of it uses SMB.


It might - it is promising.  A well designed app would either silently remove the ; or would return a proper "bad input" error message.  That it blew up (500) is a good sign.

It doesn't necessarily mean that is vulnerable, however - they could be returning 500s in case of bad input, for instance.  But it certainly suggests you may want to try some more.  Try putting an '19 or sleep(2) = 1' (no quotes) - if it takes 2 seconds longer to respond, you are in like Flynn.

NOTE : this should be on either a site you have been asked to test, one you control or a demo site designed for cracking.  Doing this on some else's site could result in charges.


What are some existing or ideas where the use of a password can be replaced to login to a service?

One option would be biometric authentication (e.g. fingerprint). This is a bad idea in a lot of cases. Primarily not because you finger might be damaged or someone uses it in some unsafe way but because if your secret (fingerprint) gets oublicly known: You will have the heck of a hard time changing it.

Another option would be temporary passwords. For example you enter your username and the service sends you a sms that you will be required to enter. Its like 2nd factor but as a first factor. It can also be a lot more elegant e.g. you will be requested by an app on you mobile device to tap a button and this simply authorizes your session in a web client on another machine.

A different option would be authentication via email. In this case a service generates an unique email adress (mail-auth-172adj289hf09ue2h9j8@yourdomain.com) that the user has to send a mail to using a special adress or containing a special string.

Basicly every 2nd factor could be used as a first factor. Like a hardware token that is plugged in or generates offline keys for you.


Your question seems to be a bit ambiguous to me because I fail to understand what you exactly want through it. Do you want the theoretical steps you must follow or the practical algorithms and libraries for your particular language that may help you do this?

If it's a general guide on how to make client-server architecture based software security, here's a good read:
http://www.eldos.com/security/articles/1942.php

As I understand it you want a method to automatically authenticate a license and add the specific computer's I.P. to your database of allowed IPs?

A good way to do this is use a simple SALT + Hashing algorithm wherein:

Each installation comes with a product ID.
This unique product ID has to be passed by your client to the server each time before use, wherein the server takes the product ID, checks if it is valid, then generates a access code (based on that day's unique salt dependent on say date and md5 of the salt+prodID).
This access ID is added to the access table and passed back to the client. In this manner everyday on the first run the client will be verified for it's validity.

Why this approach is good?
This approach leaves the method of validity to you. Ie. When you get the prodID, you can ensure multiple things such as:

Has any other computer tried to use this product ID today?
Is this prod ID first time used? In that case store the IP
If it's not used for the first time, is change of IP permitted? If so, how often?

Edited:

Alright, we'll change the above procedure a bit to get it to work. I'm presuming that you want to use it in sort of a licensing system.

Configure your payment system to generate a product or license ID for successful purchase. This ID can be anything, but remember to store it in your database.
When the client first runs the Joomla Extension, get the Joomla Extension to take the product ID from the user once, and store it locally. Then pass it to the server for registration.
At the server our products table will have two columns (pID,URL) If the product is having a null URL then we put our URL in the record where pID = Our pID
If not, and our URL is not the existing URL, then we have an unauthorized installation of an installation at a separate location then the original one. A separate method would have to be used to re-validate that.


Why there is time period of key pairs in public key cryptography?

The only intuitive answer (I got) is it reduces maintenance cost of CAs, since there will be loads of public keys it has to maintain. Otherwise, they can just scrap of keys whose time period is over.

No, that might be a reason but this is more due to several security reasons.

The first reason: better change your password every x months.

Lets consider a simple scheme. Imagine you use the same password on every website (which you should not be doing: would you use the same brush for your teeth and for your toilets ?).
You can assume that you can change your password anytime (same principle to revocation certificate). But you may forget to change your password on some website. If one of these is compromised, why not some other by domino effect ?
In order to avoid such problem, we generally have a policy that makes user change their password every x > 0 months. For your key pairs this is the same idea.

The second (and more important) reason: the increasing power of computers makes old keys insecure with time. This is due to the increasing power for factoring big numbers. A 1024 bit key may have been considered secure some years ago, but not anymore. Therefore to prevent people to use it, a life time is associated.


Windows: unknown program/service etc. sends HTTP request to download a file; how can I find the origin of that request?

I found the origin. Both Answers have given me the right indications to go on. With ProcessExplorer i picked the right svchost process (the same PID) and opened the TCP/IP tab, with wireshark i waited for the request, as it was sent, the TCP/IP tab from ProcessExplorer showed me the service wich was trying to establish a connection:
BITS Service (Background Intelligent Transfer Service). I opened cmd and with

BITSAdmin /List [/allusers] [/verbose]

i listed all jobs. And there we have the crux of the matter. All full with jobs from google-update. The files listed for each job pointed to a non-existing google-update.exe. So i think the first answers might is right, that this is not a virus. I don't know why there were 9 google-update jobs and nothing else. I deleted all. Since then the requests are gone.


The code for arbitrary curves is in the library; see the source code, file crypto/ec/ec_lcl.h, in particular function ec_GFp_simple_group_set_curve(). The OpenSSL code includes specialized function for some specific curves (in particular NIST curves) but also has functions for the general case.

Code for encoding and decoding arbitrary curve parameters in ASN.1 (e.g. for use with a public key in an X.509 certificate) also appears to be present (in crypto/ec/ec_asn1.c). However, I doubt this code gets much used, since most of the rest of the world supports only a few specific curves; so even if the code is there, it was probably not thoroughly tested.


Is this considered DOM-XSS or self-XSS or both?

I would call it a DOM-based (reflected aka non-persistent) XSS requiring user interaction.

It's not self-XSS, because self-XSS is just a way to call a specific type of attack where the user actually injects the code themself, typically by copying and pasting the malicious code directly into their browser JS console. Self-XSS is actually a social engineering attack, rather than a real XSS vulnerability. Apparently in the past self-XSS could also be achieved by tricking a victim into running malicious code in the address bar, like javascript:somethingMalicious(); but that's not possible anymore in some browsers (I just tested it in Chrome, it doesn't work). However links like  still work when you click on them.

The severity of your vulnerability depends on several factors, and you might want to consider CVSS to try to estimate it, although I'm not really a fan of those scoring systems. With CVSS version 3.1 and these parameters ( AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N ) you would get a score of 4.3, for example. Note that I don't know anything about the details of your vulnerability, and that I just supposed the attack complexity was low, user interaction was of course required, confidentiality impact was low, and no impact on integrity or availability. If you set the confidentiality impact to high, and attack complexity to high, you will get a score of 5.3, for example. Only you can know if those numbers are meaningful or not. Sometimes it can be very difficult to estimate the attack complexity and the impact of user interaction.


Can CAPTCHA-solving patterns be used to track/identify a person?

This is absolutely possible. Whether or not reCaptcha itself or any other given captcha service does this, I don't know, but biometrics based on mouse movements are absolutely able to uniquely identify people. The same is true for many other ways we interact with our computers (e.g. our keyboards).

There are a large number of research papers on various forms of biometrics. A few examples:

An Efficient User Verification System via Mouse Movements

  Our technique is robust across
  different operating platforms, and no specialized hardware is
  required. The efficacy of our approach is validated through
  a series of experiments. Our experimental results show that
  the proposed system can verify a user in an accurate and
  timely manner, and induced system overhead is minor.

On Using Mouse Movements as a Biometric

  Two authentication schemes are proposed, one for initial login of users and another for passively monitoring a computer for suspicious usage patterns. Error rates for both schemes were calculated and
  compared to prior work.

User Identity Verification via Mouse Dynamics

  The proposed algorithm outperforms current state-of-the-art methods by achieving higher verification accuracy while reducing the response time of the system.

You'll note that these papers are all about using biometrics for user authentication rather than for tracking. Both authentication and tracking are similar, as they both involve trying to determine which identity (if any) a given user is among a set of known identities. Whether or not this scales to the size of Google's user base, and whether or not it is accurate enough to track previously unknown users, I do not know. The point of this answer is to emphasize the capabilities of biometrics as a technology.


Is my personal data at risk with global digital giant's services?

IANAL, but in my opinion a service is only liable for what it manages. So they shall ensure that only authorized admins can access PII, and strictly forbid it.

On the other hand, the password is chosen by the users, and the password security is under their control. ANY ACCESS USING THE PASSWORD IS SUPPOSED TO BE A LEGITIMATE ONE. Full stop.

The various password policies should be seen as a way to educate corporate users to security practices, by their intrinsic efficacity is often debated, including on SE site. Search for password policy for more...


SHA-256 Timestamp not recognized in windows 7 when dual signed

Windows 7 doesn't support SHA256 signatures by default. You need to apply this update, in order to get the desired functionality.


Protecting information in TLS client certificates

It is possible:

Server and client negotiate SSL without client certificate requirement
Encrypted communications begin
Server sends Hello Request to ask for a renegotiation, this one encrypted
Client willing, another handshake ensues
Server sends a Certificate Request to trigger client certificate authentication
(Encrypted) handshake continues normally, and client certificate is protected by TLS.

I don't know how easily you can convince existing server implementations to do it, but the protocol allows it.  I seem to remember that there are other existing reasons and implementations that trigger a renegotiation immediately after the first (unencrypted) handshake finishes.

Updated to reflect @dave_thompson_085's correction, see also his comment regarding TLS 1.3.


HTTP HEAD and its security versus operational uses

HEAD is not dangerous in itself, and it does have legitimate uses. The problem is with Java EE. It has a way to set security constraints  using web.xml files - but  those are only applied to GET and POST, not to HEAD. This means that it is can be possible to bypass authentication using HEAD. There is more information about this and other issues in this paper on penetration testing by the SANS Institute.

Whether this particular issue is applicable to your application will obviously depend on what application server and other security measures you are using.


Can I assume that the Windows profile directory is not writable by other users?

Yes, %UserProfile% is a secure directory in such a way, that it's protected from being read or altered by other users in the default configuration.

It is not a secure directory, in such a way that any system administrator including backup operators, holder of various privileges (SeTakeOwnershipPrivilege, SeTcbPrivilege, ...), anyone who can access the files offline, etc. can read, and in most cases, alter the files.


Single vs multiple personas? What are the security implications?

As a systems admin & developer

I use different personas in Production and QA.. so that a script in QA doesn't go awry and inadvertently do bad things to production systems.

As a systems admin and a user

I use different personas for my day to day email activities, so that if my email account were to get virus-filled spam, or if I were to surf the web and hit with a zero day, the maximum harm that virus could do is affect things my user account has access to.

As an employee and personal user

If I were to do work-related business over a personal email account, then any legal issue my office runs into may allow them to sopena the emails in my personal account.  Depending on what I say in that personal account that may be undesirable.   This is especially important for FINRA-covered registered reps (for example) as any financial advice they offer or claim they make, it must be monitored by a 3rd party (such as Smarsh, or internal compliance review).

Disclaimer / IANAL

I focuses primarily on email in the above areas since that is where I work in day to day activities, but I'm also not a lawyer and don't know the local country/region laws that affect you.  The stewardship that each user must maintain for separate accounts (or identities) may be ultimately defined as the amount of legal risk that the individual or company wants to take on.

Finally, the more accounts that your users use to do business in, and if that business has its records subpoenaed, then the legal costs have just increased unnecessarily.  From a cost savings perspective alone (risk mitigation) then separate accounts may be warranted.

On the flip side, I have seen people use many accounts and not worry about this because it would cause undue burden on the business.  I'm not sure if this argument holds water, but it has been done.  I just hope those people never get sued.

Summary

Is it worth it to have many different personas?  I'd say it depends on why you're doing it.  Loss of data, service availability, and permission elevation would be one of many reasons to do it.

The general user should

Use different personas (usernames and passwords) for banking vs forums and email
Create a generic account that, if hacked, nothing important is lost.
Limit exposure with the generic account by setting up multi factor authentication (lots of good links there)
Create additional generic account as the risk exposure dictates


Are these precautions sufficient for scam baiting?

Most of the time, scammers aren't technical people, and they won't look for your IP address in mail headers (since they sometimes leave theirs). Find a mail provider that doesn't forward it, just to be on the safe side.

This extremely entertaining resource, 419eater.com, should give you the basics. As far as safety is concerned, it boils down to not giving out personal information.

I wouldn't go as far as using Tor for this, but it can't hurt anyway.


iOS, Android, and OS X SHA-2 support (in the context of SSL/TLS certificates)

In SSL there are two areas where SHA-1 or SHA-256 may be used:

in the specific entrails of the protocol itself, for the internal "PRF" (a function used during the handshake) and for protecting the integrity of subsequent data exchanges;
as part of the signature over the server's certificate, and its CA certificate, and so on.

SSL 3.0, TLS 1.0 and TLS 1.1 use MD5 and SHA-1, not SHA-256. If you want to phase out SHA-1, then you need to switch to TLS 1.2. From this answer and its comments, you can see that support of TLS 1.2 by browsers is not a given, and is slow to percolate throughout the industry. IE on Windows XP will certainly not support TLS 1.2. In particular, many Android-based devices will use old versions of Android and its browser, and won't be updated soon. Fortunately, you can configure your server to advertise TLS 1.2 support but fall back to previous versions if the client does not support it; this is the normal behaviour of a SSL handshake, and should ensure a smooth transition.

What XP+SP3 supports about SHA-256 is the second point: certificates signed with SHA-256 as underlying hash function. This works. This page from digicert (a commercial CA) argues for SHA-256 support, and by that it means SHA-256 support in certificates; when it claims "browser support" it talks about the certificate validation, not TLS 1.2. According to that page, SHA-256 in certificates seems to work "everywhere". They don't tell anything about Android, but chances that Android is up to SHA-256 support because it has supported SHA-256 internally since day one (it is based on Java, which has known SHA-256 for years).

To sum up: you can use SHA-256 for the certificates; it will work (almost) everywhere. You cannot require TLS 1.2 yet (too many client browsers out there cannot handle it) but you can support it, and decide to prohibit previous versions (those which use SHA-1 internally) at a later date.


Questions to hybrid encryption. RSA with AES

The IV is simply to prevent differential analysis between two different messages.  It is perfectly fine to be public and in fact needs to be accessible for decryption.

Encrypting for a user with their public key makes no statement about authentication.  It isn't a signature, so deniability is irrelevant.  There is no signature to attest to the original owner.

There are weaknesses in using the wrong padding for some algorithms.  I don't know if there are any that are particularly weak when you are using a more or less random value for your data, but why risk it?

I'm not familiar with the particular library, but according to the the comments I received, SignHash signs a precomputed hash where as SignData computes the hash and does the signature.  SignData would likely be better, but I'm not particularly familiar with that exact library, so this answer may be incorrect.  Note that signing would make it undeniable as it proves the original ownership.  If you don't want to prove original ownership, then signing is unnecessary and counterproductive as an attacker could also sign it and there would be no way to tell if it was genuine or not.

It seems like a pretty run of the mill asymmetric encryption of a symmetric data key.  It would be helpful to include the public keys paired with the encrypted AES keys.  This will help people lookup the correct key on the keyring to use for decryption.  Otherwise they would have to try them all to find the one that their private key unlocks.  Don't bother encrypting the IVs either, it's duplicate data and doesn't have to be secure. If a signature is necessary, don't store a collection of signatures, sign the main encrypted payload once for everyone.  Signing the keyring is unnecessary as a changed key won't decrypt the payload.

The approach seems reasonable and inline with standard approaches for dealing with it.  It's probably not the most solid implementation around, but I also don't see any super glaring issues.  You might want to consider looking for an existing library that handles the same thing though since you aren't doing anything unique.  (Though it isn't really a role your own issue since you are using established algorithms.)


Probably it is a DOS attack.

Check the log carefully and verify the source IP of the request.

If it is a DOS attack,

the source IP's may look like
either

xxx.xxx.xxx.000
 For all entries
 Or

May be a group

xxx.xxx.xxx.000
xxx.xxx.xxx.001
xxx.xxx.xxx.002

Likewise

If you see random IP address repeatedly, it may be a DDOS attack.

Don't worry the Firewall will take care of it.

If it can't, either down the server by yourself or use a 302 temporary redirect

UPDATE

  The firewall is efficiently preventing it. If you want it not to come, Just add a 302 for 1 or 2 hours to google.com or something and then remove it.


Many P2P software will create hashes of each piece to prevent a malicious entity from modifying the pieces in-flight. When your P2P client gets a piece, it verifies it's hash. This will prevent one malicious entity modifying a piece of a valid file, but it won't help you if the file itself (qwerty.mp3) is malicious.

If the file itself is malicious, a simple solution is to just run an anti-virus scan against the final file, and see if there are any problems. This will satisfy your signature/anomaly based detection (depending on what the Anti-virus does)


Getting Certificate KeyContainerName to initialize CspParameters

Is this what you're looking for? (sorry for messy code, I'm a Java guy thrown into VC++ code)

    HCRYPTPROV hProv = NULL;
    DWORD status;

    if (FALSE == CryptAcquireContext(
        &hProv,
        NULL,
        MS_SCARD_PROV,
        PROV_RSA_FULL,
        CRYPT_MACHINE_KEYSET | CRYPT_SILENT)
    ){
        status = GetLastError();
    } else {
        PBYTE pbData = (PBYTE)Alloc(256);  // formally, you should check the max size
        DWORD tmp = 256;
        PDWORD pdwDataLen = &tmp;
        status = 0;
        bool is_first = TRUE;
        // PP_ENUMCONTAINERS does an enumeration over all containers available to the MS_SCARD_PROV crypto provider
        // (which should be just all containers on the smartcard in case of single smartcard and single reader)
        while (status == 0) {
            if (FALSE == CryptGetProvParam(hProv, PP_ENUMCONTAINERS, pbData, pdwDataLen, (is_first ? CRYPT_FIRST : CRYPT_NEXT)))
            {
                status = GetLastError();
                //__leave;
            }

            OutputDebugStringA((LPSTR)pbData); // or std::cout in a console application
            OutputDebugStringA("\n");
            is_first = FALSE;
        }
    }


Is there any benefit to using a salt when the cleartext is random data?

Assuming the encryption keys will never be duplicated across multiple users - which I should hope won't happen - then salting is not required for your specific attack scenario.

With that said, the scenario you describe has the users sending the decryption key to the server with every request they make. If the data must be stored server-side and you only care about it being encrypted at rest, that works - somebody who does something like steal a backup of all the session data won't be able to decrypt it - but it's fragile. An attacker who gets access to the running server or to a user's network traffic would be able to steal the decryption keys and use them. I don't know enough about your use case to design a system that would definitely work better, but it's worth considering whether it's acceptable to you that your user's data is trivially decryptable as far as the server process is concerned.


Are phone apps vulnerable to XSS or CSRF? (Webview, Phonegap, chrometab)

A CSRF attack can only happen when cookies (or other authentication mechanisms) are provided by the client automatically. That is, where the client has access to cookies from multiple domains (such as a web browser storing cookies for each site you visit).

However, a mobile app containing a web viewer will typically only have the cookies for its own system. The cookies will not be shared with other applications using the same web viewer control. Anything loaded from the filing system will also be isolated from each other: Android and iOS  have security controls so that apps can't read other app's data. Therefore CSRF is not likely within a mobile application.

XSS could still be an issue though as anything rendered in a web page displayed by an app where JavaScript is enabled could cause JavaScript code execution if such a flaw exists, just like within a web browser.


Reason to Require A VPN Client for Exchange 2010 and Newer?

Quite simply: they don't want their email server exposed to the Internet. By placing it behind their perimeter, they reduce the threat exposure.

Encryption protects the content of communication, but not the communicators themselves.


Locale detection & huge Accept-Language header, can this be considered an atack vulnerability?

If this can be considered an attack, how can one protect his website from such forged headers?

Forging requests that take a long time to process on the server is a common technique for a Denial-Of-Service (DOS) attack. This is why you always sanitise your input. Not just POST and GET values, but also the headers if you use them.

For the HTTP_ACCEPT_LANGUAGE header, I'd say anything more than about 30 characters or 10 languages would not be a sane value for most applications. So sanitse the header. You can either limit the number of results in preg_split or limit the length of the HTTP_ACCEPT_LANGUAGE header

$userLangs = preg_split('/,|;/', $_SERVER["HTTP_ACCEPT_LANGUAGE"], 10);

or

$userLangs = preg_split('/,|;/', substr($_SERVER["HTTP_ACCEPT_LANGUAGE"], 0, 30))

edit: The answer by user 'Your common sense' was accepted, but please realise that optimising a loop is not the right way to protect yourself from any forged input. You're just reducing the impact, instead of solving the source of the problem.


When to use private keys and when to avoid in SSL?

...  Because the private key needs to be there to encrypt messages for SSL.

The private key is needed whenever a party needs to authenticate itself using a certificate. This includes web servers but might also include clients in case of client certificates. The key is not used to encrypt the messages but is used to proof ownership of the certificate using a digital signatures. This proof of ownership is essential to protect against man in the middle attacks. The private key might also be used in the key exchange, but only in the RSA key exchange. The result of the key exchange are shared symmetric keys. Only these get used to encrypt the messages and not the private key.

  Verification is done either by trusted authorities, trusted intermediaries based on certain modes of operation: verify-full (verifies both intermediates & roots), verify-ca (just roots). But you still need private keys for every server unless you are doing one-way SSL right?

I'm not sure what you mean with verify-full and verify-ca. The verification if a certificate is issued by a trusted CA is done by building a trust chain from the leaf certificate (i.e. server certificate in case of a web server) to a locally trusted root CA. This trust chain is build and verified using the issuer information and signature on the certificate. The chain might involve multiple intermediate certificates from the leaf certificate up to the locally trusted root. These intermediate certificate might be send by the peer or might be known locally already, but the end of the trust chain (root CA) must always be locally trusted already.

See SSL Certificate framework 101: How does the browser actually verify the validity of a given server certificate? for a nice description on how the chain gets build and verified.

  What is a chain "bundle"?  ...

The chain bundle contains all the intermediate certificates which the server should send additionally to the leaf certificate. These are the intermediate certificates which are needed by the client to build the chain from the leaf certificate to the locally trusted root CA certificate.


How powerful are top Verisign executives?

Big CA are supposed to implement thorough controls to prevent or at least detect wrongly issued certificates. Procedures applied by Verisign are described in their certification practice statement. See in particular their "procedural controls" and "personnel controls", pages 28 to 31 (as of version 3.8.4 of the document, published March 1st, 2011): some tasks require collaboration of several employees who check each other, there are background verification (criminal status, debt...), a lot of logs are produced and audited... To a large extent, these procedures are quite similar to the procedures for launching a nuclear attack, and, frankly, I think that a few hundred nuclear warheads are just a tad more worrisome than a couple fake certificates.


Is there a threshold for a password so long it doesn't get any more secure or even becomes insecure?

128 bits (of entropy)

The main purpose of a longer password is to prevent brute force attacks. It is generally accepted that 128 bits is beyond anyone's capability to brute force, and will remain so for the foreseeable future. You see this figure in a few places, e.g. SSL ciphers with 128-bit or greater key length are considered "high security" and OWASP recommends that session tokens be at least 128-bit. The reasoning is the same for all these - 128 bits prevents brute force attacks.

In practice, if a password is made of upper and lower-case letters, numbers, and a little punctuation, there is approximately 6 bits of entropy in each character, so a 128-bit password consists of 22 characters.

A password can be compromised in ways other than brute force. Perhaps there is a keylogger on the client system, or the user gets phished. Password length makes almost no difference to these attacks - even a 1000-bit password would be captured just the same. And these attacks are common in practice, so it really isn't worth using passwords that are too long.

In fact, you can get away with a bit less than 128 bits. If the password is hashed with a slow hash function like bcrypt, that makes a brute force attack harder, so 100-bits (or thereabouts) completely prevents brute force attacks. If you're only concerned with online attacks, and the site has a lockout policy, then you can get away with less still - 64-bits would completely prevent a rate limited online brute force attack.


what does `client_id` mean in password credentials grant of OAuth 2.0?

In short:
client_id and client_secret are used for to authenticate the APP.
username and password are used for to authenticate the user.

It also means double layer protection.

The specification  says:

  the client MUST authenticate with the authorization server as described in Section 3.2.1.

A client authentication is done by using a client_id and a client_secret value.

Actually the latest paragraph of the section 3.2.1 says

  A public client that was not issued a client password MAY use the client_id request parameter to identify itself when sending requests to the token endpoint (e.g. for the purpose of providing end-user context, client usage statistics).

However, it just may.
But Google gives a client_id and a client_secret on the developer console when trying to use an API.

If you want to use Resource Owner Password Credentials for an API or a Web authorization you might provide a register page to your clients to register themselves. (I recommend using of Client Credentials flow for API)

If you want to use Resource Owner Password Credentials for a mobile app you might give a standart client_id like AwesomeAPP and a client_secret like Bl**123_Blabla.

Or you may use  AwesomeAPP_v1.0  as client_id to track that how many people use which version of the App although it's not the best way. But you may.

Hope this helps...


Online SQL Server database for a Business app. Security considerations

Exposing a security sensitive server on the internet is never a good idea. It does not really have any advantages but only disadvantages.

Since it has a public IP, everyone can scan your machine for old software. Exploit 0day vulnerabilities, (d)dos it, etc etc.

The best way to go here is to create a VPN or a VLAN such that all services are only accesible from within the VPN/VLAN. All your business apps can than access the database as long as their part of the VPN/VLAN.

Of course the downside is that you have to implement a vpn/vlan which I assume you dont have given the question. But from a security point of view it is the way to go.


How to prevent a client-side encrypted app from being abused as general storage?

If you're allowing to store objects on your server and need to limit the amount of storage per user, you should introduce a per user quota and either deny new uploads or delete older ones. Other things won't work reliably if your encryption is good enough and the users want to misuse your resources.

Without knowing your concrete use case it is hard to give any other advise.

You may want to add to your question why you do not want to limit the number of objects.
Obviously you do want to limit them, but are trying to avoid count the objects / storage space used by the objects but limit them by reducing the rate they can be created.


DROWN does not mean that your servers share the same private key (you would have to copy and paste the keys from one server to the other, more work than just generating a new one)
DROWN is about using weak ciphers like SSLv2 export ciphers where known attacks can lead to a decryption on traffic.
I would suggest you read that:

https://blog.cryptographyengineering.com/2016/03/01/attack-of-week-drown/
and that https://drownattack.com/
and maybe their paper: https://drownattack.com/drown-attack-paper.pdf

How can you proof it? Have a look at the TLS configuration of your vulnerable servers - you will see that legacy ciphers are in use in your config (if not, maybe it's a false positive).


The property you're referring to is usually called integrity.  In general, TLS uses one of two approaches for this.
The first approach, which is new in TLS 1.2, is called an AEAD (authenticated encryption with associated data) cipher.  This type of cipher both encrypts the data and generates an authentication tag that the remote side can used to verify the integrity of the data.  In TLS, the most common ciphers that are used this way are AES-GCM and ChaCha20-Poly1305, with AES-CCM used less frequently.
The older approach is to use HMAC in conjunction with an independent cipher.  As part of the generation of session keys, an additional set of MAC keys is generated to be used with HMAC.  TLS authenticates the plaintext and then encrypts the plaintext and MAC, instead of encrypting the data and then authenticating the ciphertext.  The former approach means that a variety of timing attacks on padding and MAC verification can be exploited if the implementer is not exceptionally careful.  The latter approach, called Encrypt-then-MAC, is preferred in the cryptographic community because it avoids those problems, but is not commonly used in TLS for historical reasons.  TLS 1.3 no longer permits this mechanism because of the potential for timing attacks.
In all cases, the data authenticated is similar, and includes the sequence number (and in DTLS, the epoch), headers, and data.  Authenticating this additional data, including the sequence number, prevents an attacker from replaying packets and is a best practice for cryptographic protocols.


Is CVE-2013-2566 a practical attack against RC4 or still conceptual?

As Matthew Green puts it, the attack "is just on the edge of feasibility". It conceptually applies to any protocol that uses RC4, although some are more vulnerable than others.

The weakness of RC4 is a bias in the first bytes of output. From the key, RC4 generates a long stream of pseudorandom bytes, and encryption is just a byte-per-byte XOR of the data to encrypt with that stream. Thus, when the same data is encrypted multiple times (with a distinct key each time), the bias in RC4 output translates to a recovery of the secret data. For instance, suppose that the 17th byte of output has value 0x42 more often than the 255 other possible byte values (a fictional illustrative number). As the same message is repeatedly encrypted, its 17th byte (let's call it x) will be XORed with the 17th byte of RC4 output. The attacker, observing all the encrypted messages, may notice that the 17th byte of output is, say, more often 0x7C than any other value. The attacker will then infer that the observed value 0x7C corresponds to cases where the 17th byte of RC4 output is 0x42. He will then conclude that x XOR 0x42 = 0x7C, i.e. that x = 0x3E. The attacker just recovered one byte of plaintext.

The important point is that only the first bytes of RC4 output have biases which can be exploited in a "reasonable" time. The biases are still slight; it takes millions of observed encryptions, all with the same secret data, to reliably observe such biases.

In a Web setup (with HTTPS), the attack would look like this:

The victim's browser knows a cookie that unlocks a session on some site (let's call it www.example.com. The attacker wants that cookie.
The attacker controls the victim's network context. Realistically, the attacker runs a WiFi access point in a public place, and the victim connected to it, believing that AP to be provided by the restaurant or library he has decided to spend a few hours.
The attacker injects some hostile Javascript in the answer to an HTTP (not HTTPS) request from the browser to some site (not www.example.com). That Javascript will repeatedly trigger an HTTP GET call to https://www.example.com, e.g. by creating a hidden <img> tag in the Web page.
Each call triggered by the evil Javascript implies an SSL/TLS connection, with the cookie in it, at a predictable place. The attacker furthermore injects in the connection a RST packet just after the call, to force a connection close and thus a new connection with a new handshake and a new RC4 key each time.

Realistically, the attacker cannot really hope for more than, say, ten connections per second or so, so a million call will take more than a full day and night. Also, all these connections hit the target site (www.example.com), which may raise some alerts. If the attacker can pursue the attack at full speed for 30 hours or so, then he will be able to guess one or a few cookie bytes (the bytes which appear in the stream at a position where the RC4 biases are most important).

The conclusion is that the attack is, indeed, on the edge of feasibility: it can be demonstrated in lab conditions, but has not been spotted in the wild. Yet.

For WPA/TKIP, the same principles can be applied, but is more practical because in that protocol, each individual packet has its own RC4 stream, started anew with a packet-specific key. Collecting one million packets is sure easier than observing one million TCP connections with a TLS handshake. However, the weakness is in no way restricted to that single protocol; it is consubstantial to RC4 and will follow it into any protocol that uses RC4.

It may be noted that when SSH uses RC4, it usually does it under the name "arcfour128" or "arcfour256"; in both cases, this is RC4, but with the first 1536 bytes of output dropped. These are bytes with the biggest biases. Thus, these RC4 variants are quite stronger than the plain RC4 (known as "arcfour" in SSH terminology).

For new protocol designs, don't use RC4. If you really need to go beyond some "normal" AES/GCM, consider the stream ciphers from the eSTREAM portfolio: they are both safer and faster than RC4. But remember that protocol design is hard.


SELinux uses auditd for logging purposes, but auditd is independent from it. You can use auditd without SELinux present.


Is it ill-advised to use the same password for lock screen and full disk encryption (Windows 10 BitLocker)?

If you're the only user of the system and your password is string, then yes, there's minimal risk to using the same password.

Two caveats.

Even without FDE, your system encrypts certain data using your lockscreen password, for example DPAPI, which is used by some password managers like the one built into Chrome.

Also, consider that FDE password is something that you only need to type once for every boot, while the lockscreen password, you need to type everytime you lock your screen, which if you have good clean desk hygiene, you should be locking your screen everytime you leave your desk, so you'll likely be locking the screen dozens of times per day as you go for lunch, to the toilet, quick break, etc. Depending on how paranoid you are about your security,  you have the opportunity to use a stronger password for the FDE password and to use an easier to type password for your lockscreen. If you use the same password for both, you'll have to find a compromise by finding one password that satisfies both requirements.


The problem is the transactions with bitcoins are publicly logged so anyone can see the bitcoin transaction.

There is a page from bitcoin wiki on how to keep your bitcoin anonymous titled Bitcoin Wiki - Anonymity. There is a section "Staying Anonymous", that will explain you how to transfer the coins between many accounts from different  eWallet providers.

So to your first question

  Would I be "somewhat anonymous" if I purchased bitcoin using my real bank account, used that bitcoin to purchase a VPN-service that I can trust does not keep any logs, and use that VPN-service through TOR?

Its no, first of all buy the bitcoin with cash and in small quotes and you still need to transfer your coins through several wallets - instead of tor use tails , its a whole amnesic and anonymity distro instead of just a anonymity browser. Use proxychains and a vpn as well to create the ewallets and transactions.


Safe alternative for the `x-forwarded-proto` header?

X-Forwarded-* headers are used by proxy strategies (WAF/Load Balancer/DLP HTTP Gw/etc.) and yes anyone can send any header without custom development, have a look following command (bash).

Example custom header command: curl http://test.com -H 'X-Forwarded-For: 6.6.6.6'

This why Heroku does not accept X-Forwarded-* headers from WAN, this is the case. You can not send X-Forwarded-* headers with JS but Heroku will proxy your request and give you X-Forwarded headers (to your backend).

You can verify my answer at https://help.heroku.com/J2R1S4T8/can-heroku-force-an-application-to-use-ssl-tls.

  Under the hood, Heroku router (over)writes the X-Forwarded-Proto and
  the X-Forwarded-Port request headers. The app checks X-Forwarded-Proto
  and responds with a redirect response when it is not https but http.


How to avoid log4j output external modification

You could use the SyslogAppender

This sends all logs to syslogd (which can be on a separate server). You could configure the log files to be non-accessible by the application user, while syslog takes care of rotation.


Could a dynamic security system prevent DDoS attacks?

It really depends on the type of attack that your target is dealing with, however the solution you presented while very creative, doesn't solve the problem unless you have an unskilled attacker who only uses application attacks

Types of Attacks (and how to stop them):

A volumetric attack sends a large amount of raw traffic to saturate the network's uplink taking the entire server offline.

Solutions to block volumetric attacks are pretty much limited to Cloud "scrubbing centers" which utilize advanced rulesets to choose which traffic to forward to a server and which to discard, these "scrubbing centers" are only possible because they have an insane amount of hardware and available bandwidth topping multiple Tbps of capacity.

An application attack sends a small amount of specialized traffic to target the running application, for example you could send let's say 10,000 HTTP requests per second to a web server to crash it making the website unavailable.

Solutions to block application attacks have a larger variety, realistically rate limit the functions in your application, if a single IP is hitting the limit too often, automatically issue a firewall rule to block further requests to the application.

A few things to consider

2-factor cannot mitigate DDoS Attacks, it's a nice security tool, but it's not very effective in blocking DDoS Attacks.
The main drawback would be constant disconnects and reconnects ruining the fun of your game server. Sure you could keep changing the port to prevent an application attack, but you would go down and stay down the moment your attacker switched to a volumetric attack.

A more practical solution

I would switch to a server provider who offers to filter very large attacks. Some providers include Voxality, OVH, and DDoS-Guard.net (they protect datacenters, you normally wouldn't buy from them directly, Blazingfast uses them for added filtering). From there you only have to deal with application attacks if not filtered by the provider. It's going to save you a lot of headache, the gamer community will only be targeted more and more by DDoS Attacks, you should be prepared to be under constant attack.


Why does a VPN prevent snooping when https already encrypts the traffic?

HTTPS encrypts the content but:

Anyone watching the stream, including your ISP, can easily see that you are going to www.bluebuggybumpers.com, or my.aids.results.com, or what have you. A VPN blinds your local ISP to where you go, although the VPN is capable of the same monitoring.

The site you visit directly see's your IP address and can generally instantly know within a sub-city locale where you are located. With additional assistance from your ISP, they can locate your specific internet connection. A VPN presents the VPN's IP address instead of yours.

Your geographic locale, determined from your IP address, may result in restrictions along the lines of Dr. Who is UK Only, or blocking North Korea. A VPN can be used to appear from almost anywhere in the world.

Some ISP's block certain protocols like bittorrent. A VPN allows you to run blocked protocols.


What authentication system (OpenID, Facebook, etc) permits Javascript-free and/or Cookie-Free operation?

ASP.NET out of the box can handle cookieless session handling.  As such, any mechanism that uses ASP.NET sessions can work cookie-less.  The Windows Identity Foundation coupled with ADFS v2 will work cookieless, but every time you return back to the STS, you will need to reauthenticate so you don't get SSO.

WIF will work with MVC.

I cannot speak to any other platforms as my specialty is WIF/ADFS.

EDIT: JavaScript is not required for either.  Also, WIF will handle SAML tokens, but doesn't handle the protocol itself.  V1 only supports WS-Auth/Fed.


Minimum credential for WMI parameters Monitoring?

WMI sits on top of DCOM which sits on top of RPC.  So you'll have to expose the Windows RPC ports, which is a non-starter if you're trying to monitor servers across the Internet -- nobody should expose those.

But assuming you're monitoring across a LAN, then you'll need whatever DCOM rights are necessary on that machine, and then enable WMI for remote queries (which I think can be any account).  As far as I know though, remote WMI queries are disabled by default, so your users will have to get their hands dirty.  There is a little FAQ about that here:
http://www.poweradmin.com/help/enableWMI.aspx


How to remove meta and sensitive data from PDF file?

You can transform the PDF into uncompressed form using pdftk. Most metadata will then be immediately visible (and removable, provided you repair the file with pdftk afterwards). Same goes for "non-immediately-PDF" code (you can see that with tools such as PDFid). You can for example easily alter the trailer where fields such as /ID are to be found:

/Info 104 0 R
/ID [<81b14aafa313db63dbd6f981e49f94> <81b14aafa313db63dbd6f981e49f94>]

(in the case of ID, just replace with a sequence of random hex of the same length. No repair necessary. pdftk compress command is advised to save disk space).

It much depends on what kind of redaction you're trying to achieve. "Semi-inadvertent" metadata such as the ID (above) can be easily removed either directly or by re-saving the PDF removing unused objects and previous revisions of extant objects, which could contain sensitive information either intentionally or unintentionally:

  7.5.6       Incremental Updates

  The contents of a PDF file can be updated incrementally without rewriting
     the entire file. When updating a PDF file incrementally, changes shall be appended
      to the end of the file, leaving its original contents intact

Some filters may contain garbage without this compromising PDF legibility (for example the DCTDecode filter used to store a JPEG entity within the document. The filter supplies its own data size field internally; so what happens is that the "outer" PDF reader gathers the DCTDecode-encoded object and passes it to the filter, which gives back a raster image. The original object might contain extra bytes that the filter will ignore and discard, and which may be meaningless, or may contain pieces of random memory from the encoding computer (and possibly sensitive information), or may contain the same intentionally. Actually, being a JPEG, a DCTDecode object could contain EXIF information and this might be sensitive (e.g. GPS positioning and the like).

For example if I take an image containing a copyright

$ exiftool istockphoto_2425717-getting-a-call.jpg | grep Copyright
Profile Copyright               : Copyright (c) 1998 Hewlett-Packard Company

and convert it to PDF

$ convert istockphoto_2425717-getting-a-call.jpg test.jpg

...the original string is still there:

$ strings test.pdf | grep Copyright
Copyright (c) 1998 Hewlett-Packard Company

To remove it, I would need to extract the JPEG(s), remove the EXIF and other data tags from them, and then re-embed them back. It could conceivably be done using e.g. iText, or a state machine identifying the streams

...
/Filter [/DCTDecode]
/Width 364
/Height 380
/BitsPerComponent 8
/Length 20514
/ColorSpace 8 0 R
>>
stream
ÿØÿà^@^PJFIF<this is the JPEG file...>
...
endstream
endobj
...

saving the stream object as a JPEG, manipulating it, and writing it back. Now the stream length needs to be corrected, and the index offsets will be changed, yielding a broken PDF; pdftk can reconstruct the index from this broken PDF generating a clean one.

Yet other kinds of metadata, designed for stealth, may not be so easy to detect, much less remove. The possibilities there are endless. Some of the sneakier:

PDF has an internal index, so the actual ordering of most object entities inside the file does not matter. Find a metric - lexicographic could do - to define a "natural" order of those objects. If you have N objects, you have N! possible shuffles of those objects, and can then encode log2(N!) bits of information in the way they are ordered. Remove with: a tool capable of reordering the objects in the PDF file.
Fonts can map arbitrary symbols to glyphs and glyphs are ordered within a font. Again you can choose the mapping so it carries information. Remove with: most PDF "font optimizers".
Several objects allow positioning at much higher precision than actually needed for typesetting. Assuming there's no typesetting difference between the coordinate values 3.1415 and 3.1416, a character positioned at 3.1415064 could "encode" the ASCII code 64. Remove with: some tool (iText) capable of extracting and processing every entity in the PDF and align it to a grid with arbitrary precision (here 0.0002), thereby rounding 3.1415... to 3.1416.

A not always optimal, but working, way of doing all the above is to regenerate the PDF from scratch by e.g. printing it to another PDF device after typesetting it in a different format. A radicalization of this approach is to typeset the PDF onto a raster canvas and generate a PDF out of that. The resulting PDF will be far bulkier since it now basically consists of a series of TIFF or JPEG images, one per page. It will also be, of course, non-searchable.

It is still possible to steganograph information that will survive such treatment by using visible character kerning encoding, that will be replicated on the rasterized version. Some "safe" documents are typeset that way - if the document leaks, accessing a copy of it will reveal the identity of the responsible party; two copies assigned to different personnel, superimposed against a sunny window, will show the characters aren't exactly aligned in the two copies. A scheme used to do the trick is called QIM (other schemes exist).

Depending on the degree of control the encoding party has on the document, you might therefore never be sure you've successfully "anonymized" a document. For sufficiently large values of paranoid, even going all the PDF2ASCII way might not touch information encoded in typos or, who knows, synonym choice (I think I still have some texts that demonstrate such an encoding, but unfortunately they're in Italian :-) ).


What to do in case of a weak certificate on my bank's website?

The green lock indicates that an Extended Validation Certificate is being used. This means that the organisation has gone through some extended checks before the certificate is issued for their domain.

You should be right to be suspicious if this suddenly changes to a DV or OV certificate (Domain Validated or Organisation Validated), which are easier to obtain, and hard for a user to distinguish between. Checking the certificate is valid is a good move, however bear in mind that you should be checking the thumbprint, not the serial number.

You can check online SSL thumbprints using services such as this one on GRC.

Mandatory attrition link.

Note that if you were the subject of a targeted attack, a Man In The Middle could alter the GRC page to show you the certificate fingerprints that she was spoofing. Unlikely, but important to include this information here because it is easily technically possible. You could check the GRC page via TOR or via another connection (e.g. via 3/4G) in order to verify your main connection has not been MITM'd (and in fact the sites themselves to see if they have the same thumbprint).

It is likely that a bank telephone operator isn't technical enough to know what a serial number is and what the consequences of giving it you are.

  But this made me thinking. What should I do in case the certificate of
  my bank's website shows as weak, invalid, expired, ...?

For one thing, do not use the site at all for any sensitive information. Yes phone the bank, using a trusted phone number (e.g. from the back of your bank card), but ask to speak to somebody from technical support for the website and explain the issue to them.


Distinguishing between tokens and actual PANs for tokens based on reversible cryptographic functions

Am I right thinking that it is NOT relevant for the tokens based on
  mathematically reversible cryptographic functions?

You're right.  But you may not want to do it that way.

Tokens are generally isomorphic to card numbers (15-16 digit numeric) because they are supposed to be able to easily replace card numbers in whatever software the recipient uses.

If you were to use tokens that don't look like card numbers, than you've "provided a mechanism for distinguishing between tokens and actual PANs."  4111111111111111 is distinguishable from 057c331e-f538-11e4-b9b2-1697f925ec7b.

But tokens are usually generated by a processor or card brand and handed to a merchant for use instead of card numbers, usually using programmatic interfaces that were designed and specified to communicate 15-16 digit numbers.  The merchant probably already has software, with a database and application logic and everything, that was designed to store card numbers.  When they tokenize, they have to start storing tokens instead of card numbers.  If the tokens look enough like card numbers, then it's usually a simple non-disruptive switch.  For "distinguishing [between these isomophic] tokens and actual PANs", they might use invalid IIN/BIN numbers, fail the Luhn algorithm check, etc. etc.


There's several ways to go about this:

First, monetary rewards are a great incentive, but if you can't afford them you'll need to provide them with other types of rewards. I think creating a special page on your site/application and creating a 'hall of fame' list of people that have found vulnerabilities.

I'd also recommend that you consider running a CTF competition and include sections of your application's functionality in the CTF (or just make the CTF about who can find the most holes in your actual application). When you have a list of winners, post them publicly and keep them up so that people can reference it later.

If you decide to do either of the above, make sure you publicize it and detail your intentions/desired outcome, as Evan suggests, posting it to a security mailing list might help attract attention.

But as Terry says, if you build it, eventually someone will come and try to break it anyway regardless!


Is there such thing as a password enforced write protected flash drive?

You could encrypt the USB drive with truecrypt, then install your distro inside truecrypt to protect it. This wouldn't satisfy the write-protected requirement, but seems the best option considering everything else you're asking.

https://kb.berkeley.edu/jivekb/servlet/KbServlet/download/1625-102-55/


How is YouTube able to identify anonymous users?

This sounds like a Zombie Cookie.

There are a large number of places a web site can store state: cookies, Flash local storage, ETags, etc. When you clear your cookies, you do not necessarily clear all these places. Web sites can store an identifier in some of these other places, and track users despite them clearing their cookies.

If you use a dedicated private browsing mode, such as Chrome Incognito mode, or Firefox Private Browsing, the browser is locked down to prevent this. In particular, browser plugins are disabled, which avoids Flash local storage being an issue.

If you use standard browsing mode, and clear your history and cookies at the end of the session, you do not get the lock downs that private browsing modes provide, and you are vulnerable to Zombie cookies.


How does Burp update XSS/vulnerability scanning rules/payloads?

In their official document "Updates Settings", it states that:”New scans that start after the update will use the updated version of Burp Scanner. It is generally desirable to enable automatic updates of Burp Scanner to ensure that the latest scan checks are available.".  So it means you must update the Burp Scanner with the updated version for the latest scan checks.


Can a PowerShell script inside a Zip file execute automatically upon unzipping?

Generally speaking, the answer is no. There's a risk that a malicious archive will exploit a bug in your archive software to open a file, but if your software has such a bug then attempting to execute a script is actually relatively safe, as there's lots of ways to block that (you'd have fewer options it if just ran an executable or took over the archive utility directly).

With that said, if you're feeling paranoid, here's a few things you could do:

Set the execution policy in Powershell to "Restricted", which says "don't run scripts, period". It won't stop something like a CMD script invoking powershell with a malicious command, but it will stop an attempt to execute a .ps1 (or similar) file directly.
Rename the file, before unpacking, using a hex editor. File names in ZIP archives are stored in plain text, uncompressed, and if you simply change a non-NULL character (rather than adding or removing any) then it'll still be a valid file afterward. Changing the extension will prevent attempts to launch the file using ShellExecute or similar, although it could still be explicitly passed to Powershell... but if the attacker has the ability to launch arbitrary programs directly then the PS script isn't going to be anything except a payload, and probably a simple one. Hex editors are simple enough that it's extremely unlikely they'd have a vulnerability that could be triggered by reading any file, no matter how malicious.
Use a sandbox to unzip the file. For example, on Windows, there are multiple Zip unpacker apps in the Windows Store, most of which don't even have permissions to write to the file system without permission, much less launch a program. If one of them tries anyway, at worst you'll get a prompt asking you to confirm you want to open the file / launch the program.
Use a system that has no Powershell available. On a Mac or Linux box, this just requires never having installed it. On Windows, this requires moving/renaming/deleting the executable, removing its Execute permission, or using the OS' built-in app restriction policies to prevent it from running. Note that any of these actions require Admin privileges as Powershell is installed in the system directory, may cause the OS to malfunction in the long term (some Windows Updates require a working Powershell, for example) so you should undo it afterward, and that on anything except 32-bit x86 Windows there may be multiple versions of Powershell installed using different architectures (for example, on my x86-64 machine, there's one in "System32" (the 64-bit one) and one in "SysWOW64" (the 32-bit one, in the "Windows-on-Windows64" system directory).


OWASP + Atomic ModSecurity Rulesets - Too much?

Do not implement both. Is useless. Using the both rule sets is a waste of CPU and memory, because both of them are overlapping.

PCI Compliance require a WAF in some cases, but doesn't specify exactly the functionality. Almost all auditors will look to see if the WAF is protecting you from SQLi, XSS etc. which, in this case, any of the rule sets will do this job.


Is is bad practice to use non-standard ports? (for example ssh from 22 to something different)

Generally, no you're not introducing a new vulnerability by running a server on another port. The software will behave the same way regardless of what port it listens to (unless of course there is a vulnerability in the code that parses and sets custom ports).

Though you may find that your clients cannot connect to your server because a firewall or intrusion detection system notices "bad" traffic, since it expects the right protocol on well known ports. And if you're in an enterprise environment, those same firewalls and intrusion detection systems will likely be flooding you with false positives, making it harder to detect legitimate threats among the noise.

And the lesson may be hinting at naive security where an admin thinks they've protected themselves from ftp vulnerabilities by closing off ports 20-21 and you're opening ftp vulnerabilities by putting an ftp server on port 22 which is open to the world. The ftp software isn't more vulnerable here, but the system as a whole may be.


For the first question you can use openssl for decryption:

$ openssl enc <MODE> <ENC/DECRYPT> -in <INPUT_FILE> -out <OUTPUT_FILE>

As an example:

 $ openssl enc -aes-256-cbc -d -in encrypted.VHD -out decrypted.VHD

See this list of system recovery tools for linux distributions: SystemRescueCD, gddrescue and testdisk.

The later can be found in the main repository in ubuntu/debian:

$ sudo apt get install gddrescue testdisk


This appears to be a partially meaningless list of information security buzzwords.

While some terms exist in an infosec context (e.g. TCP SYN Flooding), others are uncommon or ridiculously vague ("Hybrid Attack", "Varied Rate"). As it mixes arbitrary levels of precision and non-established expressions, the entire list seems inappropriate for a comprehensive overview of different attack types and I suggest to not further question the term poison dart, since it will likely not be understood in the security community.

If you are interested in generating security buzzwords yourself, have a look at a this blogpost. (The generator itself is unavailable at the time of writing.)


Security engineer in a broad spectrum defines several responsibilities and roles. To have a bird's eye view there are several categories that exist. It can be broadly classified as developers - one who develops security tools, and analysts - who use these security tools to measure security.
Cryptography: It is involved with writing algorithms that have to do with encryption, authentication and stuff like that. Generally, these are the developers of the security field, who actually develop software for security and analyzing security. Not many do things like this because it is very advanced and sophisticated and requires great knowledge in Math.
Biometrics: This is another broad field. It covers security of physical applicances in conjunction with actual human intervention, such as fingerprint security, retina scan etc. Generally, hardware engineers and embedded software developers design these kinds of devices.
Information Security: This is the category where computer science and IT engineers come in. It includes fields such as network security, cryptography, etc.
To have a better idea take a look at this site which may give you a good idea.