What is legally required to store HIPAA data in the "cloud"?

If you're using CloudBerry backup, enable the client-side encryption so that the files are encrypted before they reach Amazon S3.

Encrypted Data outside of HIPAA scope

You do not need a Business Associate Agreement (BAA) if you are sending encrypted data to a third party provider.  Note this encryption must be done with FIPS 140-2 compliant ciphers such as AES-128.  Essentially, under HIPAA, encrypted PHI data does not fall under the scope of the law's protection, so long as it is done with approved ciphers.  If only encrypted data is compromised, you do not need to notify anyone of the breach.

If unencrypted, get a BAA

Amazon does now offer HIPAA-compliant hosting packages, so if you want to have data unencrypted at Amazon, you would need to sign off on their BAA (provided boilerplate via  a web form).  I strongly disagree that a BAA is unnecessary for a cloud provider you are storing PHI data with -- I've been through many HIPAA audits from third-party certification companies and they always ask about this.    You would then also need your own documentation and security policy to reflect this relationship and document safeguards around the PHI.

Source Material

HHS provides information about encryption and breach notification here

Information about BAAs is provided by HHS here.


Should I change all my passwords due to heartbleed

Short answer: Yes, all passwords.

Long answer: At first sight, you only need to change the secret key of the certificate. But due to several reasons, all passwords are affected. Here's why:

Reason 1: Chained attack

Someone captured the secret key of the certificate. From that time on, he could decrypt all the traffic to that site.
If you logged on for whatever service on that website, your password was revealed. Probably the most common service is Webmail, so let's use that as an example.
Reading your emails, the attacker found out which other services you are using.
Using the password reset mechanism, the attacker simply reset all the passwords, confirmed the reset emails and deleted those emails of course.
The attacker now has access to all your services.
The website owner (whose secret key was stolen) became aware of the security leak and fixes it. The service (we assumed Webmail) is no longer vulnerable.
The website owner informs you about the leak and asks you to change your password.
The attacker can still use all the other services as long as you don't notice that you cannot login anymore (because he changed the password). This means: For services which you use often, it's more likely to detect that it was misused. For services you don't use often, you'll not notice.

Therefore you at least have to check each single password, whether it is affected or not.

Good thing on this attack vector: You'll be aware of the issue.

Reason 2: Access to database

Someone captured the secret key of the certificate. From that time on he could decrypt all the traffic to that site.
If the admin of the website logged on to do some administration, moderation or whatever, the attacker now has the password of the admin.
With that password, the attacker gets access to the database.
Depending on the security of the database, the attacker can read

the usernames
the passwords in plaintext (worst case)
vulnerable password hashes (e.g. MD5 hash, unsalted) (bad case)
secure salted hashes (best case)

The attacker calculates the password from the hash
The website owner fixes the problem
You are informed by the website owner to change the password.

Since you as the user cannot know how securely the password was stored in the database, you need to consider that the attacker has the password (and username). This is a problem, if you reused the password for other services.

Bad thing: You don't know whether you are affected, because logging in to other services still works (for you and for the attacker).

Only solution: Change all passwords.

Reason 3: not only secrets certificate keys are leaked

 I looked at some of the data dumps
 from vulnerable sites,
 and it was ... bad.
 I saw emails, passwords, password hints.

As posted by XKCD #1353:

So the attacker could already have your password in plain text even without access to the database and without chained attack.

Notes

The second problem, described by @Iszy, still remains: Wait to change your password until the service has fixed the Heartbleed issue. This is a critical hen-and-egg issue, because you can only reliably change all the passwords, when all services you use are updated.


What is end-to-end encryption and how to do it (correctly / securely)?

We call communication e2e encrypted if one side encrypts the message and it remains encrypted on the whole way to the other side, so that only the other side can decrypt it.

Fir instance, Alice encrypts an Email, so that only Bob can decrypt it. Bob sends messages ecncrypting them so that only Alice can decrypt it. The email can be relayed via multiple servers and the whole time remains encrypted. The can use pre-shared key and symmetric encryption, or one time pad (it can be hard to implement in real life, but still it is a valid option), or - much more often - they can use PKI, for instance they both can obtain S/MIME certificates issued by some trusted Certification Authority and use public key of each other to encrypt messages. The same is applicable for messengers.

You are asking about offline. It does not matter, if one side is online or offline. When Alice is encrypting a message to Bob, Bob doesn't have to be online. In case they use PKI she has to know the public key of Bob. Alice uses his public key to encrypt a message to Bob and sends it to him. When Bob comes online, he receives the message and decrypts it.

To handshake: We speak about handshake in case of TLS. Here is direct connection between both sides is needed. That's why TLS is normally use only when at leas one of both sides has a fixed IP or fixed domain name. When two people communicate (e.g. via messenger) they are in most cases in the networks of their internet providers and have neither fixed IP nor fixed domain name. Means, Alice does not know how she can reach Bob to establish a connection with him. And Bob doesn't know how he can reach Alice. In such case they just cannot establish a TLS connection to each other. They can do that only if they are in the same network which happens rarely.

In many messengers users establish connection with the server, because the server has a fixed domain name and at any time it is known how to reach the server. Alice and Bob both establish connection to server, and the server forwards messages from Alice to Bob and vice versa. One handshake happens between Alice and server, the other one between Bob and server, but no handshake between Alice and Bob.

If Alice and Bob use their public keys to encrypt messages to each other, then the server cannot decrypt them. But many messengers don't support that and only have encryption between ALice and server and between Bob and server. Server obtains an encrypted message from Alice, decrypts it into plain form, encrypts it for Bob and sends it. This is of course not e2e encryption.


Does setting httponly prevent stealing a session using XSS?

In general, if httponly is set on its token then an XSS attack shouldn't be able to retrieve a session token. Modulo past bugs in browsers and plugins, and server misconfiguration (eg responding to HTTP TRACE).

But it's not worth much. You can stop XSS from getting hold of the token, but an XSS attack still has full control of the session on the user's machine: it can force the user to do pretty much anything on the site, or falsify the user's interface to the site (eg to phish for site credentials). See BeEF for an example of what an attacker can achieve with a compromised session: you've pretty much lost already.

Not setting httponly at best makes life slightly easier for the attacker in that they can access the session from their own machine in their own time, rather than being limited by the amount of time the user keeps their browser window open. It's worth having httponly where possible, but it's a mild mitigation that does not magically protect you from the effects of XSS.


Is DIGEST-MD5 secure if done over HTTPS?

Digest access authentication is intended as a security trade-off. It is intended to replace unencrypted HTTP basic access authentication.
  It is not, however, intended to replace strong authentication
  protocols, such as public-key or Kerberos authentication.

By implementing SSL you are bringing public-key authentication into the equation so you are addressing that issue. Anything stronger than that would require additional infrastructure that wouldn't be practical in many situations.

  Many of the security options in RFC 2617 are optional. If quality-of-protection (qop) is not specified by the server, the client
  will operate in a security-reduced legacy RFC 2069 mode.

That has to do with implementation and really doesn't apply here.

  Digest access authentication is vulnerable to a man-in-the-middle (MitM) attack. For example, a MitM attacker could tell clients to use
  basic access authentication or legacy RFC2069 digest access
  authentication mode. To extend this further, digest access
  authentication provides no mechanism for clients to verify the
  server's identity.

Using SSL will greatly reduce the risk of MITM attacks. It will provide the method for verifying the server's identity. Yes a certificate can be spoofed, but web browsers are getting better at alerting users to these issues.

  Some servers require passwords to be stored using reversible encryption. However, it is possible to instead store the digested
  value of the username, realm, and password.[2]

Yeah you shouldn't be doing that anyway.

So the answer is yes, SSL does address the weaknesses quite well. It isn't perfect but the next step after that is a pretty big one.


How proxy server remember the IP addresses of client to send the response packets back?

A HTTP proxy or SOCKS proxy simply accepts a TCP connection from the client and maybe after some initial handshake with the client creates a TCP connection to the server. From then on it forwards data (not packets - this is application level!) received on one TCP connection via the other TCP connection as long as both TCP connections are open. There is nothing special about it - it just needs to associate one TCP connection with the other which a simple programming task.

  how many connections between proxy server and proxy clients can be established at the same time?

This is not a security question, but: if the IP address of proxy and client are constant and the proxy is only listening on a single port then of the 4 parts of the connection tuple only the source port on the client can vary. Thus there are in theory at most 65535 connections between client and proxy and in practice even less since the client will not use all ports for connections to the proxy.


The actions you described constitute at least one felony.

Regarding the ethics of this type of disclosure:

If you had discovered this vulnerability by chance alone and immediately reported it, you might not have gotten in trouble.

Your self-described actions differ however, in that you not only intentionally breached the system's security and made copies of sensitive / proprietary data, you also disclosed administrative-level credentials to a third party without prior written authorization to do so, and then got "caught" through social engineering.

You don't need our advice, you need an attorney.


Is it better to encrypt to an untrusted key or not to encrypt at all?

Assuming that the key is completely untrustworthy to the point that anyone can decrypt the message, then it can't be any less secure (technically) than unencrypted.

The main risk is psychological, in that you may come to trust the untrusted key.


Open source or common implementations for reverse proxy web application security

Using mod_security as a reverse proxy is common,  especially in the IIS world where only recently has a free WAF has become available.  Apache running as a reverse proxy will handle your SSL handshakes,  so this won't be a problem.
However it sounds like you have a MUCH BIGGER PROBLEM on your hands.  If you can't update Apache you are completely and totally lost.  I guarantee you that there are publicly available exploits for your system.  There are new security systems available for Linux such as AppArmor and SELinux, not having these is a fatal mistake.
I am not sure why you think it's okay to have an extremely old system and that putting a band-aid over it is acceptable behavior.  If a security expert sees this they are going to be very concerned.  A WAF is in no way shape or form a substitute for fixing known vulnerabilities in your system (period).  A WAF is just another layer, and you must plan on failure.  (And a WAF will be the first to fall because it is usually the weakest.)


Compromised JSON Web Token (JWT) Bearer Token

To answer your questions:

  1) How do you handle a situation with a compromised token secret which is shared between a client and the server?

Add an expiry date to your token. Make sure the token cannot be used after the expiry time. But this doesn't prevent unauthorized access within the token's expiry period.

So, to overcome this problem you can embed the client's IP address or other such information inside the token. And make sure the incoming request with the token is used from the same IP Address to which it was issued to.

  2) Do you logout all your clients and define a new token secret for future requests? (that would be a bad experience)

If you mean logout all clients who are using multiple tokens in a authorized manner, then No. You can continue to use multiple tokens at the same time, provided you have a finite expiry period to the tokens. This make sure your token are used within the intended time window.

But, if you mean when the token is stolen and you somehow figured it out. Its better to invalidate all tokens to that user.

However, you may want to have a mechanism that will revoke all tokens explicitly in special cases. May be like when the user resets his password because he thinks his password may be compromised.

  3) Is there a way to just logout the compromised client?

May be, depends on your ability to precisely identify which token has been compromised. Which may lead to all clients using that token to lose access. But, I wouldn't recommend it. But, hey you can always write code that will dynamically re-authenticate and get a new access token when old client can no longer use the token. :-)

Don't be afraid to invalidate a token when necessary. If you loose a token write a dynamic script to re-authenticate. If you think you may loose the session details when you use new token, resend the expired token to server while re-authenticating. Using this expired token you can reconstruct a new token with the old token's session details. Provided you have embedded session details in the expired token.


gpg --armor --export-secret-key differ on last 4 characters

TO THE ASCII ARMOR SPEC! -- RFC 4880. The ASCII ARMOR specification is given in Section 6.2:

  Concatenating the following data creates ASCII Armor:

  An Armor Header Line, appropriate for the type of data
  Armor Headers
  A blank (zero-length, or containing only whitespace) line
  The ASCII-Armored data
  An Armor Checksum
  The Armor Tail, which depends on the Armor Header Line

So the last 5 characters (=TGyi and =/eDz) are a checksum of the armored data. Oddly Section 6.2 doesn't define the checksum format, but an older version of the spec, the 1995 Internet Draft for PGP, does:

  The Armor Checksum   is a  24-bit CRC   converted  to four  bytes  of
     radix-64 encoding, prepending an   equal-sign  (=) to the   four-byte
     code.

Checksums are used in a number of other places is the RFC, always defined as two-octet sums modulo 65536:

  Then a two-octet checksum is appended, which is equal to the
     sum of the preceding session key octets, not including the algorithm
     identifier, modulo 65536.

It does seem a bit odd that two copies of the same data would have different checksums, ... maybe there's enough ambiguity in the spec that different versions of openpgp use different methods to compute the checksum?

(Disclaimer: this is my first time diving into the PGP spec, perhaps someone more familiar with it can explain properly)


I figured it out! The app was using a service called Approov, which was a third party service generating a new token every five minutes to prevent third party apps from accessing a protected ressource.

Took a while to get around it, but at least i learned something new.


What are the risks of installing a CA on the same machine as OpenVPN server?

The OpenVPN documentation being referred to is the Getting started How-To on the OpenVPN Wiki. Specifically, this paragraph:

  BEWARE: One common mistake when setting up a new CA is to place all the CA files on the OpenVPN server. DO NOT DO THAT! A CA requires a private key which is used for signing the certificates your clients and servers will use. If you loose control of your CA private key, you can no longer trust any certificates from this CA. Anyone with access to this CA private key can sign new certificates without your knowledge, which then can connect to your OpenVPN server without needing to modify anything on the VPN server. Place your CA files on a storage which can be offline as much as possible, only to be activated when you need to get a new certificate for a client or server.

The concern is that if the CA's private key is ever stolen, the attacker could issue themself valid certificates for your VPN. Those certificates could be used to either fool your client into connecting to a rogue VPN server (letting the attacker spy on or modify your traffic) or fool your server into accepting a connection from an unauthorized client (allowing the attacker to use your VPN).

Keep in mind that if you're only ever planning to run a single VPN server, any attacker who compromises your VPN server will gain the ability to control and monitor any traffic that flows through that server anyway, even if they can't steal your CA's private key. For that reason, you may find storing your CA key as a private root-owned file on your VPN server to be an acceptable risk.

On the other hand, even in that scenario there may be some minor benefits to keeping your CA key on a separate machine:

A compromised VPN server might be easier to detect than a stolen CA certificate
You would be partially protected from attacks that can steal information from your VPN server but not gain control of it
Recovering from a compromised server might be slightly easier, depending on whether or not you find it easier to deploy a CRL to all clients than to deploy a new CA certificate to all clients

It's up to you whether or not you consider those benefits to be worth the possible inconvenience of keeping your CA on a separate machine.

If you're planning to run multiple VPN servers, keeping your CA private key on a separate offline machine is more important, as doing so prevents the compromise of one VPN server from affecting the security of other servers.


Why did the sites that went down in the Dyn DDoS attack (Oct 2016) not have secondary DNS?

They probably did.

Checking on one that was actually affected we see that basecamp had 4 DNS servers but all were hosted at dynect.net. So if dynect's infrastructure was attacked it's easily possible none of them were responding well.

dig -t NS basecamp.com

; <<>> DiG 9.8.1-P1 <<>> -t NS basecamp.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39198
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;basecamp.com.          IN  NS

;; ANSWER SECTION:
basecamp.com.       28725   IN  NS  ns3.p25.dynect.net.
basecamp.com.       28725   IN  NS  ns4.p25.dynect.net.
basecamp.com.       28725   IN  NS  ns1.p25.dynect.net.
basecamp.com.       28725   IN  NS  ns2.p25.dynect.net.

Same thing for GitHub

dig -t NS github.com

; <<>> DiG 9.8.1-P1 <<>> -t NS github.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22950
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;github.com.            IN  NS

;; ANSWER SECTION:
github.com.     24417   IN  NS  ns1.p16.dynect.net.
github.com.     24417   IN  NS  ns2.p16.dynect.net.
github.com.     24417   IN  NS  ns3.p16.dynect.net.
github.com.     24417   IN  NS  ns4.p16.dynect.net.

;; Query time: 1 msec
;; SERVER: 173.203.4.8#53(173.203.4.8)
;; WHEN: Sat Oct 22 06:09:42 2016
;; MSG SIZE  rcvd: 114

It should be noted that this is an example of putting all of ones eggs in a single basket. Most colocation providers, ISP's, and even many cloud providers talk about redundancy across their multiple datacenter but frequently they are all within a single infrastructure of some type such as all being routed, or black holed, together because all of those IP's share a single BGP ASN from an Internet backbone perspective and although that's designed to prevent looping when mistakes occur it could take all of one of these colocation providers, ISP's, or cloud providers network out temporarily.

This brings up the question, so why weren't the DNS servers on completely different ISP's networks to prevent single points of failures like this. To that I would say it's more an oversight made by the person who selected the datacenter/cloud provider. Sometimes this is due to ease of billing or due to other dynamics of the vendor relationship or system deployment methods but the more formal term for why this happens is simply path dependence  (i.e. they do this because that was the way it was done at a previous company and it worked fine there...)

To their credit it does appear the Dyn DNS offers some Enterprise solutions that have a lot of add on features which are probably only available if Dyn DNS is managing all the DNS servers. Interesting risk trade off. I'd love to know what their marketing literature & contractual SLA's says about the redundancy and availability of their infrastructure.

In any case, it would be wise to have DNS servers hosted with more than one provider.


Where do organizations store their sensitive documents? How do they protect them?

You are talking about a Document Management System. Typically these systems allow users to save documents and delegate read/write access on a user or group level. They also allow for auditing of when users access documents. Some may also restrict editing and copying or even printing of a document (in addition to auditing all such actions).

There is simple to complicated. Some use a basic NAS with AD Group Policies. Others add a layer of encryption (Full Disk encryption, TrueCrypt, something else).

Finally you have the 'Enterprisey' systems. These have workflow and publishing management, complex ACLs and options on securing the documents and logging all activity.

Xeros sells a system called DocuShare (http://docushare.xerox.com/ though now marketed more as CMS) which I know several UN Organizations use. There is also KnowledgeTree (https://www.knowledgetree.com/)

These are just two of many. YMMV depending on actual business needs. Hope this helped.


Is it possible to get malware through an incoming video/audio stream? (e.g. Omegle, Skype etc.)

It could be possible in some cases.
For example, imagine that the videoconferencing software has a vulnerability into the file format parser (E.g. buffer overflow)... then it could be exploited by a remote attacker.

Look at VLC for example http://www.cvedetails.com/vulnerability-list/vendor_id-5842/opec-1/Videolan.html


Webpage sent me my password in clear text can it be secure?

It is not as secure as it most likely should be, though there are occasional justifiable reasons for storing a password in clear-text (for example, unattended third party service access when authorization token's aren't an option).

It is certainly not secure to provide the decrypted password back to the user EVER.


Is it common practice to log rejected passwords?

Logging the value of a failed password attempt (cleartext or otherwise) seems like a security anti-pattern. I've never seen a web app that does this, and I'm not aware of any default system services such as SSH that do either. As pointed out by @tylerl below, most systems simply log meta-information about an access attempt (e.g. username, time, perhaps IP address, etc.).

Why This Should Be a Security Anti-Pattern

Offhand, I can think of three reasons why logging the value of a failed password attempt is a bad idea:

1. User Typos

It's extremely common for people to mistype a password by one or two characters. Examining a log file of failed attempts would make many of these easy to figure out, especially if you could contrast a sequence of failed attempts with a successful auth.

2. Guess-and-Check

Many people have two-or-three passwords they cycle through for everything. Consequently, when they forget which password they used on a given site, they just cycle through all of them until they find a match. This would make it trivial to hack their accounts on other sites.

3. Log Bloat

Storing failed passwords serves no useful purpose for the vast majority of authentication services in production today. While there may be some edge cases, for most people, storing this data is simply throwing away disk space.

On Relevant Legislation / Standards

I don't know of any standards (PCI, HIPAA, etc.) that specifically address procedures for storing failed login attempts, but I think that granted the above facts a good legal argument could be made for why the same standards that apply to storing passwords in general should also apply to failed-password attempts as well. In other words, you could make a legal argument that a failed-password is still categorically a password, and as such it is subject to the same standards.

While I'm certainly not a lawyer, I wouldn't want a judge to have to decide whether or not I was negligent or in violation of industry standards because failed passwords were stored in cleartext and consumers suffered the consequences. I don't think that would end with a favorable decision.

I agree with the OP that it might be useful for the various standards bodies to address this issue specifically (if they indeed haven't already).  To that end, my suggestion would be to create a compliance standard of not storing the value of failed password attempts at all.


You should either redirect the request with a 302 response or forward the page in your backend.

You can not be sure that the <meta http-equiv="REFRESH" ...> is actually performed in the browser. There might be some browsers, which do not support it and there are even browser addons which block such meta actions: Chrome Auto Refresh Blocker

Beside that the <meta http-equiv="REFRESH" ...> is deprecated and should not me used anymore (W3C).

If you want to use it anyway you have to make sure that you do not expose any data for not authenticated requests.


What is the danger of the "FTP RNFR ././ attempt"?

The attacker was trying to exploit the CVE-1999-0081 vulnerability of unpatched WU-FTPD installations, where a software bug allows RNFR Rename From commands to overwrite or rename files, even if these commands are violating file permissions and when an unescaped input parameter using relative path pointing to directory root (././) is used. The following commands (PWD Print Working Directory, and CWD Change Working Directory) suggest the exploit attempt was unsuccessful, otherwise the RNFR (Rename From specifying a file to rename) would most probably be followed by RNTO (Rename To) command (probably to rename the root path and remove file permissions on the whole FTP directory structure?). The attacker then retrieved his current position within your FTP directories structure (PWD) and navigated to another location within it (CWD). CWD however takes an argument for the new location, so I can't say what his next step might have been based on information you provide.


If a reliable provider wants to change their JavaScript, they have to update the integrity hash and distribute that to all possible users.

Not if the caching policy means that the referer will not be cached for longer than the referee. It's another strong argument for using long expiration times for static content and injecting a variable into the URL. I think (would want to spend some thinking time on this, and testing) that using mod_pagespeed's extend_cache would deliver the desired result without having to wait for browser developers to implement SRI. If smart 404 handling at the origin (i.e. creating a cacheable response rather than a 404) then the heavy lifting could be done on the CDN rather than at the origin.

My immediate thought on reading about SRI was that it should be an extension to CSP indicating what resources are allowed to reference a content item (rather than specifying what content items a resource is allowed to reference). However, IME, most browsers (Firefox is a notable exception) do not have bulletproof referer handling. The only way I can see asymmetric encryption being of any use would be to associate it with the referer mechanism.


Funny thing, I've experimented with an online encoding converter. I think you have an encoding problem on the client side.

When I embedded the string inside the PHP code, it worked.

$test_var = chr(0xbf) . chr(0x27);
echo(bin2dex(addslashes($test_var)));

Resulted in: bf5c27

The problem is when you get the variable from the URL:

뼧 after addslashes() results in ebbca7

¿' after addslashes() result in bf5c27

but the online encoding converter shows bf27 for 뼧 and bf 27 for ¿'.

Can you set the encoding of your PHP configuration to GBK and UTF-8 in php.ini, then try with the ¿' characters again? The examples in the links that you've given does not echo the output directly so you might have got scrambled on the client side as I've mentioned.


Is it exists a possibility to encrypt with several public keys and decrypt with any of them?

PGP has a method for handling this that (in your case) would go something like:

To protect the data:

Application knows user's public key (Ku)
Application generates "Hello world."
Application generates good symmetric encryption key (Ks)
Application uses Ks to encrypt "Hello world."
Application makes a copy of Ks that's encrypted with Ku
Application makes a copy of Ks that's encrypted with application's public key (Ka)
Application stores encrypted string and both encrypted passwords

To retrieve the data:

Application delivers the copy of Ks encrypted with Ku
User decrypts it using their private key
Application uses the decrypted Ks to decrypt the data and display for user.

Because there's a copy of Ks encrypted with Ka, the application can decrypt the data without the user as long as the application's private key is available.

EDIT:

As @CBHacking stated in comments, it's highly advisable you find an existing well-tested crypto system that will suit your needs. Roll-your-own crypto is an easy way to make embarrassing mistakes. Speaking as someone who implemented the first non-plaintext password storage at my company, there are plenty of options created by people who understand this stuff way better than we do.


Compiling exploit on a different kernel than target (but same arch): is it un-smart or risky?

It does not matter what kernel you compile an exploit under.

The failures were because the kernel was providing protections from the exploit methods you used. These protections are done at runtime. The kernel does not somehow insert code to cripple exploits compiled under it. The solution would be to run the exploit on a kernel with these security features removed or disabled, not to compile it on such a kernel. You do not have to have ASLR running (or even supported by your kernel) to compile a position-independent executable, for example.

The running kernel does not change the output of the compiler in a way that would break an exploit. All that matters is that you are compiling it with the same (or at least compatible) compiler features, libraries (if statically linked), and optimizations. If this is the case, it can be compiled anywhere. You could even compile an exploit for a Linux application on Windows or OpenBSD, and vice versa.

Some things you may want to keep in mind regarding your toolchain's environment:

Compiling on one system with -march=native may result in an executable that does not function properly or at all on another system. Avoid hardware-specific optimizations.
Using features from, say, GCC 7.2.0 may cause breakage if compiled on a machine that only has 6.4.0. The same applies to regressions that may break an exploit on a newer compiler.
If your target has header files which are incompatible with a working exploit for whatever reason, you will need to include the correct header files or compile it under a system which has them.
Some libraries' build systems check the kernel version running, and use this to decide what features to include. Be aware of this if you are compiling libraries on this system as well.


Using TPM persisted RSA key in Windows and Linux

Interesting question.
I don't have a direct answer for you or a piece of code that translates yours into Linux land, but I am convinced TPM chips are usable as PKCS11 providers on Linux today. Please see the resources below

TPM2 and Linux
Securing key handling using TPM
TPM enabling the Crypto Ecosystem for enhanced Security
TPM2 PK11 (practical example under ark)

Please report back your experience, it would be interesting to find out how you got on.


Is running a TOR node from device in home network secure?

This is a bit of a grey area and it will largely depend on the laws in place in your country. In some countries you can be held accountable for the traffic you allow being passed over your tor node. Some countries consider Tor nodes to be carriers, meaning that if you do not actively monitor all traffic, you can't be held accountable for what goes over it (similar to an ISP).

There are cases where Tor node owners were succesfully prosecuted for hosting a Tor node which was abused for accessing illegal content or masking an attack towards the regular internet. This is of course a risk you need to take into account, if you aren't prosecuted the police might still question you up to a point where it is almost harasment. I'm not saying that this is common, but it can happen, especially in countries where there is less police oversight or strong tendency of censorship/internet control.

In most countries there aren't any clear defined rules, and precedents may exist from previous lawsuits, so it is best to consult a lawyer in your case. Just be aware that you can get into trouble for hosting a Tor node, how noble your cause or intent may be. The fact that it is still used a lot for (unfortunately mostly) criminal purposes puts Tor (or any other anonymity service) in a bad daylight.


Is displaying remaining password retry count a security risk?

Locking accounts is a bad idea in the first place.  It might seem like you're making your organization more secure by keeping out "bad people" who are "guessing" at passwords using brute force attacks, but what have you really solved?  Even with this policy and a perfect userbase who never makes security mistakes, an attacker can perform a denial-of-service attack on your organization by repeatedly using the password "aaa" to lock out the accounts of critical users.  Consider what happens if your attacker gets a copy of the list of usernames for your entire IT department:  Suddenly, IT itself — the organization that would otherwise be able to unlock other users — is itself completely shut down.

Always consider what the threat model is before implementing a policy.  A "bad guy" determined to hurt your organization will find alternative attack vectors.  Your lockout policy won't even faze a nation-state actor (like Russia or China or the NSA); a determined hacker will just find other ways around it (like social engineering); and it will only hurt legitimate users of your service, no matter how low or high you set the lockout counter.

Moral of the story:  Don't lock out accounts.  Instead, do what Apple does with the iPhone:  Each login try doubles the login delay, so that after a dozen failures or so, you have to wait one hour between each successive attempt.  That's long enough to prevent "bad guys" from performing brute-force attacks, but still short enough that a legitimate user can spend that hour figuring out what their password was and typing it in properly after lunch — or contacting IT and apologetically asking for help.  (Similarly, "flooding" policies can often be implemented at the IP-address level in your firewall, not just at the user-account level in your software, if you're concerned about a dedicated attacker trying to brute-force many different accounts.)

And if you don't lock out accounts, you don't need to have a counter — or display it.

[see also: this excellent answer on a similar question]


How to prepare for a career in Pen-Testing

Pen testing is a type of consulting, and like any type of consulting so much of what is important is non-technical, so in addition to learning some programming and especially scripting (perl, python) I would focus on learning about how businesses work and how to work within one. Having a pen tester who knows how to find vulnerabilities and exploit them is one thing, having one who can stand up in front of bigwigs and convince them to give their employer lots of money for their services is a very rare thing and for more valuable. Getting that first job will be much easier if employers see someone who they can place with a client.

Learn business terminology, acronyms, the software development life-cycle, how companies get and spend budget, and typical company structure and governance. Learn presentation skills. Pen-testing is a good place to start but you probably don't want to get stuck there as there's a seniority block which you'll never get above, so you will want to develop your security skills beyond that. You won't be able to become an expert in these subjects in a university; so much of that comes from experience, but you can learn enough to set yourself out from the rest of the pack.


Propagating user context between microservices secured with M2M JWT tokens

I think the advice you got to not send the ID token is good. In general, an ID token should never be forwarded to some other entity besides the client that received it. Besides just breaking this cardinal rule, there's no cryptographic or physical relationship between the two tokens. As a result, a substitution attack vector is opened up. In other words, the micro-service receiving the two tokens has no way of knowing that the non-standard presentation of the ID token was replaced by an attacker with their own since that token is not related in some way to the access token it finds in the normal Authorization header of the same request.
When working in a micro-services environment where you need user context info into the bowels of the mesh, you have three options:

Share access tokens among the micro-services
Embed other access tokens in the one initially issued to the client (or the phantom equivalent)
Exchange one token for another

You'll use option one when multiple micro-services make up the same security context. If they belong to the same bounded security context, then it's OK to share them. If this is the case, they will have the same "audience" and the access token will be audienced to that set of micro-services. An example of a shared context might be a handful of "payments" micro-services that work together to perform payments functionality. These all come into contact with the same product data, user data, etc., so they are effectively the same entity from a security modeling perspective, one could imagine.
When a micro-service calls another in some other security context, it will use one of the other two approaches. The first is the easiest but requires knowledge of a priori of the call from one context to another. In other words, when the token is issued at the authorization server, it must be known that the receiver of that token is going to call a service in a foreign domain (i.e., some other security context). With this knowledge, the authorization server can embed a token for that purpose in the one it issues to the originating micro-service. This is very typical even if it sounds outlandish at first. Think again of that payments service: it's easy to foresee that it will always call an accounts service which may be in a different security context. For this reason, the authorization server may always issue a separate token scoped for accounts and embed that in another that is scoped to payments. It will issue this token within a token to any client that requests an access token with the "payment" scope.
The other choice is to exchange one token for another. This will be done when the calls from one service to another are not known at the moment of token issuance. This can be the case, for instance, when the number of hops is very large, or the route is contextual and user-dependent. When exchanging one token for another, it's important that the scope of access be controlled. You don't want to exchange a low-power token for a very powerful one, for instance. So, think about scope enlargement and try to forbid or greatly control that during an exchange. A good article about batch processing that discusses exchange more can be found on Nordic APIs.
(These three options are orthogonal to whether or not you use the phantom token or split token approaches. One of those may be used in conjunction with these token propagation techniques. If you use those techniques, which you probably should since you have a gateway in the mix, your front-end SPA won't be able to access the actual access token nor any others that may be embedded in it.)


typical request, what type of encryption is this?

Passwords in databases are rarely encrypted, they're hashed instead. Encryption is a reversible process - you can decrypt content, given that you know the encryption method and password. Hashing on the other hand, isn't a reversible process.

What you're looking at is not an encrypted password, but a hashed one.

On the question of replacing the password in your database - this is easy to do, you'll just need to use the same hashing algorithm, generate your own hashed entry, and store it in the database. Keep in mind also the fact that most hashing algorithms use salt.

I'd suggest posting the product name, or the system you're trying to change the passwords for, then we may be able to let you know how to change these passwords.

One thing is certain - it would be really hard to find out the original passwords from the hash (unless there's no salt, or something that exists in rainbow tables).

I've looked at it, it's most definitely a base64 encoded hash, the hash algorithm most probably being MD5 or similar. What you're doing wrong in your decoding is that you're trying to make sense of text data (which looks like garbage text and doesn't make sense), while you've got to look at the ASCII codes of each character instead. Look at the last text output field of http://www.hcidata.info/base64.htm
You'll see 16 bytes (or 8 bytes) of ASCII hex codes. This is your target. Then look at the output generated by the various hashing algorithms:
http://openwall.info/wiki/john/sample-hashes

Good luck!


How can I securely convert a "string" password to a key used in AES?

What you do is the following:

Generate a long key (this is just a secure randomly generated amount data, you can use 128 bits)
You use this key to encrypt your file with AES (meaning you use it as a password)
You encrypt the key itself with AES using your password (which is a bit shorter but easier to remember. Now AES requires this again to be either 128, 192 or 256 bits of length so you need to make your password of that length. Hence you can just use PBKDF2   (or scrypt or bcrypt) to create a fixed-length key from your password.  DO NOT STORE THIS.
You keep a hash of your hashed password using PBKDF2 (or bcrypt or scrypt). This will allow you to check if the password is correct before trying to decrypt your encrypted key.

So:
hash(hash(password)) --> can be stored
hash(password) --> cannot be stored

You always need to provide a salt even if you only have one key (this largely prevents rainbow table lookups). Fortunately for you, salt generation is done automatically by PBKDF2.
So in the end you actually have 3 things:

Your encrypted files
Your encrypted key
A hash of your password to verify it

You might ask why you need the key: If you would change your password (and you had encrypted all your files with your password), you would need to first decrypt all your files with your orignal password and then re-encrypt them with your new password. With this implementation all you need to do is decrypt and re-encrypt the key (as this key serves as your password).
EDIT
I kind of misinterpreted your question, I've added the key derivation function.
Also a good read (courtesy of IBM)


Encrypt Items With Single Key or Use KDF+Salt To Encrypt Each Item?

Given the property of SSNs - beeing all guaranteed to be different - there is not much added in terms of security using the second approach, if the used mode of operation (which you didn't disclose) allows IV reuse.

But please let me suggest a third option: you should be using a Hardware security module (HSM) for this.

Your question does leave me with the impression that you are trying to solve this programmatically, yet there is a huge problem with that:

If your application is to use the SSNs, there has to be the key somewhere accessible. Encyption of the SSN should probably be deployed to keep the data safe in case one of the hard drives or the stored data gets leaked.

When this happens and you keep your key with the data, there is nothing protecting the data anymore. A data dump would most certainly also contain the key, unless an HSM is used.


Encrypting/decrypting information in database

YES YOU CAN.

It is possible to use the same password for authentication and for data encryption. What you need is to derive from the password, using your favourite key derivation function, a sufficiently long password-dependent stream. You then use the first half of the stream for authentication (that's the part you store in the database), and the second half as encryption key.

For the KDF, use for instance PBKDF2, with SHA-256 as internal hash function. Adjust the iteration count so that the computation is tolerably expensive (a high iteration count slows everybody down: your server, and an attacker who would try to guess the password; so make it high). Make sure that you select a new, random, big enough (say 16 bytes) salt for each password (you will store the salt along the hash value in the database). Generate 32 bytes with PBKDF2; use the first 16 bytes as authentication token (stored in the database), and use the other 16 bytes for encryption (with a proper symmetric encryption system, preferably one with integrated integrity check, such as EAX.

If you apply all that and do not botch the implementation, you will be sure that when you will get hacked, it will be the user's fault (e.g. one user will use the name of his dog as password).


A dictionary attack is usually carried out offline, not against an online website, for exactly the reason you raise.  It requires that the password database be compromised and available for offline attacks.
A password spray attack is more common for online resources.  With a password spray, a small number of passwords are tested against a large number of accounts, spreading out the attempts to avoid triggering locked accounts.  This is based on the fact that most accounts lock on X amount of failures within a certain time frame.
Even with a gentle password spray, locking out accounts is a real danger.  Online password attacks are hard!


Applicability/Purpose of Malicious .dll Injected Into Browsers

Banking malware like Zeus does something called WebInjects, basically it modifies webpages once they've been decrypted by the browser but before they've been displayed to the user. This functionality can be used to gain access to information the user wouldn't usually give, such as a mothers maiden name or pin.

Source.


Suppose Victim A has your standard off-the-shelf Linksys wireless router which, by default, doesn't have encryption enabled on the wireless network which it broadcasts. Suppose Victim A never changed the default administration password either to gain access into the router's web interface to change settings (usually admin, admin).

These two situations are extremely common. All that Attacker A needs to do is setup a rogue DNS and web server on his laptop that has been connected to Victim A's wireless network, add forwarder addresses into his rogue DNS server (such as Google's public DNS of 8.8.8.8 and 8.8.4.4) so that all other domains Victim A tries to visit are still resolvable to their corresponding public IP address, then add a forward lookup zone for fb.com and facebook.com. Each of these 2 zones will need an A record for the root domain and an A record for www both of which point to Attacker A's local IP address of 192.168.1.1. Attacker A then logs in to the router's web interface (the default gateway address - usually 192.168.1.1 for Linksys). From there, Attacker A changes the ISP DNS settings on the WAN interface from the settings obtained via DHCP from the ISP to his laptop's local LAN address (say for example 192.168.1.101).

Now, on Attacker A's local web server, he takes Facebook's CSS stylesheets and login form with wget or any other website mirror tool, then injects some PHP into the downloaded page that saves a text file to his local web server's root directory that records any username and password submitted via the form. Bear in mind that this form looks exactly like Facebook's login form. From there, the attacker forwards this information to the real Facebook site and logs the user in so the user never even knows what happened.

When Victim A visits fb.com, facebook.com, www.fb.com, or www.facebook.com, the IP address with resolve as Attacker A's laptop LAN address of 192.168.1.101 given Victim A's DNS cache has been cleared after a period of time.

As mentioned, the only downside is that if Victim A has https://facebook.com bookmarked, the process will look extremely (ph)ishy as Victim A will get an invalid certificate warning. Also keep in mind that the attacker doesn't have to stick around for this entire process if he sets up a rogue DNS and web server on a public IP, forwards ports 53 and 80 on his firewall, and sets Victim A's router DNS address to Attacker A's public IP.


How difficult it was to crack Navajo's language during WW2?

Good question.

I'm a Native American, and this is pretty well-known to us. I also have experience with Chinese language and  dialects. I'll explain why I'm mentioning the Chinese part later.

This is a very good example of security through obscurity. It works until it's figured out. However, there are so few Navajo speakers compared to English speakers, that it would've been incredibly difficult to find native speakers to learn from at the time. How would they know it's the Navajo language to begin with? It sounded alien to them.

While the code may have been simple, it's hard to find people to teach you that code. During WW2, Japanese in America were rounded up and placed in internment camps. Anyone caught sympathizing with them may have been likewise punished. The chances of finding a Navajo turncoat were extremely low.

Why is Encryption stronger than Languages and Dialects?

Regarding encryption, other people such as Thomas Pornin can explain this better than me, but I'll try to show you similarities:

Encryption is like a language. It's sort of like a conversion of one word (or character) to another set of highly different characters. With proper encryption, you can't convert A -> Z then Z -> A unless you have the key. With languages, you can compare words with similar meanings in other languages, and translate accordingly. With languages, your key is knowing the languages.

With proper encryption, you cannot do this. You cannot put properly-encrypted text into a decryption routine and get the results back. Not without the key. You need the key to decrypt it. With a hash, you can never get the message back, only verify whether or not it's genuine, but those can be vulnerable to collision attacks.

Here are some examples:

Pretend this is Encryption. The "key" to decrypting the
hidden message is to understand both languages. There is
a second hidden message which requires deeper understanding.

[English]        [Chinese]
Hello       ->   你好
Alpaca      ->   草泥马

In the case of a hash (one-way), it could act like this:

[English]
Bring potter to Naria. The Death Star is ready for our war against the Time Lords.

[bcrypt]
$2a$04$38oxoVSWS9A97nkHYvxyD.FoLh7wxnHFTI2bOvg8XKZ/hA29BPEgS

With a hash, you would have to verify the contents against the message to see if they match. This is not really a method of encryption because you can't return the original message. You may eventually cause collisions as well.

In the case of AES 256 bit (two-way):

[English with key]
Find Potter and bring him to Narnia. The Death Star is ready for our war against the Time Lords.

[AES 256 encryption result]
Uz+07JfiUU8MwjJVCCefLpH8hFlP2mrjMbO4ArP7IbYVbpDFulUNf6GKDYw9fELI0oeni1sdD81E191BownSDPHvAnQ6TJTB63lYEodUj+ZxXVEvSetL+ZwXEgI9zS/R

How are you going to crack these? The same way as languages, actually. The difference is it's much, much harder to crack real encryption. Firstly, mapping a language and creating a translator is much, much easier than mapping an encryption database.

With one-way hashing, you would have to match every single combination of letters for every single encrypted character, to "crack" it, but that isn't going to return the message to you: it's only going to verify that the hash matches the message. With many hashing algorithms, collisions become a problem after a while.
With two-way encryption, you can get the original message back provided you have the key. Kind of like languages. Larger keys will very likely prevent brute force attacks, as with current technology, it would take longer than the estimated life of the universe to crack them. With languages, the "key" is understanding both languages.

This is why the Navajo "code" was cryptographically, "very simple" in comparison. The security through obscurity of the times made it very difficult to crack, but it would be easily very crackable today with current machines.
Having obscure dialects or languages can add an additional layer of "encryption," (note that the quotes indicate it's not really encryption) but, again, this is security through obscurity, and shouldn't be relied on by itself. In the case of encryption, these algorithms have been tested to be secure by well-educated researchers for a long time. Languages on the other hand, are much easier to learn.

Almost any idiot can learn a language. I'm living proof. Well-educated cryptographers and mathematicians can't crack many strong forms of encryption. What hope does the average layperson have?

Language and Dialect Usefulness

Regarding obscure dialects mentioned in #2, you can still see such things today. In fact, this isn't the only example of the Japanese getting owned by security through obscurity.

For example, the Chinese military relies on another layer of "encryption" (mind the quotes) -- which is really just security through obscurity -- with their dialects. During the last war with China, Japan wasn't able to "crack" the Wenzhou dialect because they didn't understand the implementation, and it was used against them.

Side note: considerable effort has been made by organizations such as Phonemica to demask obscure Chinese dialects.

Part of the problem with relying on dialects and languages today is that hacks are everywhere, so chances are high that someone will find your teaching manuals. Computers are at a good point where demasking a language or dialect could be automated in a very short time. On the other hand, real encryption is nigh unbreakable.

Once someone quickly learns your language or dialect, your security through obscurity would disappear very rapidly. This was used for thousands of years, but in modern times, it's not going to be that effective.

Is Security Through Obscurity Completely Invalid?

Despite what I've said, this does add another layer of obfuscation that is technically difficult to break. Even if your encrypted messages are broken, your attacker would still have to spend considerable time mapping it out. While it's child's played compared to proper encryption, security through obscurity does have it's uses, but you shouldn't rely on it entirely anymore.


Are there any logic-bombs that execute when the file is deleted?

If the machine is already infected, it is very difficult to know what is going on with it. You can never trust it anymore.

The malware itself could be sitting in the memory and watching its files. It's certainly plausible that a malware would do that, specifically so it can regenerate the deleted files. Remember those autorun malware? Whenever you deleted them from your disks they magically appeared again? Yup, it's pretty much like that.

The only way to clean your machine and be sure is to "nuke it from orbit".


Fraud Mitigation - Card Present Transactions

The industry's answer to this is Chip-and-PIN (as it's known in the UK), where the card holder must enter their personal identification number into the card terminal for every card-present transaction. It has reduced card-present fraud by around 80%. Unfortunately, it has not yet seen widespread deployment in the US, which is causing problems for US card holders trying to use their cards in Europe.


When MBR pirates grin as an indication of absolute pleasure!

A totally different angle on this would be to step back and consider your analysis.

You have a hypothesis that your machine is infected with malware.
You are collecting evidence through your attempt to build the machine into a dual boot configuration.

To determine if it is true that you have malware, you'll need to come up with a test of this hypothesis.  The test might be to demonstrate well documented behaviour which cannot be explained by experts on the OS, or well documented behaviour which cannot be reproduced.  I personally document this stuff with pen, paper and a camera.

You performed some installations and have observed unusual results, but your observations aren't well documented (at least here).

"Windows OS" - What version of Windows?
"A lot of unknown executables" - Do you have a list?
"Local System is replaced by either SYSTEM and/or SERVICE and I can no longer find Local System when trying to restore the defaults"  - where? how did you check?
"When trying to install antivirus software I experience some delays, and only the firewall is able to block part of the unusual network activity" - what unusual traffic did you detect?  How long are the delays?  when do they occur?
"I always seemed to get stuck to some point where the ugly malware rootkit something showed up and started doing its business as usual" - When do you get stuck?  What prevents you from continuing?

Having precise information about any one of these unusual behaviours could help.  There may be a non-malware explanation for the problems, or you may document behaviour unique to a very specific bit of malware.

Regarding your clock:  Setting the clock back a few hours in the BIOS sounds like normal multiboot behaviour.  Some OSes store the time zone as UTC, some store it as local time.  This is usually only noticable in a dual boot configuration  See further: https://superuser.com/questions/185773/does-windows-7-support-utc-as-bios-time

You can test the theory by booting to one os, checking the time, shutting down, checking the time in the BIOS, then repeating for the other OS.   If you can resolve the issue or influence the hours by changing the way the OS stores the time or even the time zone in the OS, then you have pretty good evidence that you've identified the cause.


Help in understanding an application's crash - exploitable?

I'll assume that the question has two parts: "Is this exploitable?  How can I confirm that this is is?"
It probably is.  You're probably on the right path with the heap spray.  Have you tried disabling ASLR?  That will help clear things up.
Here is some feedback from another person:

This bug is not replicable in newer versions. But he could probably perform a heap spray. He is reporting that gdb is reporting a different address every time this is probably* due to ASLR he should turn that off and back on to make sure. He can step through the program by setting some very breakpoints with gdb and determining the context of the crash.
But idk why he isn't trying out the latest version instead of the oldstable release. But I have mad respect for his/her vigor.


Securely storing an encryption key on AWS

It depends on what you mean by "storing", as well as "server".

I'm going to assume for sake of answering that there are two "servers" in use now, both on the AWS cloud:

MySQL server.

Application server (which currently has the code with your cryptography key in it).

The MySQL server has no reason to have the key, ever.

The Application server I assume has to work with the decrypted data.

IF the application server is doing the decrypting itself, it WILL have the key in memory.

You CANNOT know whether that memory was ever saved to disk by AWS, unless you inspect the hardware.

IF the application server does not need to do the decryption itself, then it is possible to have a service that takes the MySQL data and decrypts it, sending the data back to the Application server by some public/private key encryption you're satisfied with.

As always, if the key is on AWS, any AWS employee with sufficient access chooses to, as well as anyone else with sufficient access (vendors, Dell after the container full of hardware is shipped back once it's suffered too many failures, etc. etc. etc.).


Securing a simple webservice against brute-force with mod-security

There are rate-limiting rule set in ModSecurity CRS that does not directly correlate whether the authentication attempt was successful or not. Following is one of the Rule

SecRule IP:BRUTE_FORCE_COUNTER "@gt %{tx.brute_force_counter_threshold}"
"phase:5,id:'981042',t:none,nolog,pass,t:none,
setvar:ip.brute_force_burst_counter=+1,
expirevar:ip.brute_force_burst_counter=%{tx.brute_force_burst_time_slice},
setvar:!ip.brute_force_counter"

In the above rule we are maintaining a BRUTE_FORCE_COUNTER against some IP which is maintained every IP you can also maintained it against Session. Then we are maintaining a threshold that is number of legal attempts maintained in brute_force_counter_threshold. For every transaction we are increasing counter that is ip.brute_force_burst_counter=+1. After tx.brute_force_burst_time_slice that is time interval after which we refresh the counter


An attacker can still use the full range of attacks on the webserver: everything from password guessing to code injection to buffer overflows to path traversal to who-knows-what.  The only thing closing non-HTTP ports does is prevent the attacker from going after other programs that might be listening for incoming traffic (eg. a mailserver).


First: no password storage.

Storing passwords is wrong. Clear-text or encrypted, symmetric or asymmetric encryption, it does not matter. If the password can be reverted, it will be reverted.

You must store the password on a secure hashed form. Use bcrypt with a sane amount of rounds. Too much rounds (100,000) will use too much resources, too few (100) will make a dictionary attack or bruteforce easier.

Salting and hashing plus password reset is not a complex solution. Is simpler than to deploy a public key to the client and properly protect the private key.

And don't recover passwords. Generate new ones. It's not hard. Just make sure only the owner of the forgotten password can reset the password. Sending a link to the user's email, or a confirmation code to their phones. And don't modify the password until the user clicks the link or access the password reset service with the correct username and reset code.


Authentication methods

Are you only authenticating or also other stuff? You might also need smartcards.
Are you sure you only need SMS or do you also need to choose from a vast variety of tokens?

Token

You might want to choose a solution, which is not provided by a token vendor. The thing behind this is: You can keep the software system but easily mix and switch tokens (no vendor lock).
In theory you could do this with all OATH tokens... But you know theory and real life.

Supported environment

Where to install the authentication system?
The other question is, what are the applications or operating systems where you want to authenticate.
Easy API?
Credential Provider?
PAM module?

Supported VMs

No solution should be restricted in this way, that it can not be virtualized!

Out of band delivery

You might think this is cute at the moment. But you may realize in a year, that it is total crap and unsecure. You may also need to extend the usage scenarios. So do not only look for out of band but also look for a system with maximum token support and extensibality.

Flexibility & Usability

API API API.
Can it be easily automated.
E.g. Can it be integrated into your existing customer portal?
Do you get the Source Code? I.e. can you ask s.o. to enhance it more quickly than the vendor would respond to a feature request?
Can you still use it, when the successful vendor is merged with a bigger shark and the old product is ceased end of life?
Especially in the IT Security we saw this often during the last years!


What are the requirements for a random number generator to a be safe to use in cryptography?

I've written elsewhere about how we vet the security of a cryptographic primitive -- everything I wrote there applies equally to vetting the security of a cryptographically secure PRNG.

The difference between secure and non-secure PRNGs is that the secure ones are, well, secure.  You could start by reading up on the definition of security for a cryptographic-strength PRNG.  Starting with a non-secure PRNG and then trying to add extra complexity is not likely to be an effective way to end up with a secure PRNG.

The problem with using a non-cryptographic PRNG for cryptography is that you end up with with a system that is insecure.  See, e.g., the example of early implementations of SSL in Netscape Navigator, which turned out to be breakable because they used a non-cryptographic PRNG in a place where they needed a cryptographic-strength PRNG.

In the future, I suggest asking these questions on Crypto.SE, and splitting them up into multiple parts.  Or, better yet, take a look at a good cryptography textbook -- all of this should be covered there.


GRE DDOS -- Wouldn't the firewall block it?

Small amounts of unwanted traffic are easy to filter with a firewall as long as it's distinguisable from wanted traffic, which would be the case here with GRE.

The point you're missing is that the victim is receiving much more traffic than it can handle. So much more that all uplinks are saturated, so valid traffic isn't coming through to the destination anymore. Filtering at the end point is useless then, so you need other, complexer strategies like scrubbing or upstream filtering to deal with these kinds of attacks.


What security measures to have before openly allowing security researchers to hack your site

You should keep in mind sites like Google, Yahoo, Amazon have a couple (of thousand) of servers. They can afford to "open the doors" to everybody because, as M15K pointed, their resources are not limited.

There are a couple of reasons they might do be "open":
 1. You can gather performance statistics.
 2. You can test the system for stability (if server X goes down, server Y has to take over, etc)
 3. Probably many more reasons I can't think of.

In small/medium/large companies you usually end up using Linux/Unix server, Apache, Nginx, LigHTTP, Jetty, MySQL, PostgreSQL, Oracle and etc. Sites like Google(giant) create their own platform and their own software solutions - web servers, databases, proxy forwarders and etc. So leaving "the door open" for the public actually helps them to constantly improve their security and platforms because every "hacker" in the world will try bringing them down. A few of them will succeed and usually they end up working for the company or receive a satisfying number in their bank accounts :)

In my opinion it's not safe for you to "open" everything if the company you're working for is not creating most of the software solutions from scratch (web servers, databases and whatever else your company needs). Even then it's a bit risky especially if you're managing sensitive data.

i.e. could publishing such a statement put your site at more risk than leaving it out?
It doesn't matter if you say "We'll not sue you if you tell us where the breach is".
If somebody wants to hack you - he'll try doing it whether the statement is there or not. But if it's there it may sound more like you're inviting them in. So probably you'll get more hackers trying to hack your server.

However, what measures should a site already have in place before embarking on such seemingly risky endeavor?
You will need to figure out a logging mechanism, or monitor the actions that are being made on the site and server. Also a full backup of the site/server is a must.

Generally I wouldn't recommend leaving the server "open" especially if it handles sensitive information like credit cards, payments, medical information for patients and etc. It's better for you to hire a team of hackers with a proper contract. Otherwise you're risking all that information going in public.

I can't go in more details as this topic is HUGE and there are many things you need to consider before going "public":

Do you have the money to do that?
Do you have the resources? (servers, security teams and etc)
How far can you limit the damages a hacker can make to your system? I.E. If a hacker  hacks into your server what access will he have ? Will he be able to connect to your database and retrieve/store/update data? Is your data encrypted ? Will he be able to decrypt it? (and so on)
Can your security team find how a hacker exploited your system?
Does your security team have the skills to fix problems that may occur ?
Probably many more questions that you need to ask and answer before you decide.


Is bruteforcing the last character of a salt a good idea?

Assuming that you're using per-user salts (i.e. a different salt for each user account), rainbow tables are already an impractical means of attacking the hashed passwords (rainbow tables are typically used where there is either no salt or a salt which is common to all accounts and preferably known to the attacker ahead of time).

Where you're using a password hashing scheme such as bcrypt, if you're looking to make this "harder" for an attacker it's best to use the mechanisms provided by the scheme (e.g. the work factor) rather than inveting your own.


Is letting just anybody see the appearance/html/javascript of your admin pages a security risk?

I wouldn't worry about it.  Imagine it like this: if you use, say, django.contrib.admin, everyone knows what the admin pages look like.  Is that a security risk?  Not if requests are being properly authenticated and authorized.

You might want to take care that the pages themselves do not expose information you'd rather keep secret or would be useful in social engineering, such as "to reset a user's password, call the internal help desk at 212-555-4240."


Only set up noreferer if you are privacy-paranoid. noopener otherwise. At least one of these two must be present on links pointing to external websites in a new browsing context (there is a target value). Add nofollow for unrelated (ad partners) websites.

noreferrer includes the behavior of noopener, which is the most important one from a security point of view (see this for an example of attack). So noreferrer noopener = noreferrer.

nofollow indicates that you don't endose any responsibility for this link so it won't change anything for security (Search engine might still follow this link)

Don't do complex things with iframe for such a simple result as opening a link (you will break native security in browsers).


For what do I hash user passwords with PDKDF2 when the user data is stored in the same database?

An attacker might not have to gain access to your database to obtain the passwords of your users.

By design, data stored in a database are segregated by tables. Information like usernames and passwords should be in a different table from the user details like name and such. This is basic database schema design.

If an attacker compromises your application using techniques like SQL injections, they might be able to access only the table containing the passwords.

Even assuming the attacker manages to gain access to your entire database, there are other factors to consider. User information is not the only important thing in your application. If the attacker changes the information in the database directly, his actions would most likely be logged. This makes it relatively easy to find and fix any unwanted modifications.

However, if the attacker logs into a user account through the login page of your application, it would be difficult to differentiate what is intended and unintended access. He could cause a lot of potential damage.

In addition, many users use the same username/password combinations across multiple sites. If an attacker compromises the account information on your site, he could potentially access all the other online accounts of the user. This is bad.

Always hash your passwords.


GPG/GnuPG secret key passphrase recovery and/or .gnupg/private-keys-v1.d/ file format

I'm taking a guess at these, but I have no easy way to test if these are actually possible.

Easiest: Nasty and crackgpg have been designed for this purpose. If one of them has been updated to support this new format, try it.

Harder: The file format is documented in gnupg/agent/keyformat.txt. Can you get something like john to try your wordlist until it gets a ( as the first character?


Use another ssl certificate even if server has other certificates

First, SSL / TLS is quite an advanced setup. you will need to research how it works and test it on another machine before even attempting to do it on a production machine.

If you have a modern setup, (e.a. you have an SNI aware webserver, and clients.)
you can setup multiple TLs certificates, see the NGINX documentations regarding virtual hosts and multiple SSL.

To test with Ceritficates you id not buy, but only use for Testing / Development (ea. NOT PRODUCTION) you can use mkcert or xca.

the last thing I would recommand after you tried your setup on the production server, is to use a service like ssllabs to validate your setup. (do it for ALL domains with TLS in your server)

as a footnote to get a good cipher suite list, try cipherli.st


Does a password manager's master password significantly improve security?

All depends on what threats you consider. You are right, if your system is deadly compromised with keyloggers everywhere, there is little that can be done. But what if the attacker can just take a copy of a file and if that file is the password vault?

The common usage of a password manager like Keypass, is the assumption that there is a hierarchy in data sensitivity:

not so sensitive data can live in unencrypted files on the disk
highly sensitive data (passwords to bank accounts, PIN code of your credit card, etc.) should be protected with a master password in case of data theft.

If your data does not respect that hierarchy, it is possible that the security of the password vault is not worth a complex master password. But that means that you use Keypass only for its ability to store passwords and no longer for its ability to protect passwords. In that case, you could as well store passwords directly in your browser...


How does SFTP function without a manually generated public/private key pair

Short answer: there is necessarily a public/private key pair on the server. There may be a public/private key pair on the client, but the server may elect to authenticate clients with passwords instead,

SSH is a generic tunnel mechanism, in which some "application data" is transferred. One such application is the "remote shell" which is used to obtain an open "terminal" on a server, in which terminal applications can be run. Another, distinct application is the file transfer protocol known as SFTP. From the SSH point of view, which application is used is irrelevant. This means that any authentication concept applies equally to SSH (the "remote shell" part) and SFTP.

The server MUST have a public/private key pair. That key is used for the tunnel part, so a server will use the same key pair for all applicative protocols. Most Unix-like operating systems (e.g. Linux) create a SSH key pair when first installed, and will use it thereafter. This means that you don't have to "create a key" when you configure your SSH server to also be used as SFTP: the server already has a key.

A client may have a public/private key pair if it wishes to be authenticated based on that key; this is all about client authentication, i.e. about how the server will make sure that it is talking to the right client. Password-based authentication and key-based authentication are the two most common methods (some servers are configured to require both). By definition, only the key-based authentication requires that the client stores and uses a key pair of its own.


Any flaws in this security model for a REST web service?

I dont see any flaws, but I do think you're overdoing it. It seems to me - I might be missing something - that you use a token because you think you should, not because there is a legitimate reason.

The best approach would be to first identify your (security) requirements and then look for the solutions.

One of the things you should think about with stateless API's is replay attacks. THe way you describe it, your protocol sounds like vulnerable to a replay attack. Moreover, it can be abused for CSRF since there is no randomness in each request. I'm not sure if this is something the REST API can fix, because it is an inherent webapp problem, but it's worth thinking about it.

Bottom line, nobody can assess if you're security is alright if you dont have security requirements (and a threat landscape).


Laptops SSD: Hardware Encryption plus DM-Crypt/Luks - Security and Performance

Using only hardware encryption means you have to trust the SSD in addition to trusting the OS and CPU/RAM. With LUKS, you only need to trust the OS and CPU/RAM.

In practice, either one should do the job. But I'd trust LUKS slightly more because it's open source.  Hardware encryption can be convenient though.

If you are really paranoid, you want to use both to hedge your bet such that flaws in either would not compromise your security. As far as I can tell, there's no reduction in security by using both at the same time, a they're independent from each other. It might complicate data recovery if you ever need to do it.

  Does the hardware-encryption support (in the SSD) at all speed up software encryption in linux?

No.


You need to URL-encode SEARCHED_QUERY_HERE, otherwise if a user searches for &body=something, the body of the e-mail message will be set to something. Also, if you don't URL-encode it, if the user searches for a literal %20 (or similar) it will appear as a space in the message instead.
This is not a security risk, though.
The other, obvious risk is that if you don't properly HTML-encode the SEARCHED_QUERY_HERE, it will lead to XSS. But it appears you're already doing so, so you're covered.
Some programming languages, such as PHP, require you to explicitly specify that quotes must be encoded as well, so make sure you pass the correct arguments to your HTML-encoding function.
Example (PHP)

echo 'Link';


Is it possible to analyze real Single Sign-On (SSO) messages via network sniffing?

There are two types of data in an SSO system: data an end user can see and data that is hidden from the end user.  If the system is designed properly, there is no third category (i.e. there is no data is hidden but obtainable via sniffing).

There are many SSO systems where 100% of the data transfer is done right before your eyes, in the browser.  If you have Chrome you can hit F12 and see all of the traffic.  You don't have to sniff it or decrypt it because you are the proper user and your browser has the cryptographic session key.  With this method, you can see often SAML requests, responses, and assertions passing right through your browser via scripted posts and redirects.

But in some systems there are data that are hidden, via two means.  (1) The data still flow through your browser, but are encrypted (e.g. a session cookie containing an encrypted bearer token), and (2) data that flow through a back channel (e.g. if a private VPN is established between the identity server and the application server).  In the former case, you will not be able to access the data unless their crypto is broken.  In the latter case your browser may be using tokens that are meaningless to you because they are pointers into a data store that you can't see.

In all cases, sniffing network traffic won't get you anything that you can't get by easier means.


In TLS 1.3 handshake, can an internal error at the client be interpreted as a decrypt error at the server?

You are assuming that some error can occur which makes it impossible for the client to compute the keys correctly. Assuming that client and server have completed the handshake so far in a correct way, so that the input data for computation of the keys are available at the client and they are correct. Also, assuming that there are no implementation errors. In this case it is very unlikely that some error can happen during computation of the keys at all, i.e. probably only some out of memory condition or some hardware related problems. It might even be that the client is unable to send a message at all to the server in such a situation. I think it is perfectly ok if in this rare case the server cannot distinguish between an "internal error" message from the client and a corrupted message from the client or a connection close with no message at all since the amount of usable information is about the same: something unspecified went wrong.

Apart from that, the alerts sent to the peer do not contain much useful information in the first place. Since there is no real error message but only a single error number it can only point at the direction of the possible cause of an error but not describe it in detail. And when looking at how this alert protocol was used in TLS 1.2 and lower by actual implementations, the chance is high that it will be similar mostly useless in TLS 1.3: there are major implementations which just close the connection on error instead of sending an alert back. Other implementations just send a generic handshake_failure in most cases even though there are more exact alert types available for the particular error.


Deploying internally is easy. The hard part is getting all the procedures right so that it is convincingly uneasy to obtain a fake certificate. This is the condition for signatures: a signature has any value only inasmuch as people believe in it.

Of course, if your signatures are not meant to have legal value, then things are a lot simpler. But then, why would you want to sign things ? A signature is useful only through its binding property: he who signed can be held responsible for what which was signed. The whole point of a signature is to serve as a weapon against the signer. From which we can draw two conclusions:

Nobody in his right frame of mind wants to sign things. You want other people to sign things; you accept to sign things yourself only because you are pressured to do so in a specific context.
A proof is a legal weapon. If you do not want "legal value" for your signatures, then you have made them a lot less frightening, and thus a lot less useful as well.

Let's explain things with an analogy: suppose that you have a warehouse with valuable goods in it. You fear that thieves may break into it, so you want to hire armed guards. But it takes some precautions, because you do not necessarily want to give a loaded pistol to just any guy that looked good during the hiring interview; you will want some medical certificate that says that the guy is not mad, and some legal certificate that says that he is not wanted for some crime, or anything like that. A much less risky solution is to equip the guards with water pistols -- but then, thieves are unlikely to be much deterred by the prospect of being merely soaked.

Running a CA is 5% technology, 95% procedures (access control, audit, logs,...). The 95% are what makes running a CA expensive and complicated. You have to understand all that is going on (including dreary details on certificate formats such as revocation and renewals). If you do not accept to do that part of the job, then things can be very simple (a couple of scripts around OpenSSL), but then, you no longer have actual security to your signatures. You have merely sprinkled crypto all over the place, giving a feeling of security.


I'm far from being a PHP expert, so my comments are more general rather than specific.

Probably not entirely, but it depends. I don't think that any whitelist/blacklist approach can ever be 100% accurate. There will always be a case of false positives or false negatives. So you're always balancing between hits (of a script being able to still penetrate through your defences) and misses (i.e. successfully blocking the script, but in such a way that doesn't allow you further analysis). PHP must have thousands of different calls and permutations, so building a waterproof list is very difficult. That said, the list on a very quick glance looks ok as a starting point. Again, my php experience is limited.
I'm not sure what you meant when you said "to be made part of the web app", but I would rather strongly advise against embedding this with anything that is even remotely connected or in proximity to real data or any real production application. If this is a honeypot, it should probably be kept in as much isolation as possible. You should consider things like:

Running this on a dedicated hardware machine which gets regularly 'refreshed' (re-imaged, built from scratch)
Don't let it connect to anything other than the outside world
Don't store any sensitive (or even not so sensitive) data on it
Log all access and use an external firewall with verbose logging
Use internal OS system logging
Monitor anything even remotely strange on any of your logs
Consider throttling the speed of the external connection

If the system is isolated well enough, then the main remaining risk besides to itself, is to other systems. Assuming the attackers went through your php protection layer successfully, your honeypot can be used to launch external attacks onto other systems - spam, denial of service, act as part of a botnet etc. This is why keeping it in isolation, keeping a close eye on it, as well as trashing and starting from scratch is a good idea.
Unfortunately I cannot answer that more than I already covered on 1.
See 2.


Use $( )

The $( ) construct is equivalent to the backticks, executing the inner command:

$ python -c 'import os; import sys; os.system("ping " + sys.argv[1])' '$(cat /etc/passwd > /dev/stderr)'
root:x:0:0:root:/root:/bin/bash
...


Prevent finding key in C++ application binary

Basically, you can't.

What you look for is DRM by any other name, and history has shown time and time again that DRM isn't effective. Any skilled attacker in possession of the binary is therefore also in possession of the key, regardless of how well you hide it.

Even if you were to store the key on your server and load it dynamically from the internet, the attacker can either intercept it as it is being transmitted, or dump the key from memory once it has been loaded.

In fact, the attacker doesn't need the key at all, since once it is being used to decrypt some data, the attacker can just dump the decrypted data from memory, once decryption has finished.


How can I make my java application trust connection using a domain (self) signed certificate?

The comment from Steffen above should be the listed answer, so i'm adding it here:

  Java has its own key store and does not use the central windows trust store. Thus you need to add the CA certificate to the java key store. See for example Adding a Certificate to the Java CA Certificates Store. Apart from that you cannot revoke a CA, only distrust it in which case it needs to be removed from all trust stores.


Can an AES-128 key be reversed if the attacker can control plain text and capture cypher text and IV?

Knowledge of the plain-text and it's direct encrypted cipher-text does not offer the attacker any method of reversing the master key other than brute force, which they will already have at their disposal by just knowing the cipher-text. Therefore, your system should still be secure.

To find a lot more detail and justification to this answer, I would recommend this post:
How less secure is an encryption if we know something about the original data?

Hope it helps!


How dangerous is negligent RFID / NFC card use?

NFC readers are a great piece of technology. Sadly, it has been poorly executed and has many security concerns. Most the security concerns have been "debunked" by credit card companies whom continue to push the technology. Theft using NFC on various RFID systems is open to compromise, but really all depends on how secure the user is with this information, The NFC must be passing active data to be hijacked or intercepted. So a malicious person cannot simply pass his or her phone passed your wallet and get information, unless there is an active data stream or connection to a reader. But there has also been workings to have more levels of authentication to ensure appropriate use.

Eavesdropping

Eavesdropping is when a criminal “listens in” on an NFC transaction. The criminal does not need to pick up every single signal to gather private information. Two methods can prevent eavesdropping. First there is the range of NFC itself. Since the devices must be fairly close to send signals, the criminal has a limited range to work in for intercepting signals. Then there are secure channels. When a secure channel is established, the information is encrypted and only an authorized device can decode it. NFC users should ensure the companies they do business with use secure channels.

Active Attacks

There are NFC attacks based on actively probing a card without the cardholder's knowledge, and this is done outside of the context of eavesdropping on or intercepting a legitimate transaction.  The idea is that you sit next to someone on the train, and a computer in your backpack attacks the victim's card while it's still in their wallet.  The first demonstration of this was on Mobil's SpeedPass, which was defeated this way long ago.  Charlie Miller recently presented on this at the 2012 Black Hat.

Data Corruption and Manipulation

Data corruption and manipulation occur when a criminal manipulates the data being sent to a reader or interferes with the data being sent so it is corrupted and useless when it arrives. To prevent this, secure channels should be used for communication. Some NFC devices “listen” for data corruption attacks and prevent them before they have a chance to get up and running.

Interception Attacks

Similar to data manipulation, interception attacks take this type of digital crime one step further. A person acts as a middleman between two NFC devices and receives and alters the information as it passes between them. This type of attack is difficult and less common. To prevent it, devices should be in an active-passive pairing. This means one device receives info and the other sends it instead of both devices receiving and passing information.

Theft

No amount of encryption can protect a consumer from a stolen phone. If a smartphone is stolen, the thief could theoretically wave the phone over a card reader at a store to make a purchase. To avoid this, smartphone owners should be diligent about keeping tight security on their phones. By installing a password or other type of lock that appears when the smartphone screen is turned on, a thief may not be able to figure out the password and thus cannot access sensitive information on the phone.

While it may seem like NFC would open up a world of new security risks, it may actually be safer than a credit card. If a user loses her credit card, a criminal can read the card and find out the owner’s information. If that same person loses her smartphone and has it password protected the criminal cannot access any private info. Through data encryption and secure channels, NFC technology can help consumers make purchases quickly while keeping their information safe at the safe time.

Slides: "Practical Experiences with NFC Security on mobile Phones"
Security in Near Field Communication
Security Risks of Near Field Communication
Blackhat study Exploring NFC attack surface


First you should ask your self: What advantage does a VPN provider have over providing your own with something like OpenVPN? If you are paranoid you could get a Virtual private Server(VPS) host.  Other than that I would make sure that the service was fast, cheap and wasn't in the news for a security breach.


A couple of questions about port scanning

1.) There are some variables at play here. Mainly you are both using different routers (with different configurations) and both using different ISPs. (with different security equipment and policies in effect) Your friend's router doesn't have to reply to anything...it depends on how he has it configured. There is no definite port or protocol that can always be used to determine the asset on the other end is "alive".

2.) It's common for ISP's to block incoming port 80 traffic. This prevents customers from hosting webservers on their personal accounts.

3.) Same as above. Firewalls/routers are stateful, (nowadays anyway) which means that the firewall/router will only respond to a request that was first initiated from inside the network. (unless configured otherwise) To muddy the waters a little bit more, when a NAT is involved (and it almost always is) there are source ports involved. There is a good explanation of source ports here: https://stackoverflow.com/questions/15708011/how-is-source-port-for-http-determined-is-there-ever-collision-in-nat


PGP: Including your public key as a recipient? Any less secure?

On the one hand, if someone compromises your private key, such person would then be able to read your past encrypted correspondence. If that's not an acceptable risk to you, then you shouldn't encrypt to self. On the other hand, more often than not, the person responding to you would leave your previous message body intact anyway (especially when top-posting), so an attacker would be able to piece together what you were talking about anyway.

I'd say the security gains of not encrypting to self are not worth the inconvenience of not being able to read your own sent mail.


For encrypted chat app, how can I store sent messages so that they are encrypted but still can be viewed by the sender?

Create a symmetric key, encrypt the symmetric key with receiver's key, encrypt every message with the symmetric key. On the sender side, store the symmetric key together with the message.

Or encrypt the message with the receiver's key, send it. Encrypt same message with sender's key and store it.


Windows Firewall allows the connection to more than one user who shares the same external IP address

Contrary to what you state in the comments, this is an xy-problem. An xy-problem is "how can I use x to do y" while not even considering whether x is an appropriate method to do y.
If you want to distinguish between clients behind a NAT (your y), an IP-based firewall (your x) is not the appropriate solution. Possible solutions are

use VPNs if you must (seems disproportionately heavy in this context)
authenticate the sessions and allow only authenticated sessions, for example via a proxy
separate the anticheat and game server on different (possibly virtual) machines
et cetera.

In short, the answer to your question is, that Windows "firewall" is an IP based filter and you cannot reliably distinguish between host behind a NAT router.


How is "something you have" typically defined for "two-factor" authentication?

I started to ask this question to get input before discovering the one. In light of a Magistrate Judge's recommended judgement on PATCO v. People's United (which implies a horrible theory regarding multifactor authentication), I define something you have as this:

What you have must only be compromised by an attacker having physical access to what you have. This excludes:

A password written on a piece of paper (once somebody sees it, they know it)
A cookie stored on your computer
"Security questions" (They are just another password)
Your PGP key kept on a thumb drive if you plug it into a machine that has network access

That said, I would consider a paper list of 100 passwords that have no relation and are each used only once would be considered something you have. A paper list of 100 passwords that might be asked for more than once would not qualify as an attacker would be able to pretend to have access to that credential by monitoring.

Something you have must be something whose integrity can be secured by physical control. Attacks on the other side of the channel such as stealing their authentication database or breaking a cryptographic protocol don't count. If it can be compromised without an attacker's physical interference (or breaking an encryption algorithm as they are integral to demonstrating possession remotely), it is not something you have. ATM cards are a bit fuzzy that way -- a compromised ATM could provide all the track data, though what we usually see are skimmers (physical access). RSA tokens are another that I would consider something you have.

I like smartcards best because placing them in a reader won't expose their secrets, nor would compromise of the authentication database.