How to use openssl ca with prime256v1? I am new to the encryption world, and reading about this, most websites say to use the prime256v1 for better performance and security.

After some days testing, finally I get my openssl CA structure working, almost steps come from this guide:

FreeBSD Certificate Authority

I did some changes, like search for OIDs (just adding same OIDs from permissions, example in CAs I have added 2.5.29.19, etc...)

Already have setup my CRL distribution points too, everything is working (at least seems to be working) nice.

The problem occurs if I change the final certificate structure from the guide, so for example, instead make a TLS Server Certificate using the following 3 steps from guide:

Generate PK

/usr/local/bin/openssl genpkey \
    -aes-256-cbc \
    -algorithm RSA \
    -pkeyopt 'rsa_keygen_bits:4096' \
    -out private/srv.example.org.key.enc \
    -pass file:private/srv.example.org.pwd

Generate Certificate Request

setenv SAN "DNS:srv.example.org"
/usr/local/bin/openssl req \
    -config etc/tls-server.conf \
    -new \
    -sha512 \
    -out certs/srv.example.org.csr \
    -key private/srv.example.org.key.enc \
    -subj /C=DE/ST=State/L=Locality/O=Example\ Corporation/OU=System\ Administration/CN=srv.example.org \
    -passin file:private/srv.example.org.pwd
unsetenv SAN

Sign the certificate

/usr/local/bin/openssl ca \
    -config etc/component-ca.conf \
    -batch \
    -md sha512 \
    -in certs/srv.example.org.csr \
    -out certs/srv.example.org.crt \
    -extensions server_ext \
    -startdate `date -j -u '+%Y%m01000000Z'` \
    -enddate `date -j -u -v+2y '+%Y%m01000000Z'` \
    -passin file:ca/component-ca/private/component-ca.pwd

For test an prime256v1, I have done:

Generate PK (testing prime256v1)

/usr/local/bin/openssl genpkey \
    ecparam \
    -name prime256v1 \
    -genkey \
    -param_enc explicit \
    -out private/srv.example.org.key \

Generate Certificate Request (testing prime256v1)

setenv SAN "DNS:srv.example.org"
/usr/local/bin/openssl req \
    -new \
    -sha512 \
    -config etc/tls-server.conf \
    -key private/srv.example.org.key.enc \
    -nodes \
    -out certs/srv.example.org.csr \
    -subj /C=DE/ST=State/L=Locality/O=Example\ Corporation/OU=System\ Administration/CN=srv.example.org \
unsetenv SAN

Sign the certificate (testing prime256v1)

/usr/local/bin/openssl ca \
    -config etc/component-ca.conf \
    -batch \
    -md sha512 \
    -in certs/srv.example.org.csr \
    -out certs/srv.example.org.crt \
    -extensions server_ext \
    -startdate `date -j -u '+%Y%m01000000Z'` \
    -enddate `date -j -u -v+2y '+%Y%m01000000Z'` \
    -passin file:ca/component-ca/private/component-ca.pwd

The certificate is signed without errors...

When I try to access my domain browsers block the access saying the error:

  No Cypher Overlap

My first guess is because the mix of encryption, then I have changed entire commands from the guide to make Root-CA, Network-CA, Component-CA all using secp521r1, since it seems to be a good security practice use highest encryption on top and low encryption (prime256v1) on bottom for make compatibility...

And then, same error occurs:

  No Cypher Overlap

So if I wish to use prime256v1 I need to make all structure with only it?
If tomorrow this process becomes weak, I need to remake the entire CA with new security encryption (eg, secp384r1)?

On Server side I have used the Mozilla SSL Configuration Generator to setup:

  SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1 SSL

  CipherSuite
  ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256

PS.: I have no plans to purchase an online SSL Validated Certificate, but I will love to have a working CA testing structure working for study.

Probably useless, but since this got necroed ...
I don't believe the Q is accurate, because
/usr/local/bin/openssl genpkey \
    ecparam \
    [anything]

is an error and cannot have worked. But if you actually did
/any/openssl ecparam -name prime256v1 -genkey -param_enc explicit -out keyfile

and used that key for a CSR and cert as described, you may have created an unusable cert.
When RFC 4492 (first) defined ECC options for TLS in 2006, it followed then-current X9.62 practice to allow both predefined (standardized) curves, also called 'named' and identified in TLS by registered numbers, and 'arbitrary explicit' curves (over prime or characteristic-two fields) that might be defined by users.
In practice people implemented only 'named' curves -- and often only a subset of them, such as the ones adopted/approved by NIST in FIPS 186-2 and especially the two selected by NSA's then-fashionable 'Suite B', which are called secp256r1 secp384r1 in SEC1 or P-256 P-384 in FIPS 186, and the first prime256v1 in X9.62. Almost nobody generated their own Weierstrass curves, and the few that did got them registered e.g. Brainpool RFC7027. (Note that the schemes for Bernstein et al's 25519 and 448 are not just different curves but different algorithms; they don't fit in the original 4492/X9.62 definition at all.)
Consistent with this OpenSSL didn't implement 'arbitrary' curves in TLS -- although it does implement ECC primitive operations using X9.62 formats. I don't know any other TLS implementation that does implement arbitrary curves for TLS, and the standards have moved away from it. For PKIX certificates (related to but distinct from TLS) RFC3279 in 2002 supported EC pubkeys using explicit parameters (in painful detail) or 'namedCurve', but RFC5480 in 2009 prohibits explicit (now 'specified') parameters and requires namedCurve only. Post-Q, RFC8422 in 2018 modifies RFC4492 (for TLS1.0-1.2) to reduce the list of named curves and remove (deprecate) the 'arbitrary' option; concurrently RFC8446 for TLS1.3 adopted the same reduced list of named curves, plus predefined/registered non-EC groups (called Finite Field groups) from RFC7919 in 2016, and no arbitrary groups ever.
Using -param_enc explicit discards the information that this key is on a standardized curve and makes it appear arbitrary. (edit) As a result OpenSSL for a long time did not treat it as matching a ClientHello offer to use P-256; it would match a client offer to use 'explicit_prime', but OpenSSL doesn't implement that, and I've not seen any (other) implementation that offers it anyway. Thus an OpenSSL-based server couldn't agree any ECC-based ciphersuite because the cert isn't suitable, nor any other authenticated ciphersuite because you haven't provided any other cert, and it can't agree a non-authenticated ciphersuite because those are disabled because they're insecure, so you get 'no common cipher' (or whatever other wording is used for alert 40). However, I didn't notice (or re-check) when I wrote this but OpenSSL 1.1.0l and 1.1.1d up (since 2 months earlier) recognize explicit parameters which are actually for a supported named curve, and convert them back to the named version, so this works. However, explicit still wastes space and violates 5480, and might or might not interoperate successfully, so I recommend against it.
TLDR: don't use -param_enc explicit


rancid like tool for config files I need to be able to watch directories on our servers, and track changes to files as part of our audit compliance.  I have adjusted auditd to watch the directories, and send all writes and attribute changes to syslog (which immediately forwards on to my splunk server)

this is helpful, it shows who changed a file, but does not actually show you what was changed.  If I do a "vi app.conf" and make a change, it will just show that I wrote the file.

I have looked briefly at both AIDE and etckeeper, but I need to track about 2 dozen servers, and that seems rather manual.

For my networking equipment, Rancid has been awesome, with its automatic emails of Diff's. (its actually saved our bacon more than once too)

Is there such a thing as a rancid like tool for linux to monitor directories remotely?

As you're using Splunk, check out FSChange. It's been deprecated in Splunk 5 (though it's still there), but it might do what you want.

An alternative to FSChange might be something like Samhain's file integrity monitoring, coupled with Splunk.


Which is the best antidote for DNS cache poisoning? I know some antidotes for DNS cache poisoning attacks, both simple as port randomisation, and more complex as DNSSEC. But, which is the more effective? Which solutions are really deployed in the nameservers today?

Thanks for answers.

But, which is the more effective?

They address slightly different issues:

Port randomization makes DNS spoofing harder because there is an additional unknown secret for the attacker (the port) which must match for the spoofed answer.
With DNSSec one can reliably detect if the answer was spoofed.

  Which solutions are really deployed in the nameservers today?

DNSSec everywhere could probably make port randomization obsolete, but currently we are far from a sufficient adoption. For the mean time we need port randomization. But this is not a server side solution, but instead must be done by the client (a DNS cache works as a client when asking another DNS server).


Was Meltdown/Spectre discovered in 1991 or 1995? Wikipedia mentions this paper without going into details: The Intel 80x86 Processor Architecture: Pitfalls for Secure Systems:

  As mentioned in the preceding scenario, caches
  present potential for covert timing channels. Even without MSRs for direct measurements of cache activity,
  cache hits and misses can be detected strictly
  from instruction timing, as described in Wray1991. To
  eliminate these flows, caches must be managed. This
  can reduce their efficiency considerably, depending on
  cache architecture, as it introduces otherwise unnecessary
  cache flush and invalidation activity.

Wray1991 is

  John C Wray: An analysis of Covert Timing Channels, Proceedings of the IEEE Computer Society Symposium on Research in Security and Privacy, Oakland, CA, pages 2-7, 1991.

That sounds pretty close to Meltdown/Spectre, doesn't it?

The Wray paper is about categorisation of covert channels, and from a rapid reading, it does reference an attack on a cache by two processes explicitly loading memory locations, but to be used as a timing mechanism.

The Sibert paper, in the section 3.10 merely identifies the covert channel, not the actual Meltdown flaw.

In conclusion, although it can sound like Meltdown/Spectre, these papers only identify the existence of the covert channel used in the recent exploits, and have not discovered the vulnerabilities themselves. These are the result of the use of this covert channel over the speculative execution mechanism of the processors.


Polymorphic Analysis I'm a beginner at malware analysis. For my research studies, I have to identify polymorphic malware based from experiments. I would like to know if there are any guides showing how to analyze the code (assembly language) of polymorphic malware using ollydbg (or other tools) to see where it started to mutate?

In the following articles, the decryption key of the decryption loop is mutated:

https://n1ps.wordpress.com/2008/09/14/w32virut-analysis/
https://n1ps.wordpress.com/2008/09/16/w32virut-analysis-part-2/

There's no universal guide to find all these kinds of mutations with OllyDbg or other tools but you could try to find Crypto code where there're lots of arithmetic/logic instructions as a tip to start your mutation digging journey.


Is it safe to send clear usernames/passwords on a https connection to authenticate users? I'm setting up a home HTTP server which can send and receive JSON data to/from different clients (Android and iPhone apps).

I'd like to allow access only to certain users and I'm considering using a simple username/password mechanism, as setting up client certificates seems a bit of an overkill for this small project.

Of course I can't send clear passwords from the client to the server on plain HTTP, otherwise anyone with wireshark/tcpdump installed could read it. So, I'm thinking about the following mechanism:

The HTTP server can be set up as HTTPS server
The server also has username/password database (passwords might be saved with bcrypt)
The client opens the HTTPS connection, it authenticates the server (so a server certificate is needed) and after exchanging the master key, the connection should be encrypted.
The client sends the username/password in clear to the server
The server runs bcrypt on the password and compares it with the one stored in the database

Is there any problem with this kind of configuration? The password should be safe since it's sent on an encrypted connection.

Yes, this is the standard practice.  Doing anything other than this offers minimal additional advantage, if any (and in some cases may harm the security).  As long as you verify a valid SSL connection to the correct server, then the password is protected on the wire and can only be read by the server.  You don't gain anything by disguising the password before sending it as the server can not trust the client.

The only way that the information could get lost anyway is if the SSL connection was compromised and if the SSL connection was somehow compromised, the "disguised" token would still be all that is needed to access the account, so it does no good to protect the password further.  (It does arguably provide a slight protection if they have used the same password on multiple accounts, but if they are doing that, they aren't particularly security conscious to begin with.)

As MyFreeWeb pointed out, there are also some elaborate systems that can use a challenge response to ensure that the password is held by the client, but these are really elaborate and not widely used at all.  They also still don't provide a whole lot of added advantage as they only protect the password from being compromised on an actively hacked server.


How can startup companies protect their code from any intentional leakage? So, how can new companies that have just started protect

their source code from leaking by their employees?

If it is a new company that means that the source code of the product is not so big and

complex yet in order to distribute developers to different parts and  limit their access.

Also, the employees need internet access for help during their work
(that means that they can just upload the source code anywhere they want).

Furthermore, I do not believe that NDAs (Non-disclosure agreements) can stop anyone.

Imagine the following scenario:
You have hired 10 developers, and after some time one of them

uploads all your source code using TOR to a remote server.

Result:
Your source code has been leaked, you can not find the culprit and you don't know who to sue.

There is no perfect technological solution, and there never can be.

Humans are the weakest part of security, (because they click on things they shouldn't and fall victim to social engineering traps), but they are also the strongest part of security.  They can identify when something "doesn't seem right".  They can look into and probe deeper to confirm or refute their suspicions.

Ideally, the people you hire should not want to steal your source code.  You should be treating them well so that they want the project to succeed as much as you do.

Ideally, you should know each of your developers well enough to know if they would do something like that.  Even if you blocked access to Tor, you can't prevent them from putting the code on a USB stick.  If you prevent that, you can't prevent them from printing it out and sending it through the mail, and so on.   You need to nurture a level of bidirectional trust, such that they know you're working in their best interests and you know that they're working in yours.


Does PKCS #7 (CMS) add assurance to an email if a CRL/OCSP response is included, then revoked? Suppose I issue a signing certificate in January, and have a daily CRL issued (expires in 1 day) to verify the validity of that signature.

Then sometime in July I need to revoke that certificate.

My goal is to not invalidate all prior emails signed with that key, but, rather give recipients some assurance that the key was valid and correct when they received the message. CMS/PKCS7 might do what I'm needing IF:

The sending client includes the revocation response in the message
The signing PKI infrastructure is correct and not flawed
The validator will see the SMIME signature, validate it, and also validate the signature as well.
Does this whole concept fall apart if when the certificate is expired/superseded and not lost due to theft/loss of integrity of the private key?

Given the inconsistent support for SMIME (e.g. gmail and all things Google) is there any software or technology that would validate in the way that solves my needs?

Is what I'm looking for viable, or am I using the wrong technology for the wrong purpose?

What you are looking for is theoretically viable, provided that you add the missing extra piece, i.e. some form of time stamping. However, behaviour of existing, deployed implementations is likely to be a problem.

The conceptual idea is that if you verify a signature at date T on some message, then, at a later date T', you can still remember that the signature was correct, and act on that belief -- even if the signature is no longer verifiable at date T', e.g. because the signer's certificate was revoked in the mean time.

In the case of revocation, each revocation information (be it in a CRL or an OCSP response) comes with a revocation date. The field is called revocationDate in a CRL and is defined in the following way:

The date on which the revocation occurred is specified.

So when a CRL says that a certificate was revoked on June 17th, at 14:10 +00:00, it also implicitly says that on June 15th, the certificate was not revoked. Therefore, if the recipient can somehow make sure that he received the email (and its signature) at a date prior to the revocation date, and that the stored email was not altered in any way, then the signature is still, conceptually, verifiable.

A serious hole in the theory above is that existing CA do not necessarily write revocation dates with all the needed accuracy. For instance, if you revoke twice the same certificate with Microsoft's PKI (Active Directory Certificate Services), then the revocation date will be the date of the second revocation, not the first. But if you manage certificates on smart cards with Microsoft's FIM CM product (Forefront Identity Management -- Certificate Management), then you will make such duplicate revocations.

In general, proofs of existence of some piece of data at a previous date rely on time stamps. For long-term archival of signed documents, still verifiable years after (not only after the signer's certificate has expired, but also after some of the intermediate CA certificate have also expired), you need to apply time stamps on a regular basis, like a layer of fresh paint. Some standards exist for that, but they are little more complex than simple CMS (CAdES builds on CMS, but with some rather hairy extra attributes). See this answer for some more discussion and pointers.


Is there any reason to not use my real name in my email address? Somewhat of a privacy/security question here. I'm looking to get away from Google services, especially email, and I'm wondering if there's a reason not to use my real name in the email address. The enemy I'm think of is intrusive government surveillance.

If I use an encrypted email service, just going by the handle any State actors won't necessarily know which address is mine, but then again then can just look at the emails coming in before they're
encrypted, so that argument doesn't work.
Practically any online service that has my email address is going to know my name, so there is really no privacy benefit there either.

Am I perchance missing something?

Many contact sites or services use email for communications. While it might not matter in most cases, having your real name as part of the email address may be concerning sometimes, such as:

an AIDS Clinic
an Abortion Provider
a Left/Right wing organization
a Car Salesman
Others

It may also lead to cyber stalking, as in people finding "John_Smith@whatever" and not differentiating.


How long should I wait before choosing a hash function? How long should I wait before using a newer (hopefully improved) hash function? For instance:

Is SHA-3 ready for use because of extra testing that went on during the NIST competition?

How long should I wait before using a newer (hopefully improved) hash function?

The better question to ask is: "How long should I wait before switching off my current hash". What are you on now? If your data is protected with MD5 or SHA1 then please switch. Please switch now. If you're already on something that's believed to be unbroken, then you have no reason to "upgrade".

The general rule with crypto is to assume everything will be broken eventually, so pick something that's not known to be broken at the time, and have a plan in place to switch your data over to a new algorithm in a hurry if an attack does get published.

At the time of writing, the following are all perfectly acceptable, not known to be broken, hash functions / key derivation functions:

BLAKE, SHA2, SHA3, ... , bcrypt, scrypt, PBKDF2, argon2, ...

Choose the one that best fits your application.

  Is SHA-3 ready for use because of extra testing that went on during the NIST competition?

If NIST has standardized it (which they have in FIPS-202), then it's ready for use!

As @RoryAlsop said, beware that if you need your data to be compatible with multiple pieces of software, then be aware of compatibility issues; just because SHA3's been standardized for two years, doesn't mean that it's been widely adopted.

One final note, reading between the lines, you seem to be implying that SHA3 is a "a newer (hopefully improved) hash function". I want to correct this.

While it is newer, it is not "better" than SHA2, in fact SHA3 offers exactly the same security levels as SHA2. NIST launched the SHA3 competition not because they wanted to "improve" on SHA2, but because they were uncomfortable with the "all your eggs in one basket" nature of only having one approved hash algorithm. That's not to say there's anything wrong with SHA2, but if something does come up, they want to have a migration path at the ready.

SHA3 for password hashing.

Bad idea. SHA3 is ideal for file hashing (because it's fast), but it would actually be considered a weakness to use it for password hashing (because it's fast).

See NIST SP-800-63b:

  Examples of suitable key derivation functions include Password-based Key Derivation Function 2 (PBKDF2) [SP 800-132] and Balloon [BALLOON]. A memory-hard function SHOULD be used because it increases the cost of an attack.

SHA3 is designed to be efficient, it is neither slow (time-hard) nor big (memory-hard).

PBKDF2 and Balloon are schemes that wrap around a standard hash function to make it time-hard / memory-hard, respectively. So if you only wanted to support one hashing primitive in, say, your embedded hardware device, you can wrap PBKDF2 / Balloon around SHA3 and still have FIPS-certified crypto, but please don't use naked SHA3 on passwords.


How to bruteforce smime.p7m key My information security teacher gave me homework - hack smime.p7m. He said that the key is simple and bruteforce will not take much time, but I can not find a utility to do this. Maybe you know these?

I would take a look at this tool (I haven't tried personally though):

https://github.com/SaschaWessel/rc2-40-cbc

  rc2-40-cbc
  A brute force tool for 40 Bit RC2 encrypted email messages.

  In S/MIME messages [1] the plaintext is encrypted with a symmetric key (e.g. 3DES, RC2) and this symmetric key is encrypted with an asymmetric public key (e.g. RSA). To decrypt the message, only the symmetric key is required and this key can be brute forced for small key sizes. This tool implements this for 40 Bit RC2 keys.

  [1] S/MIME Version 2 Message Specification: http://tools.ietf.org/html/rfc2311


Ethernet over power: security aspects Our company is moving to another facility which has no LAN cabling, therefore we are considering using ethernet over power.

We would like to avoid our data being transmitted out of this facility and also that only authorized people logically "join" the network.

Preventive Measure: How can I ensure the data transmission remains within the facility?
Control Measure: Which technology should I consider to avoid unauthorized people to join the network?

Good one.  Ethernet over power has distance constraints and in practice, I've seen the ethernet connection die after 20-30 meters due to the quality of the cabling in the building. In an older building where we were using ethernet over power - it died after 10 meters....

Also the devices work in pairs - so a person who wants to tap into your LAN would have to have a paired device just like yours.

These constraints would make it difficult for someone outside the building to tap in - especially since another building would be on a separate circuit.

And - it's easy enough to test.  Take an adapter outside the building and see if you can get Ethernet connectivity.

This may sound lame - but why not use secure WIFI?


PCI compliance dilemma I am looking for advice on PCI compliance. I am being told that I am not currently PCI compliant although I am not sure if this is accurate.

We outsource the payment management and card storage to a 3rd party service and only store the external ID and last 4 digits of the card.

I collect the CC data on the frontend and pass it to a Node application which sends it to our 3rd party service. This is required because the API key/secret should not be exposed to the client for obvious security reasons.

However I am being told that passing the data from one application to another is against compliance, now I am being asked to send the CCs directly from the browser which would mean each person using the app would have the API key/secret being sent to their local machine and if known someone could easily use this to access our payment instruments.

What do I do? Is it actually against compliance just to transmit the data from one service to another?

You’re right, that is a dilemma.  I’ll try to answer point-by-point.

  I collect the CC data on the frontend and pass it to a Node application which sends it to our 3rd party service. ... However I am being told that passing the data from one application to another is against compliance,

It’s not so much passing data that’s non-compliment (after all, you need to pass it to the 3rd party) as passing it through your server that’s the problem.  I like to describe PCI levels in terms of what would need to be compromised in order to steal card data. If the answer is “my webserver” or “my application”, they you’re under SAQ-D, the most onerous. If the answer is “my communication channels with a trusted third party”, then you are probably A or A-EP, like most ecommerce.

  This is required because the API key/secret should not be exposed to the client for obvious security reasons. ... from the browser which would mean each person using the app would have the API key/secret being sent to their local machine and if known someone could easily use this to access our payment instruments.

This isn’t as obvious as you’d think. What can someone actually do with these credentials?  If all they can be used for is to give you money, they’re not really that sensitive. If they can be used to refund it, they’re critically sensitive. If they can be used to retrieve information that isn’t the PAN, that’s important but not as bad.

This is a big reason why the API credentials are almost certainly not what you log into their portal with. You may also have a different set for non-payment operations.

In the end, you should talk to your payment provider. You’re not the first person to have these issues, and they may already have guidance on how to handle it.  (If you are the first... run!)

Many payment systems I’ve seen ask the server to make some kind of setup call, using secret credentials, which then returns a one-time-use value (url, transaction key, etc) to be delivered to the client. Others just restrict what you can do with those creds so they’re safe to expose to the user.

It’s also possible you’re using the wrong API/endpoint. You might be using one intended for in-person payments, and there’s a different one for ecommerce. I’ve seen that too (and made that mistake myself).


Crypto++ RSA - Encrypt and sign with the same key pair I have a program A which needs to send messages to several instances of program B (B1, B2, etc...). The messages must be encrypted, and also signed. Which means only Bn instances can decode, and they must be sure that the messages come from A.

Also, B1 should not be able to send messages to B2, etc. ...

Theoretically, it should be possible to use a single RSA key pair, with a key for A and a key for Bn. Once decoded by Bn, if the recovered message is validated (such as by a hash function), it must have been sent by A which did not disclose its key to anybody. In that case, both keys are private (which means they have to be exchanged in a secure channel)

Is this recommended or is there a strong argument in favor of having separate encryption and signing steps with independent key pairs?
Practically, in the Crypto++ library, the PrivateKey class also contains the public key. Is there a way to load a private key only?

I can answer your first question. It's not recommended to use the same RSA key pair for signing and encryption. The reason for that may be differences in expiration or key-escrow (e.g. sometimes organizations will want to back up your encryption key (confidentiality), but you do not want them to have your signing key(non-repudiation)). There's also a long shot possibility that if you blindly sign messages without checking or hashing the message a user can decrypt the message (signing applies the private key on a message). This is quite rare and would result from atypical application development that has bad design anyway.

Also, if you can manage one key, why not two?


Implications of the security model of HTTP cookies on HTTPS connections I have a feature that would require the user being able to provide the URL for a custom script, store the URL in a cookie, and incorporate the script into subsequent responses.

This, of course, immediately raises concerns over possibilities of a cross-site scripting attack, but using HTTP, given that no third-party can manipulate the cookies* unless performing a man-in-the-middle attack, at which point it is easier to directly inject scripts into the page, this does not further compromise the integrity of the site.

* assuming all ports of all subdomains of the originating domain are trusted, since cookies do not fall under normal same origin regulation

Using HTTPS, however, one would expect that, using appropriate encryption and certification, like any other part of the communication, the cookies can be trusted to come from the user, either by setting indirectly through the server or directly through a dedicated user agent interface, eliminating the risk of a man-in-the-middle.

Turns out, this is not the case, since browsers can be instructed not to send cookies set through secure channels on unsecure channels (using the secure attribute), but they readily send cookies obtained through unsecure channels on secure channels.

So, for example, an attacker, diverting traffic around a wireless access point, could lure a victim into requesting a page in the given domain through HTTP (by clicking a link, displaying an embedded resource like an image, or redirecting to it), respond with a forged cookie, and have the victim use the forged cookie while communicating with the server using HTTPS (injecting a malicious script, fixating her session etc.).

Considering all these, I have several questions:

Is the above understanding correct, and should a server communicating with the client through HTTPS consider all cookies to be possibly compromised, only using them in a way which prevents compromising the security of the site (allowing only a selection of trusted predefined scripts, regenerating the session id, etc.)?
Is there any way given the available framework of HTTP to ensure the integrity of cookies when using a secure connection I haven’t thought of? (Perhaps using cryptography?)
Is there any standardization effort ongoing to solve this problem, that I just haven’t heard of? If not, how come browser vendors, who go out of there way to apply the same origin policy wherever they can and alert users to the risks of mixed content, do not address this weakness in the protocol?

Generally speaking, a server shall consider every incoming data element as being potentially hostile. There is, here, a definition issue when you talk about "site integrity": this can be about integrity of the site as the user sees it, or the integrity of the site as other users see it. If all the server does is to send back the cookie back to the client who said it, as a script to execute, then the problem is simpler.

As I understand it, you fear the following scenario:

The site allows a user U to upload some Javascript, that your server will "store" and serve back to the same user U. This uploading goes through a properly secured process (HTTPS, user authentication...). The storage is not actually done in the server, but as a cookie value in the user's own browser.
By exploiting the user's gullibility, or hijacking the user's network access, the attacker succeeds in pushing some hostile Javascript H into the user's browser, attached (as a cookie value) to your server name.
When the user U next connects to your server, the hostile Javascript H is sent to your server (as a coookie) and the server sends it back to the client, to be executed.

Described that way, then your problem really is one of recognizing "official" cookies that have been pushed to your server through the normal process (with HTTPS and user authentication). Cryptography can help, with a MAC: you want to tag a cookie value, such that only your server can compute a proper tag, and can verify it. That way, your server would reject cookie values that have not been previously recorded through the secured registration process. In the scenario above, the hostile Javascript H value would lack a proper MAC value (because the attacker does not know the MAC key used by the server), so the server would refuse to send back the cookie contents as a script to execute.

In all generality, what you are trying to do is to offload server state onto clients. This can be done with:

a MAC to preserve integrity (against clients who modify their cookies, willingly or not);
encryption, if the state contents must not be shown to the user (this does not apply to your specific case, as you describe it).

See this question for some details.

Take care that the size of an individual cookie, and the number of cookies recorded by a browser for a given site, are both subject to browser-specific limitations.


How can I partially overwrite the EIP in order to bypass ASLR? As far as I know, it is possible to overwrite the unchanged part of the EIP to bypass ASLR protection. Unfortunately, I do not understand how this can help me in order to jump to the location of my exploit. I would need the address of a [JMP ESP] instruction in order to do so, but since the address will always vary, what's the idea behind partially overwriting the EIP?

Furthermore, this answer states that a non-ASLR module is required. How can some parts of the address be fixed and some change in a non-ASLR module?

With ASLR not the full address of instructions will vary but only some higher bytes. So for example Byte 1+2 are static but Byte 3+4 not. So the idea behind partially overwriting the EIP is to overwrite only the static bytes of an address to get a (limited) control of the execution flow.


Does figuring out what one password hashes to allow you to crack all identical passwords? Forgive me, as I am very new to cryptography, but it seems interesting, and I have a question.

I'll state my beliefs and please feel free to correct me on the aspects that I'm mistaken so i can learn:

Here's what I think I know:

When trying to protect a password, it goes through a hash function (i.e. SHA-1), and the resulting hash is stored in the database instead of the actual password itself.
Any time one attempts to log in, and they type in their password, their entry gets hashed and then compared to the hash value in the database
So does this mean that for a given login system, if i type "password1", it always has the same hash value?
If that is the case, then wouldnt all members of a login system who have the same password also have the same hash value in the database? Or is there an additional form of security/differentiation implemented for each user so that my "password1" does not come out to the same hash value as the "password1" of another user?

Yes, sort of.  Ideally two values are stored.  A unique salt, and a hash of the salt+password.  A globally unique salt is generated and stored for each password.
Again, sort of.  First the salt for that user account is retrieved from the database, then the salt+password is hashed and compared to the hash value sotred in the database.
No, because the salt will be different for each user, resulting in a different final hash value for each user.
See 3.  The salt is the additional security/differentiation component that prevents the hashes from being the same.


Is a PCI scan required for LAN outer firewall with no open ports? I have recently been trying to get my company ip addresses scanned with Comodo HackerGuardian. My website needed some adjustments to ssl but after they were made it passed the scan. As we also have a machine accessing a Virtual Terminal at our office premises I then scanned our LAN ip, but as we have no open ports on our outer firewall the HackerGuardian scan did not compete. I then adjusted the firewall to reject rather than drop the HackerGuardian scanner but the scan still failed to complete.

I contacted HackerGuardian about this received the following response:

Question: We have a Virtual Terminal inside our LAN and as I understand things we need to scan our LAN outer/perimeter firewall.

Response: This is incorrect.  Only Internet facing (externally accessible) hosts are in scope for PCI scanning by an ASV.

Question: How can I scan this firewall's WAN ip address with HackerGuardian to make sure that the Virtual Terminal provider is happy?

Response: This is not possible.  Your virtual terminal software should be a pre-validated payment application.

Our office network has a WAN IP address that is public routable with both forward and reverse DNS resolution and the IP address is also externally accessible enough to be reached by HackerGuardian’s scanner.

Regardless of the fact that I do not have any ports open on our office network perimeter firewall I thought one of the reasons for scanning is confirm that this in in fact the case and there has not been a misconfiguration.

What do people think is the correct or appropriate interpretation of the PCI rules?

Any physical location that stores, processes or transmits credit card information needs to have its associated public IP address(es) scanned per the PCI-DSS regulations.

I have a number of sites that return back with either 'no open ports' or only port 500 (for VPN servers). This is absolutely fine.

I can't comment on using Comodo HackerGuardian - I've used a number of different external scanning utilities ASVs. None of them have errored out from not having open ports.


Is HMAC-SHA256 more secure to hide information than SHA256? I need to save user email on a public database but I don't want to do it in plaintext, so I need to hash it. If somebody wants to verify if some email exists in the public database, he or she can calculate hash and check if the hash is there.

I don't want any other user to find out what the email is by knowing only a hash. I know that SHA256 is fast to compute so it will be easy to brute force those hashes.

The question is: is HMAC-SHA256 more secure for "hidding" email? Every email will be associated with a 256-bit random key, the verifier will know the email and it's secret so it will be feasible for him or she to calculate the hash and see if it exists on blockchain.

I believe, HMAC-SHA256 will be more secure in this case than SHA256 because the attacker who wants to brute force the email needs not only to brute force email but also the key which is a 256-bit long.

Yes, using an HMAC with a sufficiently long secret key should prevent third-parties from being able to brute-force the hashed values and identify their original values. For HMAC-SHA256, a 256-bit key would be sufficient.

Note that you do not even have to associate a unique key per email. As long as you can ensure that the key never leaks, you can use a single key to HMAC all emails. An attacker that knows their email, and the HMAC of their email, should still not be able to brute-force the key. Nor should they able to derive the HMAC of related emails.


How to configure TPM lockout in Bitlocker when using a PIN I have Windows 10 (1607) and use Bitlocker with Pin protection. It is a TPM 2.0 chip. I got completely locked out of my a machine. It kept saying "Too many PIN attempts" at the Pre-Boot stage.

I eventually followed the instructions here: https://johnpenford.wordpress.com/2015/05/05/bitlocker-too-many-pin-entry-attempts/

But what are my options in terms of preventing this? I can understand the need for anti-brute-forcing but I would have thought it would reset after a successful PIN entry. I'm guessing (and I have read that some chips do this), that the lockout count doesn't reset.

Is there anyway to manage this - I can see a Standard User Individual Lockout Threshold but there is no way to reset to zero.

It's a little disconcerting to be locked out of new machine after 2 weeks!

This is from MS10 Bitlocker/TPM documentation:

TPM 2.0

TPM 2.0 devices have standardized lockout behavior which is configured by Windows. TPM 2.0 devices have a maximum count threshold and a healing time. Windows configures the maximum count to be 32 and the healing time to be 2 hours. This means that every continuous two hours of powered on operation without an event which increases the counter will cause the counter to decrease by 1.


What happens after setting up HDD password? I am wondering what happens when I set HDD password in my laptop (Samsung with ssd).
I mean a given case.
I have been having working system without any password. Then one day I decide to set up HDD password in BIOS.
Does whole disk in that very moment become encrypted ? I did not notice any moment waiting etc...
I understand that after having password set all written data would be encrypted, but what happens with existing one.
Perhaps I am missing something

Usually, disks supporting encryption do this in two steps.

In step one (usually on factory manufacture) a secret key is chosen at random. Then, a decryption key is chosen, and initially it is blank.

The secret key is encrypted using the decryption key and, when the system is powered up, an API exists whereby the user can supply the decryption key, if needed. Then, the secret key is stored into a temporary memory buffer and used to encrypt (and decrypt) all traffic to the magnetic platters.

To change the password, you supply the old password, whereby the encryption key is decrypted and re-encrypted with the new password. This takes only a few instants.

To decrypt the hard disk you need to know the secret key, which never leaves the disk itself. While some encryption schemes are vulnerable to brute force and statistical analysis (for example because the encryption scheme is a simple "SECRET KEY (XOR) HARD DISK SECTOR" - it has happened), current schemes are pretty solid.

There are some very sophisticated techniques that can recover the hard disk secret key, if the model is known and supported, from the powered down hard disk provided it hasn't been powered down too long, from the residuals in the hard disk's volatile memory. But at that point it makes much more sense to worry about a rubber-hose attack.

The advantage of the double-key system is, as you experienced, that there is no need to decrypt and reencrypt the whole disk whenever the user key changes. This makes the operation very, very fast and reduces the risk of a mishap happening in mid-encryption which might leave the disk effectively "bricked".

Of course, there are rumors - I can't seem to find the reference now, so let's call it a theoretical possibility - that the master key is not actually random at all, but may (e.g.) derived from the disk serial number, maybe hashed with a secret salt (or alternately, it can be random generated... and then secretly stored together with the disk serial number). Knowing the hash, the salt and the disk serial number, and by dismantling the disk or overriding its interface, it then becomes possible to "easily" recover the disk content. At the same time, such a backdoor isn't easy to uncover.


Is Telnet safe for receiving text or does it compromise my whole network? I have a telnet port open to my PC using the TCPClient in latest version of .net, it is only used for receiving text then parsing it and adding it into an SQL Database, my telnet server does not reply to the client in anyway.
Apart from an SQL injection attack are there any major concerns I should be worried about regarding the rest of my network being compromised.
Some of our customers are using old legacy systems still that only support telnet so it is needed to be used, but a recent cyber security audit by an external company said it was a massive risk to our business.
EDIT: If any of the data was to be intercepted and read it doesnt contain any confidential information and would pose no security risk for someone to have this data to both us and our clients.
The security audit did not include any network testing all they heard was there was a telnet port open and put down this was a risk without actually testing if it was secure. But my boss doesnt see it that way and thinks we now are at a massive risk.

One issue with telnet is that there's no protection of the data in any sense. Anyone on the path can copy the data, alter it, and nobody will know. Any data coming from it is untrusted.
The rest of the network being compromised is not the main risk, because this is inherent to any service you have: HTTPS, SSH, NTP, anything. If someone can connect to your service, a bug on said service may lead to compromise. The word may is key here.  Some services are stable, secure, and run for years without issues, while others (sendmail, I am looking at you) have a constant stream of issues.

Apart from an SQL injection attack are there any major concerns I should be worried about regarding the rest of my network being compromised.

Here there's a lot of things that may go wrong:

Buffer overflows: this depends on how your application manages the incoming data. A buffer overflow, use-after-free, off-by-one and a lot of other memory access issues can lead to code execution and lateral movement on your network. The same applies to any other service.

Data leakage: anybody sending data to your service is subject to have their data stolen.

Corruption of data: any message can be silently changed in transit.

Replay attacks: data can be copied, and re-sent later.

What do you do? You can ask your clients to run an encrypted tunnel between their network and yours, and send the telnet data inside the tunnel. Because asking the clients to upgrade their services is not something they will do. SSH is around since 1995, HTTPS since 1996, and they still use telnet, so I bet they will keep using telnet until the end of the times.

cyber security audit by an external company said it was a massive risk to our business.

Ask them to clarify the massive risk. Most of the time, the massive risk they are talking about is credential theft, as telnet is not encrypted and any credential sent can be stolen. If you tell them that no credential is ever sent, maybe they change the risk assessment.
But even so, create an encrypted tunnel and FORCE your clients to use the tunnel.


Multiple Certificates with same DN I have few questions related to DN in SSL Certificates,

Can multiple domains have SSL certificates with the same DN issued by same
CA?
Is it ok for a single domain to have multiple SSL certificates with same DN
and validity?
Can we include CA related information (serial number, name or id
etc) in the attribute of SSL certificate DN? e.g.
cn=user001,ou=SSL,ou=001,o=DS,c=US. If it is possible then which
attribute is better to use for this purpose ou, sn or other? The problem is
that currently, our CA does not support multiple certificates with same DN
therefore, we want to include some unique information in each SSL
certificate's DN.

If possible please provide name or link to the RFC / standard for further guidance.

Thank you

Can multiple domains have SSL certificates with the same DN issued by same CA?

Yes. The browser does not care how many certificates are there for a site as long as these are valid, which includes that the subject(s) of the certificate match the domain name. Thus, if multiple domains should use a certificate with the same subject(s) then the subject(s) must cover all these domains, for example by using a wildcard or by including all the domains as subject alternative names.

  Is it ok for a single domain to have multiple SSL certificates with same DN and validity?

This is possible too. And while it is unusual to have multiple SSL certificates with same subject and exactly the same validity it is common to have certificates with same subject but overlapping validity, i.e. when renewing a certificate which is about to expire.

  Can we include CA related information (serial number, name or id etc) in the attribute of SSL certificate DN?

If you have full control over the CA you can do this. Be in the normal case of using a publicly trusted CA you don't have this control. The CA will only pick the information from the CSR (certificate signing request) which it finds appropriate, which is commonly only the subject(s).

  If possible please provide name or link to the RFC / standard for further guidance.

For general information about X.509 PKI structures see RFC 5280. For specifics regarding publicly trusted CA see CA browser forum baseline requirements.


Asymmetric Encryption + Signature workflow Let´s say that Alice wants to send an encrypted message that only Bob can read, plus confirm that Alice is the person that wrote that message.

What is the procedure that will take place?

When I see digital signature workflow I always see that the message it´s transferred "clear" to the receiver (so Bob can hash the document in his side and compare it with the hash received by Alice), but the encrypted part (using Alice´s private key) is always the hash.

What happens when we want to encrypt also the message to a specific person? There will be a "second encryption" process, in which the message will be encrypted by Bob´s public key?

Just an example to confirm:

  Alice produce digital signature: creates a hash of the document + encrypt it using her private key.
  Alice encrypts the message itself: Takes the document and encrypt it using Bob´s public key (so only he can decrypt it, using his private
  key). (I guess that if the document is big can take a long time to
  finish the process, right?)

There's nothing that prevents you from either signing an encrypted message or encrypting a signed message. The latter is the way encrypted email works, see S/MIME with its CMS message format, or OpenPGP. The former is less common, but sometimes seen, for example in the specification of SCEP secure message objects.

A detailed discussion about the merits of these approaches and more can be found here.


Should I send the Secret with the Refresh Token in OAuth 2.0 I'm working to implement a OAuth 2.0 server, and while reading the RFC6749 specification I realized that section 6 on Page 47 regarding "Refreshing an Access Token". Explains that we need to just use the Refresh Token that we have to get a new Token.

But for example, in addition to the Refresh Token, Google require the User ID and the Secret to do so.

This confuses me, because on one hand we have Google that is processing high volume of requests every day, and we have a specification written probably with a smaller scope in mind.

Is it good to send the Secret every hour with the Refresh Token?

Personally I believe no: because the User ID and Secret should be used only to go over the whole OAuth 2.0 process.

Basically

You use the token on each request to prove that you are who you are.
Refresh Token get used only once an hour (and potentially changed at each refresh)
Secret and User ID go to the internet as rarely as possible. Only when option 1 and 2 get compromised.

I personally believe that sending the Secret with the Refresh token is less secure. But maybe I'm missing something.

If you have another point of view, please share it :)

Actually, if you read on, it also says

  The authorization server MUST:

  o  require client authentication for confidential clients or for any
       client that was issued client credentials (or with other
       authentication requirements),

  o  authenticate the client if client authentication is included and
      ensure that the refresh token was issued to the authenticated
      client, and

  o  validate the refresh token.

Which means quite that: Pass your client ID and secret with the refresh token request.

The specification is not very explicit in this regards, but says that you have prove who you are (or which application you are) in order to be able to do a refresh. Note that it's stated "confidential clients", which means that this is primarily intended to happen server side.

So, in addition to just passing the refresh token, you also have to pass your client authentication into token endpoint, which means that an attacker needs to get hold on multiple values to be able to use a refresh token he has gotten his hands on. This implies that you should possibly also store these things in separate places, and just assemble the needed data when you need to refresh your token.


ASP.NET Web API and potential XSS I'm wondering if my ASP.NET Web API had an XSS vulnerability as my controller didn't have a method to handle the default GET call.

Without the GET method being handled in the code a call to
/api/mycontroller/?<script>alert('hi');</script> would result in:

{"Message":"No HTTP resource was found that matches the request URI
 'http://localhost:8888/api/mycontroller/?'.",
 "MessageDetail":"No action was found on the controller 'MyController' that
  matches the request."}

Note that the script tags are in the JSON source, they're just not displayed on the page.

Drop the question mark, /api/mycontroller/<script>alert('hi');</script>, and you'll get
"A potentially dangerous Request.Path value was detected from the client (<)." so now an HttpException is protecting the users.

The API's routing is simply the default one:

.Routes.MapHttpRoute(
    "DefaultApi",
    "api/{controller}/{id}",
    new { id = RouteParameter.Optional });

and I've now added in a default action method:

[HttpGet]
public HttpResponseMessage Get()
{
    // do something.
}

Putting in this action method, however, could easily be missed when a developer is creating an API, I think.

So I was wondering, is this an exploitable XSS issue?

This condition was probably not an exploitable XSS vulnerability for most applications.  This is more likely a "defense in depth" filter to prevent programmers from unintentionally causing problems.

XSS is solved in an API's by setting the content-type to application/xml or application/json depending on the return data type (and text/plain is also commonly used to prevent XSS). Reflective and Persistent XSS can only be a problem if the page has an HTML content type.  DOM based XSS is still a concern for web services.  The Content-Security Policy can be used to further restrict the ability to execute JavaScript using HTML injection,  and is useful in preventing DOM-based XSS.

When using a modern browser, an XSS payload shouldn't execute on a non-executablite content type.  Never the less, it is a good idea to explicitly disable content sniffing for legacy or non-standard browsers:

X-Content-Type-Options: nosniff


Is it Feasible to Block Connections That Windows 10 Uses to Push/Pull? - ie: Phone Home, Watchers, Monitors, Onedrive, Cortana, Bing, Shadyness, Etc? Even with all the privacy, sync, and p2p settings off, using an offline account, I don't feel safe using Windows 10 for a business. I would like to restrict its ability to communicate to Microsoft (or vice versa) as much as I can.

Is there a list, or any way info out there, about what IP's Windows 10 is using to, for lack of better words, "phone home"? Or is there some way I can find/initiate the push listeners and see incoming? It seems mysteriously sparse in the resource monitor considering the amount of junk that's internet facing. I would like to block all possibilities of push/pull besides updates. However I don't know the plethora of "connected" services available in Win 10 yet and I feel that they would use massive ranges of IP's [v6] or proxies, which would be hard to capture fully. Or perhaps they may even mask com in some abstract layer, underneath the reach of monitors such as netstat or Fiddler.

So far I see some, svchost (netsvcs) perma connected occasionally calling system using the classic 157.56.106.189 range and some new IPv6, then there is system using MS limited in europe at 94.245.121.253 (I'm in USA), followed by system hitting MS denver 64.4.54.254. Im sure there are plenty more of these too that pop up. Also there are mysterious system connection bogons that are way out of our network range such as 169.254.255.255, and some other IP's I've seen checking in for just a second.

Do you know any more IP's like these? Any insights on how to force stop the non-essential communications or what to hardware firewall would be very much appreciated.

Since I think this is a battle you can't win, I've resorted to simply not having Internet available by default for my Windows 10 box.  Instead, to get access to the internet, you have to go through a firewall with a proxy setup.

If an Application needs internet access, I configure its proxy server settings (but NOT the native Windows proxy).  This covers 99% of my needs, as Firefox, Chrome (with plugin) and Thunderbird all have these settings available.

For the other 1% of my Internet needs, I configure the firewall to allow certain IP ranges only (for a few games I play).

This also convienently blocks almost anything that normally annoys me (applications that are not supposed to use the Internet, incessant checking for updates, giving me news, etc..)

Sure, the Tiles etc won't work -- I don't care.

Runs like this for 3 months now, I'm happy.


Passwords verification against a set of breached passwords NIST and OWASP ASVS recommends checking passwords against those obtained from previous data breaches. The list of such passwords can be downloaded from "Have I Been Pwned" (https://haveibeenpwned.com/Passwords), but there are more than 300 million pwned passwords.
Do you recommend comparing users' passwords (during registration, password change, or even every successful login) with such a large list? Will it affect the performance too much?
Is it a better idea to compare passwords with smaller lists like top 1000 or 10000 most common passwords for example https://github.com/danielmiessler/SecLists/tree/master/Passwords? That is the exact recommendation from OWASP ASVS.

"Every successful login" is pointless waste unless you just implemented the password-checking feature and didn't have it before, in which case it might make sense to check every user's login once. The only other time it would make sense is right after you add a bunch of new passwords. Add a field to your authentication DB that indicates whether each password has been checked against the list (defaulting to false), and check each one once, toggling the field to true after it passes (no match). Those that do match the list get forced to change it (if they decline, leave their field false, or even just flag the account for "must change password"). New passwords (either of new users, or if the user changes or resets them) are checked at creation, and once they pass, the field is set true.
The pwned passwords list can be sorted in a few ways, but "alphabetic" (by string comparison logic) is an obvious one, and allows extremely fast lookups (binary search). Stuff it all in a database table with appropriate indices and you won't even have to write the lookup logic yourself. There's no performance reason not to check all 300 million; it's only a bit more than twice as many lookups as checking 10,000 (which isn't enough, really), and that's a pretty easy task for any decent DB engine with a few gigs of RAM to use (give it enough RAM and the whole column can be kept in RAM, though even without that it'll be decently fast). However, you might decide there's some threshold where a password that has ever been compromised is still tolerable (maybe the passwords that have been seen in dumps only once, or just not the million most common ones, or some such thing). The most secure option is definitely to check them all, though.


Applications security review When a company wants to buy a new application, the security aspects must be reviewed (access rights, privileges, logs, data integrity ... etc).
Is there a standard for applications security reviews? In other words, a checklist that must be followed to check that the security features of a certain application are acceptable?

This question might seem a bit generic, and I'm looking for generic guidelines.

Considering two cases:

Web application, hosted in my company and im the owner of the web server and Database.
A locally installed application on host PCs and im the owner of the application server and Database

The restrictions on how security should be implemented when assessing the security of an application, heavily rely on the regulation to which the application needs to be compliant would. General security recommendations can be found in the OWASP guide.

To be able to assess each of these recommendations you would need access to the source code. If your vendor does not want to give you access to the source code, you can inquire if an independent company has performed a penetration test or audit on the code.

Mind though that additional restriction can apply if you are storing data within the application. For instance you have FIPS140, HIPAA, PCI-DSS,... which all may have more strict requirements on how data should be processed by your application.


DNS Amplification DDOS attack During the weekend I made some tests to simulate an DNS Amplification DDOS attack. sending about 90Mb/s traffic I was able to generate about x.x Gb/s amplified traffic which sent our datacenter offline in seconds.
Now that this kind of attack is getting popular every day Im curious to know best practices to mitigate it. Has anyone had experience mitigating DNS Amplification DOS attack?

----- Edit Possible Workarounds -----

Ask provider to block incoming traffic with source port 53.
(Suggested by @rook) To have big guys like Cloudflare, Akmai or verisign to handle it for you which may cost but can be very effective when the provider is not able to help.
(Suggested by @user24077) To implement Remote Trigger Black Hole Routing/Filtering strategy which for my opinion can be effective but risky because you can end up wasting the complete bandwidth while trying to protect a node or client.

CERT recognizes this as a vulnerability in DNS.  As it stands there are about 27 million misconfigured (read: Default!) DNS servers that can be used in this attack.

Ideally you want to prevent these UDP packets from reaching their destination by filtering them at the edge router (which is your provider).  Unfortunately not many providers offer this service.  Cloudflare  uses this method to help mitigate this attack.

Another method is using GEO IP based load balancing.  This is the magic behind many CDNs in that,  DNS resolves the server closest to you.  In a DoS attack this helps distribute the load,  and isolate outages to a specific region(s).  There is also some elegance in using DNS to help prevent DNS amplification attacks.

Eventually the servers used for DNS amplification will be configured properly.  But this solution is likely more than 10 years from coming into fruition.

For most people, using a service like cloudflare or akamai is the best solution.


Exploiting a PHP server with a .jpg file upload I would like to ask a question regarding the classic uploading an image and executing php code exploit on a website.

So I have been trying out this exploit a website I'm supposed to hack (It's set up for us to try and hack it)

The webpage allows us to upload an image, and while changing the mime type using TamperData is easy, the webpage apparently checks if the last characters of the file is '.jpg' or '.jpeg' before allowing the image through.

Regardless of the placement of the PHP code(I've tried just php code, php code pasted at the end of the image file, php code in EXIF headers etc), the website just shows the image file when I open it after uploading (or an error in the case of plain php code saved as .jpg), since the extension is always jpg.

So in such a case, what should be done to execute the file as .php?
(null bite poisoning does not work, neither does uploading the code as vuln.php.jpg or vuln.php;.jpg. Both just shows the image)

Regardless of the placement of the PHP code [...], the website just shows the image file when I open it after uploading

Yes, that is how it should be. The server would be seriously vulnerable if it would interpret .jpg files as .php files depending on the content instead of the extension.

  So in such a case, what should be done to execute the file as .php?

Without some kind of vulnerability in the code itself, you can't execute image files as PHP files, as any decent server would not allow this.

Without knowing more about the code, we can't do more than guess. If it's supposed to be vulnerable on purpose, I would guess that the extension check is probably broken.

You might try:

.htaccess: the extension check may interpret this as no extension, and it may be fine with that. If the server parses the .htaccess file, you can then gain code execution with image files via AddType application/x-httpd-php .jpg.
vuln.jpg.php: the check may check the first, not the last extension.
vuln.php5, vuln.php4, vuln.phtml, etc: the check may be a blacklist check, not a whitelist check, which may miss some extensions which may be interpreted by the server as PHP files. You can easily test this with a madeup extension such as foobar, if it passes, it's a blacklist filter.
LFI: You may have a directory such as misc with subdirectories uploads and configs, where configs contains PHP files, and uploads contains the image uploads. Then you may have code such as include "misc/" . $filename. Lets say that there is a check for directory traversal, so this should be bad code, but generally still somewhat secure, right? Well, included .jpg files are parsed and executed as any other file would be, and thus PHP code inside it will be executed. This example is a bit far fetched, but it's not completely inconceivably that something like this may exist.

tl;dr: You can execute jpg files as PHP files via .htaccess or via include. Additionally, you may be able to bypass the file extension check if it is insecure.


How is my website vulnerable for sql injections? I am running a small website where I have published some articles.
I am also very interesed in security topics and tried sqlmap on my website. It found the database name, so my question is how it could find it.

The website is very basic and does just contain a very small number of php files and I have just tested on the index.php file:
sqlmap.py -u http://myurl.com/index.php?id=5 --dbs
In the index.php I have used the php functions mysql_real_escape_string and stripslashes to clean the string before using it in the SQL question and if the visitor tries to mess with the id in the URL, then I just reload the index.php:

$id = $_GET['id'];
if (get_magic_quotes_gpc()) {
    $id = stripslashes($id);
}
$id = mysql_real_escape_string($id);

$sql = "SELECT * , COUNT( * ) AS amount
            FROM articles
            WHERE id = $id
            GROUP BY id";
$result = mysql_query($sql) or die(header("Location: index.php"));

So how on earth could sqlmap.py get the database name out of the above information?

Could you please explain how it is possible and also provide an example?

Always use parameterized queries, string concatenation leaves room for error, stop leaving that room (they also look a lot nicer).

Also, because id is an int, I don't need quotes to inject:

$id = '0; Drop Table myTable;--';

$sql = "SELECT * , COUNT( * ) AS amount
        FROM articles
        WHERE id = 0; Drop Table myTable;--
        GROUP BY id";

I like to use is_numeric to check if it's a number and kick them out of it isn't.

Edit:

PDO provides preparation of SQL queries:
http://php.net/manual/en/pdo.prepare.php

So for example:

$sql = "SELECT * , COUNT( * ) AS amount
    FROM articles
    WHERE id = :id
    GROUP BY id";
$sth = $dbh->prepare($sql);
$sth->execute(array(':id' => $id));


What tools one can use to detect a malicious activity on a computer, aside from antivirus programs? Some time ago I got a virus on my computer, which is not detected by antivirus programs.
Yet I can see the malicious activity in the Windows Event Log and in the TcpLogView:

Considering that updates of antivirus databases always lag behind the creation of new viruses, what program tools are best suited for a timely detection of such zero-day threats?

There is no perfect security and noone can guarantee that a virus will never go through whatever defence you set up. Though there are some measures that can make it less likely:

A firewall

monitor for suspicious network activity

Behavior-based detection

Just like firewall can detect suspicious network activity modern antiviruses can monitor suspicious activity within your system. No matter how new the virus is it needs to autorun somehow every time when computer starts. Usually applications add themselves to autorun during installation or when you deliberately ask them to do so. So monitoring autorun is a good way to catch a virus and is unlikely to bother you with false positives. This is just one example, the behaviour-based security could monitor hundreds of potential harmful activities. Among free antiviruses i know COMODO Antivirus provides this type of protection (its called HIPS in it). Many others may do as well (check AVG, Avast, Avira, etc) though I am not sure about them. Though with more aggressive detection comes more false positives. So don's get overenthusiastic with high settings.

Heuristics

Signature-based detection tries to find specific viruses that have already been caught and analysed. Heuristic analysis is searching for specific commands within application's code that are likely to be harmful. While behaviour-based detection analyses what application does, the heuristic analysis analyses what it could do.

Sandboxing

When you have a clean PC the only way a virus can infect it is from some new file that you downloaded and lauched. If you care a lot about staying secure you could launch unsafe (downloaded from internet, etc.) applications in a sandbox (isolated environment that from which the virus can not escape and harm your real OS). Even if you run a virus within sandbox it will be killed without a trace when the sandbox is closed. Advanced sandboxes allow you to "freeze" it's state when closing instead of just erasing everything so that you can continue the work when opening a sandbox next time. It is still perfectly safe.

Though some very advanced viruses might escape a sandbox using a mistake in it's code there is no reason to worry about it. For this to happen the virus should be targeting the specific sandbox application you are using (and probably the same version) and it must be vulnerable in the first place. Also creating such a virus would require expert-level knowledge and a ton of work. It's just not worth the trouble. Viruses like this are usually created for specific targets (i mean by intelligence agencies, etc.) and not spread in public. Because getting it caught by antivirus companies would destroy all the hard work put into creating this monster.

An example of free sandbox is "sandboxie". It has a nag screen after trial expired but still allows you to use it forever. Also many modern antivirus solutions have built-in sandbox. Once again COMODO antivirus has it and many others are likely to have it.

P. S.

When you see an unknown process with suspicious network activity in background it is not necessarily a virus. It could be background update service, license check service, etc. Just google the name of the process and you may find out what it is. Also when you are concerned about specific file you could use online virus scanning services that would check it with every antivirus in the world without having to install anything. It would also help the antivirus companies to roll out an update quickly if you actually find a new virus - they do check files uploaded to such services (not all of them though. It requires the owner of the service to cooperate).

P. P. S.

As was said in the beginning you can only increase your security but never reach 100%. And with more security comes more bothersome false positives and more performance drop. At some point antivirus does more harm then the virus it might catch. One of the targets for risk management is to make sure that maintaining your security is not more taxing than having it breached sometimes.


Reading the MailWatch interface - 'From' address We often get emails blocked that have confusing sender addresses. This is always the scenario: a message marked as spam says this in the actual headers: "From: "Bob Jones" some.normal.address@domain.com". But below the section with headers, MailWatch reports the From address as "From: bounces+234567-91eb-recipient address@sender domain". What does this mean? Why does a seemingly normal email coming from a normal address show up as being from bounces+123456-blah-blah?

The From address can be set to pretty much anything you want it to be.  It's arbitrary text.

Other headers, such as Envelope-From, Reply-To, Return-Path, Sender, and Errors-To may provide more accurate information about who sent the mail, especially - as appears to be your example - in the case of a mailing list.

Mailing list software will often leave the original sender's From address but insert Reply-To to make replies go to the list by default.  However, in your case, you've indicated (via comment) that MailWatch was paying attention to Envelope-From.  That header was likely injected by your mail server; it noted the SMTP "MAIL FROM" value that way.  The mailing list sends mail with that "bounce" address as the SMTP "MAIL FROM" so that any bounces will go back and be handled by the mailing list manager, but normal user agent replies to the mail will use the (From, Reply-To) headers to send to (the list, or the original poster, depending on list policy).

The specific weird in the address (234567-91eb-recipient address) allows the mailing list to determine which address it sent mail to that caused the bounce.  After a few bounces, it will either pause email to that address or remove the address from the list.


Using GPG as password manager I want to use GPG as a master password storage (encrypt and push to online storage). This would require encrypted file being able to be decrypted on multiple machines.

Two computers comp1 and comp2 with differing operating systems
Comp1 has a file, myfile.txt
This file will be stored encrypted on comp1
From my understanding, private key on comp1 will be used to encrypt myfile.txt

How are private keys stored with GPG. e.g. Best practices. If hd fails, private key is lost?
To decrypt on comp2, I could store private key on comp2 as well?
Any links to diagrams appreciated as I know the keys are also tied to emails and not sure how this fits in?

With GPG the file is actually first encrypted using symmetric encryption, and the key used for that is then encrypted to every recipient using their public keys. Therefore, instead of transferring a single private key between the systems, it's possible to just encrypt the file with multiple recipients.
gpg --encrypt --recipient <comp1> --recipient <comp2> \
    --recipient <compN> passwords.txt

There are some caveats with this approach:

How any changes to your password database are synced between the systems. One would need to be able to act as a server, while the others might use e.g. rsync to syncronize the file. Password managers may provide service for this.
If any of the systems is compromised and the password file containing everything is decrypted, every password would be compromised. Software designed for password management have some solutions to minimize this risk e.g. by only decrypting one password at a time and trying to erase it from the memory as soon as possible.
As so many good solutions already exists, I wouldn't try and reinvent the wheel.


2FA: Why do I need to keep my backup codes for each platform on paper? I'm looking into setting up 2-factor authentication for my registered accounts. However, when setting up 2FA, for example Reddit, you need to write down backup codes in order to regain access to your account in case you lose your smartphone.
I've already read this post.
But the whole point of using password managers (yes, that's another thing) is that you don't have to write down all the passwords you've been using for all your registered accounts, and still can have different passwords for all websites in case a website gets hacked and appears to have stored all passwords in either plaintext/encrypted form (yes, yes, it still happens today). Since writing down passwords, keys, codes is really old-school.
So I'm feeling that writing down backup codes for the platforms supporting 2FA is a real step back. In fact you'd have to store these codes written on paper in a safe.
Is there any way I can be sure to regain access to my account that's been setup to use 2FA, when I lost my phone, without having to fallback to silly backup codes I've written down on paper, for each website?
Does this also mean that if you lose your phone and backup codes, you can't access your account at all?

Writing them to paper is one of the simplest, guaranteed to be safe from malware and hardware failure for the average people. If you have a password manager, usually you can store secure notes too, which can handle backup codes. But if you do that, then attackers who managed to breach your password manager now have everything they need to get into your account. Some 2FA apps like Authy allow syncing and backing up codes across multiple devices, but this also means you've multiplied the weak links.
You don't have to take a single approach for all of your account, perhaps you decide your social media account is not that vital and store the backup code in online account or sync the 2FA token, while still writing your email backup code in a piece of paper because it's the gateway for every account you have.


How can I report a new vulnerability to cve.mitre.org such that they assign a CVE ID to it? This is a hypothetical question. The answers would help me to learn how CVE issues CVE IDs to vulnerabilities.

Let us assume that I have followed the principles of responsible disclosure, reported the vulnerability I found to the vendor and the vendor has not fixed it even after several months.

How can I report this vulnerability to cve.mitre.org so that they publish the details of the vulnerability after assigning a CVE-ID to it?

I have seen independent hobbyist security researchers people posting vulnerabilities on Bugtraq and Full Disclosure mailing list and those vulnerabilities are automatically included with CVE-IDs in cve.mitre.org. I want to know more about how this works. I don't think each one of them emails a CNA to request a CVD-ID number.

[Note: see the answer by @tim, which is a more thorough anwser than my quick google.]

MITRE has official documentation that answers your question right on cve.mitre.org, specifically have a look at https://cve.mitre.org/cve/identifiers/index.html which gives a thorough description of CVE Identifiers, how they are created, and how to request one.

The home page https://cve.mitre.org also has the following right in the main column:

  CVE Numbering Authorities (CNAs)

  CNAs are the main method for requesting a CVE-ID number.

  CNAs are major OS vendors, security researchers, and research organizations that assign CVE-IDs to newly discovered issues without directly involving MITRE in the details of the specific vulnerabilities, and include the CVE-ID numbers in the first public disclosure of the vulnerabilities.

  The following 22 organizations currently participate as CNAs: Adobe; Apple; Attachmate; BlackBerry; CERT/CC; Cisco; Debian GNU/Linux; EMC; FreeBSD; Google; HP; IBM; ICS-CERT; JPCERT/CC; Microsoft; MITRE (primary CNA); Mozilla; Oracle; Red Hat; Silicon Graphics; Symantec; and Ubuntu Linux.

  A message about turnaround times for requesting CVE-ID numbers from MITRE is posted above. For more information about requesting CVE-ID numbers from CNAs, visit the CVE Numbering Authorities page.

If you're not satisfied with the official answer, then please specify what you know, and what you're missing in your question.


Tools helps: First time cracking passwords I am trying to crack passwords on two Windows member servers (2003 and 2008). There is no Active Directory. Each user seems to use the same password across servers, workstations, etc. I have access to the servers via an account given to me by the company that owns the servers. We'd like to get the other accounts.

With OphCrack, I used a pwdump file generated on the 2008 server to crack 18 of 26 passwords. These passwords were VERY simple (first names, for instance). The others are proving more elusive.

I am running Hash Suite Pro on the last eight accounts on a spare laptop.

I'd like some suggestions on other ways to go about this: tools, ways to speed the cracking up, etc. I've got a budget I can work with that's fairly high.

As far as jail time goes, as long as your contract is effective and has protection, you can be pretty safe in many countries. In the UK we do a lot of this sort of thing- mostly password strength audits. I'm not going to give legal advice, but your legal counsel should know the wording required in a contract for this. In the UK we use Hold Harmless terms, and restriction of liability so that if we break something while accessing computer systems we aren't held liable.

Technically, if you know the password strength requirements, you will know what sort of table or brute force you need to work with. For example if your minimum length requirement is 8 chars, start your brute force at 8 chars.

If you have already covered off brute force and dictionary attacks, a rainbow table maybe your only option. As @rook says, there are a few free places you can get them. The most common, though, are paid tables or table exchange, where you create a new table in exchange for the total set so far.


how secure is passwordcard.org? How secure is passwordcard.org? Assuming user follows recommended precautions:

Don't read along with your finger, or the smudge will tell a thief where your password is.
Keep your PasswordCard on your person, don't leave it lying around near your computer.
Clear your browser cache and history after printing this page.

I have a quite a few concerns with this service:

The premise of the card is flawed.  While it is better than simply writing your password down, it's not much better.  If the card is known to an attacker there are 8 x 29 starting places and your choice of length and direction of password.  This choice is very likely to be 8 and quite likely to be up-right, right, down-right or down (4 possibilities).  An attacker with your card or secret number would likely have your password in 928 attempts.  If you consider lengths longer than 8 and directions that go left, multiply that number by the number of possible lengths and/or directions. 8 rows x 29 columns x 8 possible lengths x 8 possible directions still only gives 14848.  The card provides very little extra protection than simply writing your password down.
Your card is defined by a secret number.  If anyone knows this secret number, they can regenerate the entire card by visiting the site and typing in that number.  This number leaks all over the place on the site in question.

The site does not default to using SSL, even though the site is available using an SSL connection.  Below the card there is a list of options and one of those is "Secure connection".  Next to this is a tiny arrow.  That arrow is a link to the SSL version of the site.  Your secret number will be visible in network traffic if you are not using SSL.  There is also a link to the SSL version in the FAQ.
The image is pulled in to the page with a URL that includes the secret number.
Some pages (such as this one) cause the image to be linked from http://www.passwordcard.org/generatecard.do?number=4cdf1e93c5229716&cookie=-n0uofpzgp7x7&allowCaching=true which causes the image to be sent back with an Expires: header that allows it to be cached for a year.  Although they have a precaution to "Clear your browser cache and history after printing this page." this does nothing to prevent intermediate third parties such as your ISP from caching.  This is in contradiction to the FAQ which states that only images on the mobile site are cacheable.
The secret number is put in a cookie: number:ce9916b2fb16f213 with a very long expiry date.

Set-Cookie: number=ce9916b2fb16f213; Domain=.passwordcard.org; Expires=Thu, 08-May-2081 13:00:58 GMT; Path=/

Both the cached image and the cookie end up on your hard drive, meaning that even if you delete them, they can be recovered unless you use a secure delete process.
The site pulls in javascript from several other sources including addthis.com, facebook.net, google-analytics.com and google.com.  The FAQ is mostly but not completely consistent with what I see on the site.  Note that the domains may also differ, such as m.addthisedge.com and ssl.gstatic.com
On this page, the Google Analytics javascript in particular caused this request to be sent:

  http://www.google-analytics.com/_utm.gif?utmwv=5.4.1&utms=30&utmn=482475756&utmhn=www.passwordcard.org&utmcs=UTF-8&utmsr=1920x1080&utmvp=700x626&utmsc=24-bit&utmul=en-us&utmje=0&utmfl=11.6%20r602&utmdt=Your%20PasswordCard&utmhid=257017121&utmr=0&utmp=%2Fen%2Fpanel%3F
  number%3D1cc09968cc0f6c31&utmht=1366451569430&utmac=UA-9164771-1&utmcc=_utma%3D18293158.224629233.1366447288.1366447288.1366447288.1%3B%2B__utmz%3D18293158.1366447288.1.1.utmcsr%3Dsecurity.stackexchange.com%7Cutmccn%3D(referral)%7Cutmcmd%3Dreferral%7Cutmcct%3D%2Fquestions%2F34602%2Fhow-secure-is-passwordcard-org%3B&utmu=DB~

The secret number is written on the card itself.  It is much easier to shoulder-surf just that number than the entire card.

The code that generates the secret numbers is available on the site and does use java.security.SecureRandom, which is good.  Unfortunately I'm not familiar enough with Java to know whether nextLong() automatically seeds the PRNG the same way that nextBytes() does.  If the seed for the CSPRNG is predictable, the secret numbers become predictable.
To generate the strings that are used for the passwords, java.util.Random is used with the secret number as the seed.  The PRNG used for java.util.Random has serious problems for anything related to security.  So much so that non-security-related games developers notice them by accident.  The specific problem with this code is that it may introduce patterns in the passwords that would make them more predictable without even knowing the secret key.

In the end, your usage of PasswordCard should be dictated by your risk tolerance.  All the above possibilities are unlikely to happen to a random person.  If you were the CEO or Sysadmin for a company with some significant value in an industry on China's five year strategic plan, the likelihood of there being an attacker actively trying to get your information is somewhat higher than if we're talking about a high-schooler's Reddit account.

You can mitigate most of the above leakage problems by downloading the Java source code and generating your password card on your own machine.

You can be certain of the seeding by modifying the code to call nextBytes() directly after instantiating the SecureRandom object.

You can mitigate the predictable strings problem by modifying the code to use a second instance of java.security.SecureRandom for the password strings rather than java.util.Random.


Was DSA invented from RSA? I'm wondering if the two algorithms are similar and whether DSA was really just based off RSA?

Is DSA based on RSA and public key encryption?
If so how does DSA introduce signing and makes it different from RSA?

DSA is not a variant of RSA. If anything, DSA is a variant of the Schnorr signature scheme, modified in order to make signatures shorter, and, more importantly, to make DSA out of reach of the Schnorr patent (which has long expired). DSA itself was promoted by NIST as a US Federal standard because RSA was also covered by a patent at that time (this one has expired too).

Mathematics of DSA and RSA are quite distinct. See the mathematical description on the Wikipedia pages for DSA and RSA.


Multi-factor auth: implementing a "don't ask again for this computer" function Many sites that support multi-factor authentication provide a "do not ask me again for this computer" option. I'm hoping to gain some insight into how this feature could best be implemented.

My initial assumption would be that it is implemented using an (ip-locked?) cookie on the users system.

This would however seem to drastically weaken security, since if the cookie is stolen, 2fa is essentially defeated (especially if a login-cookie is also stolen).

Any ideas?

Pinning the cookie to the IP is not practical. Imagine a mobile phone that is constantly switching networks.

I heard about pinning the cookie to the SSL session keys in high security applications. The server would allow a specific cookie only if it comes over the specific SSL session that was used to initiate that cookie.

A different way of making the cookie unusable on a different computer is fingerprinting the original computer. The combination of, OS, browser, screen resolution, installed add-ons, can form a unique fingerprint that identifies one computer.

When Heartbleed hit and session cookies were exposed, a lot of second factor authentication became useless and the "remember me" worsen the problem because cookies did not expire at the end of a session.

The "remember me" functionality is for convenience. Convenience is almost always at odds with security. Imagine using voice recognition in your office to conveniently input passwords and the second factor. Multi factor decreases convenience and increases security.

In fact, multi factor authentication asks for multiple inputs from the user while the "remember me" is used to ask for less inputs. You are asking for something that increases security and convenience. That is where research into new authentication is currently applied. Biometrics, personal devices and other technology is working toward that goal.

Services like LastPass and KeePass can provide the illusion of the "remember me" and still have heightened security.
Google is working on a ring and a technology that uses your smartphone and inaudible sound to authenticate the user.
YubiKey is a hardware device that can eliminate remembering and typing of passwords.


Who's been accessing my computer with TeamViewer? Tracking through UUID So here I am, sitting at my computer screen on the one day of the week I stayed home from work, checking messages on my phone, when out the corner of my eye I see a browser page being opened. It was PayPal. Luckily for me, I'm not so careless to stay logged-in. Then I noticed a TeamViewer session is running. I of course immediately disabled it and shut down TeamViewer, changing my password in the process. Looking through the logs, there indeed was an incoming connection, and fortunately for me, it seems to have been the first time.

I already contacted TeamViewer support and I am currently waiting for their reply. However, from what I can gather by the logs, they contain the incoming connection's UUID. Can this somehow be used to find more information about the culprit?

The UUID can be tracked by TeamViewer, but do not expect them to tell you anything as that would likely require a subpoena. But let's take another look at this. So you gain the knowledge that the UUID belongs to say: Drugov Russianomov somewhere in Romania. Now what? Your course of action to minimize the potential of someone 'owning' your TeamViewer sessions should be something to the tune of:

Creating a complex password
Minimize usage (turning off Team Viewer    when not in use)
ACLs (firewalls. Allow trusted networks block ALL others)

I fail to see what gathering data via UUID will do. No law enforcement agency I can think of will give you the time of day unless you were the victim of theft to the tunes of hundreds of millions of dollars. Here in the United States, most SAs will listen to you for about five minutes before politely telling you: Nothing to see here moving along.

The issue with Team Viewer and similar software, is right now there is an assumption that the user utilized TeamViewer on their own machine to access yours. The reality is, whomever logged into your machine, likely did so from another compromised machine. To fiddle around with financials (banking, Paypal, etc) one would not point a direct target right back to them. There are the unsophisticated attackers, but again, if this were one, what would be the outcome? Criminal complaint? At this point there is no forensic evidence. Retribution? To whom, what makes you sure you're not attacking a compromised machine. See the dilemmas here?


what are good requirements for a password I'm making a website and I'm deciding on the password policy. What does make a good password? I really have no idea. I guess passwords should be at least 6 characters long.

EDIT: are there any recommendations on how "complex" the password should be? For example require 2 digits 2 grammar characters and the remainder of the password can be anything?

Bruce Schneier has written a nice essay about the subject, I suggest taking a look at that. In a nutshell:

Most users tend to use similar patterns for their passwords, and there are tools which are pretty good at guessing them (up to 65% success rates).

This pattern, as satirized here, consists of using a dictionary word (common or not) with some letters substituted according to common rules (such as 4 for A), followed by (or more rarely prefixed by) a simple affix (usually numeric).
The "danger" of such passwords is that they provide an illusion of complexity and thus security, while in fact they are relatively easy to crack (assuming an off-line attacker).

Passwords that contain biographical data (such as names, addresses, ZIP codes) are substantially easier to crack, so users should be discouraged from using them.
Very short passwords (4 characters or less) are also susceptible to exhaustive searches.
A good password, thus, should have reasonable length (8 characters as reccomended by OWASP might be ok, but in principle the longer the better) and not follow an easily recognizable pattern.

Alternatively, it could follow a pattern, but one that can not be easily replicated. An example would be thinking in a sentence, and creating a password from the first letters of each word in that sentence.
Another option (also suggested in the essay, though personally I disagree with it) is putting the affix (the numeric sequence) in the middle of the root (the word), or using two words joined together with the affix.

The most important of it all IMHO is not having a "maximum password length" or, if unavoidable, to leave that maximum at a very high value (such as 64 characters). Since you won't be storing the password itself, instead storing a secure hash of it, the length shouldn't affect your back-end design.

(Also don't try to "force" too much password complexity, or your users will begin to actively fight you - by writing down their passwords for instance)