What steps should I take to ensure there are no unpleasant surprises in a recently purchased home? After buying a house from another party (i.e. not new construction) what steps should I take to ensure the previous residents have not left behind anything unpleasant for me?

I'm not worrying about booby traps or anything of that sort, but rather surveillance equipment or physical security backdoors.

I'm already planning on changing the locks, but what other steps should I take to limit any unpleasantness from the previous owners.

In terms of surveillance, on a consumer level, most of what you're likely to run into are WiFi-based surveillance devices and cheap baby monitors.

There are two tricks to discovering WiFi surveillance devices in your area. One trick you can sometimes do to find WiFi-based cameras is kill the power (at the breaker), wait 10 seconds, then bring it back online and watch for WiFi APs on your phone. Many of them send out a beacon SSID for configuration during startup.

The other trick, for WiFi-based cameras that connect to a configured network, is to use a WiFi card in promiscuous mode to capture probe packets. These packets are effectively the "are you there?" queries from the client device when they are trying to connect to the network. There'll be some noise from nearby devices, but again you can turn off the power, look to see which devices are sending out queries, turn on the power, then look for new devices (particularly ones that reliably send out a probe packet within the first 10-15 seconds of power being turned on, but never when the power is off).

Baby monitors are trickier. They're mostly running on 2.4GHz band, which puts them outside the range of most cheap RTL-SDRs (usually no more than 2.2GHz), but they're not WiFi devices. Instead most of them transmit using FHSS. If you buy a down-converter for your SDR so that you can receive 2.4GHz, or buy a pricier SDR with a wider tuning range, you can look for FHSS signals in the 2.4GHz band. They look like this:

Note the strong carrier, two sidebands, and characteristic spots over the frequency domain. Unfortunately you'll need to do a lot of manual searching, since the 2.4GHz band is quite expansive, and that still won't tell you where the device is. Again you can cut the power to see if the signals go away so that your neighbour's baby monitor doesn't give you false positives.

For audio-only baby monitors you can scan for narrow FM (NFM) on 40MHz and 49.5-50MHz (protip: get a battery radio and turn it on as a background audio source to make the signals more visible on your SDR) and wideband FM (WFM) on ~860MHz. You can also check the DECT bands (1920–1930MHz) for strong signals, again doing a differential test with power on and off, although you'll need some magic to decode these back into audio as they're not analogue.

On the physical side the locks are the main one. Don't forget sheds and garages, as they often contain valuables and are overlooked when changing locks. Ask your locksmith to install a cylinder lock with protection against snapping, bumping, and drilling, as these are the three most common low-skilled attacks. Not many burglars will SPP or rake a lock but you can get a fancy pick-resistant cylinder if you wish.

You should check to see whether the locks on lockable windows are working - it's easy to grind off the lever on them so that they appear to work (key goes in, turns) but it doesn't actually prevent the window from being opened. Also verify that all exterior doors open inwards, as outward-opening ones will have the hinge pin on the outside and that can easily be knocked out to remove the door (outward-opening fire escape doors have special pinned hinges to prevent this attack). Again, you can ask your locksmith to do a once-over of all the locks and security controls in your property.

Finally, you can install deterrents like an alarm system and motion-sensor floodlights. They make it hard to approach the property without being spotted and make it even harder to break into the door unseen. Back doors are more preferable as they're away from the street, so a wall or fence and a locked gate preventing access helps a lot.


How secure is the CDM design? A followup to How secure will EME be?

What I don't understand is how the CDM prevents key leakage. Is it not enough to "simply"[*] inspect the browser's memory and derive keys?

In other words - given two options, which would be more secure, or are they roughly equivilent?

Widevine/etc. CDM solution
Some app with a bit of obfuscation on a whitebox-aes implementation

As far as I can see - both are software only and neither benefit from more robust hardware+os implementations

[*] I'm not qualified enough to come up with an example of how to do this - perhaps the answer(s) could provide specific tools/techniques of how such an attack could be carried out, and explain why CDM is any different in light of those specific attacks

Re. inspecting memory: Back in the day, that was indeed how it was done. It's often a bit more involved than that due to anti-debugging tricks or run-time encryption (on top of the inevitable obfuscation) of the DRM program code and data. If I remember correctly that was how the DeCSS key was leaked from the software-based DVD player programs of the time.

The CDM providers might take this road, which is well-known to be somewhat secure in that it buys time (it takes a skilled reverse engineer a while to figure out the decryption, then you change it in the next version and make them start over again) and isn't too controversial.

Or they might go for a hardware solution in which part of the decryption code is uploaded into some 'secure enclave' in your CPU that cannot be inspected from within the same computer itself. I think we have gotten a preview of this type of scheme with e.g. Apple's iPhone and Intel's 'Management Engine' which has been in the news recently, although I don't think the current implementations of either make much provision for multimedia decryption / playback.

So I think the plain answer to your question is:

The current crop of CDMs are probably as secure as a typical software DVD or blu-ray player: Good against most casual opponents, still vulnerable to skilled reverse engineers who care to put in the requisite time and effort.
Future CDMs have the potential to be highly secure, assuming hardware support becomes widespread, making illicit decryption of multimedia as difficult as e.g. jail-breaking an iPhone or cracking the copy protection on a modern gaming console: There is at any given time probably only a handful of people in the world with the skill, time and motivation to crack such hard schemes (reverse engineers and hackers almost always 'age out' - it's a young man's game).


can vulnerabilities be treated differently based on ceratin circumstances? We are running vulnerability scans on our systems. I can see a few XSS vulnerabilities being reported, such as CVE-2020-14173. Let me quote:

The file upload feature in Atlassian Jira Server and Data Center in
affected versions allows remote attackers to inject arbitrary HTML or
JavaScript via a cross site scripting (XSS) vulnerability. The
affected versions are before version 8.5.4, from version 8.6.0 before
8.6.2, and from version 8.7.0 before 8.7.1.

If this is a internal (not exposed to the Internet) system could I safely assume that the severity for such vulnerability could be decreased? I mean, if a bad actor has already gained an initial foothold, I could imagine that he would use other techniques to escalate privileges.
Are my assumptions valid?

Well, having a service internal facing only does limit the scope of who can abuse said vulnerability.
(It goes from the whole world to a quite limited subset of users with acces to your intranet)
So just like if an exploit requires a valid admin login or not impacts its severity, so does this.
But you must also consider that xss are initiated from anywhere, so unless you got dedicated tools your browser can become a relay.
But remember that gaining access to your intranet is often easier than you think (it takes 1 compromised device after all), so it’s still the best idea to patch ASAP.


Spoofed email has appropriate alias but unknown email My wife received a suspicious email where the "FROM" field contained my name, but the email appeared to be delivered from an E-Mail address that we do not recognize.

The fact that the email used my name was a little alarming, since it was so appropriate to get my wife to respond (she did not, deleting the email after she confirmed with me that I had nothing to do with it).

Should I take this as evidence that either of our accounts have been hacked? It seems to me like someone may have access to her address, her contacts, and sent her this message using a spoofed account using one of her contacts as an alias.  On the other hand, maybe this is just the result of data mining on the web and there really isn't anything to worry about.

Any recommendations?

To answer your question, I slightly suspect if any, your wife's account may have been compromised. This suspicion is derived from assuming that the attacker may have gotten your name from her contacts, but I find it more likely that both of your E-Mail addresses and marital status are contained in some database out there.

One thing you can do to check if there's any unauthorized people using your gmail account is go to https://myaccount.google.com/security and from here you'll be able to scroll down and see some information about recent activity and connections to your google account. If things appear to be in order here, then you're likely fine. Regardless, it's always a good idea to change your password whenever you become suspicious.

In the future it might also be a good idea to keep the email in the event that this person starts to become threatening to the safety of your wife, family or yourself. It could be a good lead for the authorities.


Idea for an algorithm to authenticate users with zero-knowledge-proof [need thoughts/review] I have an idea for an algorithm. I don't know if I made any mistakes and need some extra thoughts/peer review on it.

This would work as an (almost)zero knowledge proof for sending passwords that can be easily implemented.

registration:

A user sends his password to the server (one time risk).

The server computes a "secure" hash of said password. This hash has to be very long, lets say 4k characters.

login:

When a user wants to log in, he first computes said hash on his local machine. The server then tells the client to join random letters to a new one time password. The server only sends out letter positions and sends them out at random, so that there are enough permutations to never run out of combinations. There has to be a history of already used letters, so that at least one never exposed letter gets used. Else a MITM could simulate a client.

After joining all letters to a new password, said password gets "securely" hashed and send to the server for verification. the server performs the same tasks the client is doing and checks his version against the clients data.

Even if send one-time passwords are "securely" hashed, the attacker has time. So after about half of the hashed original password is revealed, a counter is increased, and said password is hashed one time on the server side and old hashed password discarded. This counter gets send to the client every time he want's to login, so he increases hashing rounds by the counter to match server data.

This is an idea that came into my head some seconds ago. It seems to be a good approach. But I would like to see your thoughts on this one, where is the flaw? Or is something similar used already?

This is how I understand it, please correct me if I've misinterpreted something.

Sending Password in the Clear

A one time risk is never worth it when it can be avoided.  Using a secure algorithm like bcrypt or PBKDF2 with a salt does not require the password to be sent in the clear.  Even if the password is sent under TLS, am I to trust that you're not keeping my password for yourself?

This answer provides a completely secure mechanism for login authentication without sending a password in the clear.

Overhead

There is a lot of overhead that an attacker can see over the wire.

  When a user wants to log in, he first computes said hash on his local
  machine. The server then tells the client to join random letters to a
  new one time password. The server only sends out letter positions and
  sends them out at random, so that there are enough permutations to
  never run out of combinations. There has to be a history of already
  used letters, so that at least one never exposed letter gets used.
  Else a MITM could simulate a client.

What exactly is happening here?  Are you joining random letters to the hash of the password?  You're sending the letters in the clear, so why exactly can't someone be in the middle?  I understand that you've exchanged a secret only once, but that secret is stored on both the client and server.  Two separate attack vectors.  If you're concatenating the letters to the end of the hash, then all I need is the hash and I can login with the server.

If you're creating a whole new password from the letters sent by the server then at what point do you verify that the original password was correct?  Otherwise I can connect to the server myself, and the server happily supplies me with a new password.

  Even if send one-time passwords are "securely" hashed, the attacker
  has time.

I'm not really sure what you're referring to.

  This counter gets send to the client every time he want's to login, so
  he increases hashing rounds by the counter to match server data.

Again you're providing some other characteristic over the wire, if an attacker can see it then it's reproducible.  I don't think this adds anything to security, as any secure hashing algorithm will run through enough iterations on its own.

Unnecessarily Long Password Requirement

There's no reason for a 4000 character password.  For a secure algorithm this will put a performance hit on your server.  I securing hashing algorithm iterates 20,000 times over the entire password.  A 16 character string is the minimum needed for a secure password.  4000 characters is overkill.

Done Before (kind of)

It seems like the random characters provided by the server are acting as a random salt.  However, since they're restricted to letters they're not going to be nearly as effective.

Check out Salted Password Hashing - Doing it Right


What are the implications of activating "obtain DNS server address automatically"? There's a (private, password-protected) WiFi network (not under my control) which at first did not work* for my laptop - until I disabled the option that caused it to use google's DNS server.
[*] not working means that the laptop was connected to the LAN, but had no internet access.

(source: windowscentral.com)
What are the security/privacy implications, if any, of using one or the other? Is it a sign that something fishy is going on if 8.8.8.8 is not working?

Well, I can imagine legitimate reasons why a network administrator would want to block access to Google's DNS. After all, you're basically telling Google about every host you're connecting to. To Google, that's very valuable information since without it, they'll be tracking you on the WWW only. By using their DNS as well, you're giving them everything there is to know about your movements on the internet.

On the other hand, a locally administered DNS can in principle do lots of other sinister things, for example redirect you (visibly or invisibly).

In the end, you simply have to think about who operates the network, what their interests may be and how you can trust them. Or just ask.


Is SSL Tamper Detectable? I know how SSL provides security against people reading your messages - by encryting the message with a SYMMETRIC KEY, which was exchanged during SSL Handshake with the help of ASYMMETRIC KEYS. But I could not find out where it was tamper proof (someone tampering the encrypted data). Is SSL Tamper Detectable? If yes, how?

SSL is "tamper-proof" in the following sense: no third party may alter the transferred data in any way, without the receiver being made aware of the tampering. Of course, an attacker can always cut the cables, disrupting communications ! But no alteration goes unnoticed, thanks to the use of Message Authentication Codes by SSL.

Note that SSLv2 did not include a "safe end" feature: an attacker could force a connection close at any point, and the receiver could no know whether this closure was from an attacker or really triggered by the peer. This was fixed in SSLv3 and ulterior versions (TLS), which include an explicit administrative message (close_notify) marking the will of one of the SSL parties to close the connection (this administrative message is covered by the SSL MAC, and thus cannot be forged by an attacker).

Among the cipher suites which SSL clients and servers can negotiate are some integrity-only cipher suites, such as TLS_RSA_WITH_NULL_SHA, which use MAC only but not encryption -- so you can have tamper-proofness without confidentiality, if that's what you want (deployed SSL client and server implementations rarely allow for these suites, and certainly not by default, but they are specified by the standard.


Would authorisation codes in Star Trek be secure in real life? I'm watching Deep Space 9 and I've noticed that they use spoken authorization codes when commanding other ships, computers, ... In the show it looks like "Authorization Some-Name 5 7 3 5 blue", then the other person types it into the computer (and looks up in fear, says "I didn't know" and files away).

Using a single code is obviously not good enough, because everyone around can overhear it, so I was thinking that maybe everyone can have a pre-generated list of these passwords both memorized and stored in a central computer and when verifying the last used code would be invalidated.

Would such a system be feasible in real life? How strong would it be?

I'm thinking about implementing a scheme like this for my home server when accessing it from the internet (mostly for the hack value, though), so I'm also interested in implementation details -- for example how to store this kind of passwords on the computer (probably hashes of all of them, right?).

You could setup the Google Authenticator and use the Google app to allow access. This comes the closest to your OTP idea without building anything yourself. If you want something more fancy, you should look at tiny RSA tokens, the kind used for SecureID.


Managing trusted certificates revocation in containers in as "cloud native" means as possible This is a bit of a tough question to ask so bear with me a bit. I'll try to be brief if I can.

Problem statement

I'm looking for a modern best practice for managing and deploying the trusted root CA certificate list of Docker containers. I know I can bake the certificates into each container through a Dockerfile. However, that is a new docker image for each container every time we need to make a certificate or CRL change. Ideally in the spirit of "cloud native" (see 12 factor apps) our containers would have no certificates and CRLs baked into them and this would all come from the environment somehow.

To give a bit more context. I'm running these containers in Kubernetes, but they could run in any container platform such as OpenShift, AWS, etc. and ideally my objective here is to come up with a single solution that allows for true container portability.

Potential solutions

Some ideas I have toyed with:

1) create another container that has all of the certs and CRLs and volume mount that to each container.
- This is a common approach but requires the container to be saved to a new image every time a new cert or CRL has been updated. Not awful, but it doesn't feel very "cloud native".

2) Use the Spring Config Server and build a little Spring Boot sidecar that installs all of the certs at startup.
- The external centralized config feels cloud native.
- May require heavy modification to the start order of services in the container that may require those certs.
- Feels too complicated for a container.

3) Use a proxy where all certs are managed.
- Feels like a hack to force all traffic through the proxy.
- Possible throughput and contention issues when there is heavy loads to HTTPS resources.
- May not be feasible to route everything over straight HTTP.

4) Use environment variables and have a start up script that installs them
- Simple and generalized approach for any type of container deployed anywhere. I'm not sure if it's appropriate to do it this way. Those would be a lot of big environment variable values. Can you imagine what a "printenv" will look like?

5) Use Kubernetes Secrets (not sure this can work yet)
- It's a kubernetes only solution which is a downer for write once, use anywhere.

I know this is a bit long winded. I apologize for that. I didn't know how to compress it any further. I am looking forward to the discussion on this.

A solution that emerged from chat / comments:

Post a tarball of what the trust store should be at some static URL -- you have the ability to update this at your convenience.
For the TLS cert on this URL, use a cert that the docker container will trust in its default configuration -- from a publicly-trusted CA or a private root CA explicitly for this purpose that you manually add to the docker template. Let's call this the bootstrapping CA.

Where you need to put the bootstrapping CA cert depends on how you're fetching the tarball. For example, with curl:

$ curl -O https://my.server/docker_root_cas.pem --cacert [file]

Since CA certificates are public information, just drop the CA cert anywhere on the filesystem (of course making sure an attacker can't modify it pre-bootup. But if that were true, you'd have bigger problems...)

You have now securely fetched the list of trusted CA certs. This also leads to an easy update mechanism by having containers periodically pull the list again either from this URL or from one protected by a TLS cert that chains to one of the CAs that you just imported.

Security considerations

The docker image needs to be protected against an attacker replacing the bootstrapping CA file with their own.
The server hosting the tarball becomes a big target, so harden it well. Doubly-so if you have an update mechanism where containers continue to pull updated trust stores periodically because now a compromise of the tarball server will compromise all new and all existing containers in one fell swoop.


Is viewing applied group policy on a client PC not considered a minor security breach? A client on a company can run commands and view the Group Policy settings applied to his own account and computer.

The commands are:

gpresult (and all of its variants)
rsop.msc

In my opinion, telling a user what is being enforced upon him can have a minor flaw, as the security administrators will sometime prefer obscurity when it comes to internal users, not knowing what is their security level etc.

Is viewing applied group policy on a client PC not considered a minor security breach?

In general, in a corporate environment, the rules under which staff should operate should be very transparent, as should the controls which enforce these rules.

Being able to view the group policy is rarely a security breach as it shouldn't be leaking information which is meant to stay hidden. The valuable part of the policy is the enforcement of permissions and access etc.

Security through obscurity is generally a bad thing in corporate environments (as well as many others) as it doesn't actually provide security against attackers or against accidental breaches.


Is it true that meltdown and spectre were intended as debug tools? I heard from a guy that's involved in low-level (assembler, C for drivers and OSes) programming, that meltdown and spectre weren't actually vulnerabilities discovered only so recently, but they were openly known as debug tools. It seems quite unlikely, but could anyone confirm or deny this?

It's not even remotely true.  Although you can use a Meltdown or Spectre attack to inspect the internals of a program in the way a debugger can, a proper debugger is much faster, easier, and more reliable.


How to get the certificate of the Client a client send data to a server over a ssl-encrypted connection.
i want to know which certificates are used. (server want a client-certificate)

to got the server certificate with:

openssl s_client -connect 192.168.254.208:40004 </dev/null 2>/dev/null | openssl x509 -outform PEM > cert.pem

but how to get the client-cert?

ist this possible with openssl s_server?

or can I use a simple python ssl-socket? (i have access to the certificates and keys from the server.) I only want to know which certificate the client sends.

is this possible with openssl s_server?

Start a test server which requires a client certificate. The certificate send by the client is shown as PEM in the server output:

openssl s_server -cert ... -verify 2

  can I use a simple python ssl-socket

The peer_certificate method can not only be used by the client to get the server certificate but also by the server to get the client certificate.


Why does not updating a MacOS keychain password cause applications to become troublesome? I've changed my Macbook computer's password in using recovery mode. I'd changed it once normally, then it suddenly "stopped working" (or I started "mis-remembering" it after using it a few times, which is not likely, but not impossible).

As I continued with the recover mode, I received the message (photo of screen shown below):

  The system was unable to unlock your login keychain.

Since I don't use my keychain at all, and since I did not understand the implications of each choice, I just selected Continue Login.

Once I was using my computer again, I have a persisting sequence of dialogue boxes that will not go away no matter how many times I click Cancel. They seem to interfere with other applications strongly, rendering them unresponsive (beachballing sometimes) until I cycle through them once or twice by clicking Cancel three or six times. Preview is particularly difficult to use now. Using menu items with the mouse is okay, but when I use hot-key's for copy/paste or arrows to move between multiple images, I then have to attend to the keychain dialogues again. It seems keystrokes are triggering them.

Question: I am not only asking how to stop this, but also asking why this is happening? Why is getting a keychain password so strongly linked to trying to use Preview, Chrome, and other applications, since I've never intentionally used the keychain? Is there any way to get this under control without updating my keychain password - something I do not use and don't see why anyone else should be able to use either?

This behavior makes me wonder if something else unknown to me is using or wanting to use the Keychain, which might be alarming!

Well, the Keychain on macOS is the place for applications to store sensitive data such as credentials, certificates and the like. For instance, Keychain stores the passwords for all wireless networks you join. Chrome might use it to obtain a list of trusted root certificates for your system. Messages uses it to store its tokens. Why certain applications use the Keychain is an implementation detail we cannot fully explain here. Most likely, the app stores or accesses some kind of data that it deems sensitive. What you are experiencing happens all the time on macOS (see links below) and does not indicate your system is compromised.

Now, the Keychain is by default secured by your account password and unlocked automatically during boot. When you change your password, the Keychain password is not automatically updated. You need to either update the existing password or create a new Keychain. Since you claim you do not use the Keychain, the simplest solution is probably to just create a new Keychain and be done with it.

See here, here or here for possible solutions.


Is PHP's eval() function vulnerable to code injection when executing a string built from an array? I'm trying to learn more about PHP eval() exploitation and I came across this scenario:

<?php

$test = array();
$test[0] = "command0 ";
$test[1] = $_GET["cmd1"];
$test[2] = "command2 ";
$test[3] = "command3 ";

$params = "";
for ($i = 0; $i < count($test); $i++) {
        $params .= "\$test[$i]";
}

echo $params;
echo "
";

$cmd = "echo \"" . $params . "\";";
echo $cmd;
echo "
";

eval($cmd);
?>

I've tried to inject several combinations of double-quotes and backslashes into the $_GET parameter but have had no luck breaking out of the $cmd string.

Beyond the XSS bug, is this code snippet vulnerable? Can this be abused for PHP code injection?

No, this is not vulnerable to PHP code injection.

The string passed to eval() is simply not user-controlled. There is no path from the source $_GET["cmd1"] to the sink eval():

The argument to eval() is $cmd.
$cmd is assembled from a fixed string and $params.
$params is accumulated from a fixed string and $i.
$i is an iteration variable that depends on the (fixed) length of the array $text.

That said, passing a generated array through eval is certainly not good style and you're obviously not sanitizing output which makes the code vulnerable to XSS.


How can a non-technical user verify a message was sent "securely"? ...or over TLS? I have a situation where B2B and B2C communication needs to be sent securely and not visible to most SMTP hijackers. I don't care about conspiracy theories or NSA style attacks, but want to provide reasonable security for individuals who don't want their PII data exposed to less capable attackers.

This business requirement comes from Massachusetts data privacy laws that require PII for residents to be sent "encrypted" without much further elaboration of the technical requirements.

Our client's business relies heavily on email and the ability to send PII for life insurance,  health insurance and other financial products.

To that end, I intend to use TLS to provide this security due to its ubiquity, ease of use, and that it co-operates well with financial compliance requirements.  I envision creating a direct TLS tunnel between partner's MTA and ours.  (Forced TLS not opportunistic)

The problem is that TLS "security" is buried in the SMTP headers, difficult to understand, and the borders of administration are hard to delineate.  e.g.

  company1 ---->  MSFT Hosted Relay  -->  [TLS between providers] ----> Google Hosted --> Company 2

  company1 ---->  Proofpoint         -->  [TLS between providers] ----> Google Hosted --> Company 2

Question

Assume an insurance company needs to send a SSN in an email message (body or attachment).  The next hop MTA is a Gmail, Yahoo, or other trusted private MTA.

How can I give the recipient confidence that the message was sent securely over TLS?
What alternative technical solutions or RFC would assist in giving me this assurance?  (Perhaps a variant of DMARC/DKIM + TLS?)

Your objective is to drive in a screw, and you want to use a hammer because you have one handy and it's easy to use. I'm afraid the most likely outcome is a sore thumb.

TLS is fundamentally about point-to-point security. It is only attached to the connection, not to the data. Email, on the other hand, is fundamentally designed to bounce through multiple hops. While the hops do leave a stamp tracing their actions, you would be dependent on the hosts to not be malicious (each hop can fake the whole message including the stamps of its predecessors), to not be fooled (e.g. into misauthenticating their predecessor), and to leave the stamps that you expect.

You can give the recipient confidence that the message was transmitted securely by delivering a signed, encrypted message produced by the sender. TLS is not useful for this. RFC that can help you include RFC 3156, RFC 4880 (OpenPGP Message Format), RFC 5750 and RFC 5751 (S/MIME).

In other words: use PGP or S/MIME.


How to block Evercookie There is a Javascript library called Evercookie designed to track the user. It writes cookie information into every possible location:

Standard HTTP cookies
local shared objects (Flash cookies)
Silverlight Isolated Storage
Storing cookies in RGB values of auto-generated, force-cached PNGs using  HTML5 Canvas tag to read pixels (cookies) back out --- pretty clever idea
Storing cookies in Web history
Storing cookies in HTTP ETags
Storing cookies in Web cache
window.name caching
Internet Explorer userData storage
HTML5 Session Web storage
HTML5 Local Web storage
HTML5 Global Storage
HTML5 Web SQL Database via SQLite

Is it possible to block this for all the sites except those I trust? For now the only robust way I see is to turn off javascript and cookies completely.

I am using squid HTTP proxy, can it do at least part of the job?

Blocking access to this specific library can be done with the acl mechanism in squid if you know the full URL of the library or a relevant part of the path which should of course match only against this library and not against innocent files.

If the URL is not known you can try to do content analysis using the ICAP or eCAP interface of squid. But note that the evercookie Javascript library is only an example how such a cookies could be created and while somebody could use the original library he could also modify the library to change typical variable names or just use the ideas of the library in his own library or even interweave the functionality with other code so that the whole web site fails if you try to block the evercookie. This means the chances are high that even content analysis will not result in a sure blocking of the library. Depending on how you match you might even block innocent data (i.e. false positives).


Restrict access to REST web application to authorized computers? I have developed a REST web application. The client only wants authorized computers to access the application. We have gone with 2-way TLS implementation where the client approves or rejects certificate requests.

Now the problem is that there are tools to extract the certificate from the machine even though the certificate was marked as non-exportable. We thought using the CertEnroll COM component to generate the CSR would have helped prevent exporting but marking the cert as non-exportable wasn't suffice.

The requirements are that only authorized computers can access the application and minimize the copy of permissions as much as possible.

Some options I have ruled out:

Restricted IP Addresses, there are internal users we don't want to
access the app.
Browser fingerprinting, can't guarantee users coming from browser.

You trying to prevent a certificate from being copied from a computer that an attacker has full access to (as they would be able to run tools to extract non-exportable certificates) while at the same time having the certificate accessible for use by your application. This is simply not possible.


Is rounds in a cryptography algorithm same as iterating the algorithm? In a cryptography algorithm such as AES or DES, does the number of rounds mean same as iterating the algorithm?

Example:

c= "plaintext";
for(int i=0;i<5; i++)
{
 c = AES(c , "key");
}

Where c holds the cipher text produced after 5 iterations.

If No, then

1.What exactly a round is?

2.Does iteration improves the security of the information being encrypted?

The simple answer is No.

"Rounds" are internal operations inside the AES (or DES) algorithm.  These algorithms use a mixing function that is repeated internally a defined number of times.  Sometimes you read about people cryptanalyzing "a reduced round variant of AES", they are talking about attacking a modified form of the encryption algorithm.  These may or may not indicate a weakness in the published, full-round algorithm.
It may help security slightly, it may do nothing, or it may actually harm security!  It depends on how it's implemented.  Cases where it helps are in protocols like PBKDF2, where the increased number of iterations is used to make breaking the algorithm take a long time.  Cases where it could harm include certain ciphers where a second encryption might result in a decryption of the first!  And there are cases where the intersection of two encryptions can yield information about the key.

In general, randomly throwing cryptographic algorithms at a problem in hopes of making it "better" is an extremely risky approach, and is not recommended.


Performing POODLE attack I trying to perform POODLE attack on a hosted server that I've configured to support only SSLv3. The scenario is I logged on my server and it sends the cookie in response that will be stored by the client. I need not be in middle since I'm the attacker and the victim. So to get the decrypted cookie I have to craft a POST request and replay it to my server. The crafted request will be

POST  Cookie: name="cookie value" "\r\n\r\n"body "MAC" padding bytes

So, how to get length of the cookie value since it is encrypted and it is required to add the padding bytes ?

The Poodle attack model is one where the attacker triggers the requests (normally with some Javascript in the client -- note that, in that case, requests will be GET, not POST, since that "evil Javascript" will be served as part of an unprotected Web page load from another site, and the same-origin policy will prevent arbitrary POST) and manipulates the resulting on-the-wire packets. The two parts of the attacker (the insider and the outsider) dynamically talk to each other.

Therefore, you can organize some initial discovery procedure in which the insider first triggers some requests with paths of increasing lengths, and the outsider observes at which point the encrypted request length increases by a full block (8 bytes for 3DES or RC2, 16 bytes for AES).

Of course, in practice, the attacker knows the length of the cookie of the target site, because he registered his own account to see what to expect. In many cases, the length for an authentication cookie is constant. Such a preparation step is needed for the attacker to reliably know at which point the cookie starts in the requests, anyway.


Tor "Security Slider" - What security does it provide? When opening up Tor Browser for the first time I am notified of the existence of the Security Slider. The docs explain what each security level does in terms of functionality.
I haven't found a solid answer on what threats I would be protecting myself from at each level.

Why should I set the slider to High rather than Medium or Low from a security standpoint (known exploits/attacks, attack vectors), rather than anonymity standpoint (though not to be disregarded)?

The Security Slider allows you to choose compromise between security and convenience.

At normal, convenience is first. All features are enabled.

At safer, javascript over HTTP is disabled. This is important as without using HTTPS, an attacker (for example an exit node) could inject malicious javascript. Also, video and audio playback often has security problems, plus ads use it to be annoying, so it is disabled. I am not sure why symbols are disabled, but I suspect there may be either rendering problems (symbol going beyond the space it is supposed to be in) or crashes similar to all those UTF character freezes and crashes on mobile phones.

At safest, all javascript is disabled by default. This will in addition to preventing MITM injection also prevents XSS attacks and intentional attacks by the sites you visit.


HTTPS but NOT encrypted? I'm accessing Bing (https://www.bing.com) from within China. I got the following information:

How could this happen? HTTPS but not encrypted, and with SSL certificate?

Here is the packet capture using wireshark. Bing's IP is 202.89.233.101 .

A new capture.

Edit for the pcap: my theory does not hold; the other points are still valid.

I will keep my original, speculational, answer, but TL;DR: if resources are loaded via http, such a warning is warranted.

As the comments go, this seems to be a warning about non-https resources used on the website. This might trigger warnings of that kind and for a good reason:

If scripts are loaded in such a way, a man in the middle can inject scripts that compromise every interaction with such a website (and even more, in case of an exploit being available to the attacker for your browser). Additionally, even other resources could lead to code being executed that was not intended to run in that context.

Now my original answer:
This might be a downgrade attack that is allowed by Microsoft.

First off: TLS has two different purposes:

to authenticate the server (and optionally the client) via a public key infrastructure.
to evaluate which encryption capabilities server and client share and choose one of them over an insecure connection.

While the server has been authenticated, it seems that the server and you have established a plain text „encryption“.

Secondly: this might be useful if the client (or server) has very limited computational capabilities. As a mean to allowing access (availability) over secrecy, this can be useful.

Thirdly, my speculation:
In this case, it is possible that bing is only allowed operation in China as long as the great firewall can look inside the traffic. Thus, Microsoft might have chosen availability over secrecy, making use of the plain text option to allow for deep packet inspection by the GFC.


VMware Workstation 9 Security Best Practice Guides Could someone please be able point me in the direction of where I could find some best practice security guides for VMware Workstation 9 please? I've searched the VMware site and to say it's badly organised is an understatement! I've been able to find general setup guides but nothing with a specific focus on security.

I'm also wondering is there any best practice guides that I should follow when installing Windows 7 Professional and Windows Server 2008 R2 on VMware Workstation 9? I obviously will be implementing Microsofts recommended security best practices but I'd be very interested in any recommendations for virtualizing these operating systems.

Any help is much appreciated.

I suspect the issue is that hardening guides are usually aimed at data-center virtualization products, rather than personal virtualization products like Workstation.

VMWares security section, for example, only has hardening guides for vSphere. These are worth looking at, as is the SANS guide to hardening virtualization, but you will probably have to skip a lot of parts that don't apply.


dns reflection attack vs dns amplification attack Over the past few weeks I have heard discussions about a DNS reflection attack and a DNS amplification attack.

Is there truly a difference between the two or are people just using 2 different names for the same attack method?

DNS Amplification Attack definition 1

  A DNS Amplification Attack is a reflection-based Distributed Denial of
  Service (DDoS) attack. The attacker spoofs look-up requests to domain
  name system (DNS) servers to hide the source of the exploit and direct
  the response to the target.

DNS Amplification Attack definition 2:

  A DNS Amplification Attack is a Distributed Denial of Service (DDoS)
  tactic that belongs to the class of reflection attacks -- attacks in
  which an attacker delivers traffic to the victim of their attack by
  reflecting it off of a third party so that the origin of the attack is
  concealed from the victim.

If you google "DNS Reflection Attack" what is resolved is a list of DNS amplification attacks.

US-CERT only notes of DNS Amplification Attacks.

Both definitions denote that the amplification attack is a class or part of a reflection attack.

What is the difference between just a DNS reflection attack and a DNS amplification attack?

Full disclosure, I work for a company that develops DDoS mitigation and web application firewall services

DNS amplification is a Distributed Denial of Service (DDoS) attack in which the attacker exploits vulnerabilities in domain name system (DNS) servers to turn initially small queries into much larger payloads, which are used to bring down the victim’s servers.

DNS amplification is a type of reflection attack which manipulates publically-accessible domain name systems, making them flood a target with large quantities of UDP packets. Using various amplification techniques, perpetrators can “inflate” the size of these UDP packets, making the attack so potent as to bring down even the most robust Internet infrastructure.

DNS amplification, like other amplification attacks, is a type of reflection attack. In this case, the reflection is achieved by eliciting a response from a DNS resolvers to a spoofed IP address.

During a DNS amplification attack, the perpetrator sends out a DNS query with a forged IP address (the victim’s) to an open DNS resolver, prompting it to reply back to that address with a DNS response. With numerous fake queries being sent out, and with several DNS resolvers replying back simultaneously, the victim’s network can easily be overwhelmed by the sheer number of DNS responses.

To amplify a DNS attack, each DNS request can be sent using the EDNS0 DNS protocol extension, which allows for large DNS messages, or using the cryptographic feature of the DNS security extension (DNSSEC) to increase message size. Spoofed queries of the type “ANY,” which returns all known information about a DNS zone in a single request, can also be used.

Through these and other methods, a DNS request message of some 60 bytes can be configured to elicit a response message of over 4000 bytes to the target server – resulting in a 70:1 amplification factor. This markedly increases the volume of traffic the targeted server receives, and accelerates the rate at which the server’s resources will be depleted.

Moreover, DNS amplification attacks generally relay DNS requests through one or more botnets – drastically increasing the volume of traffic directed at the targeted server or servers, and making it much harder to trace the attacker’s identity.

My company provides various solutions to protect yourself against DNS attacks. Please read more about how you can mitigate these sort of attacks: https://www.incapsula.com/ddos/attack-glossary/dns-amplification.html


Responder mitigation The Responder tool can grab the netntlm hashes of clients on a Microsoft AD network by either using LLMNR to answer queries "accidentally" made by clients by responding as otherwise nonexistent SMB servers, or by responding to WPAD to insert itself as a local proxy server which can require Windows authentication in order to grab the same hashes.

Can this be mitigated by requiring SMB signing by clients on the network? i.e. Would this prevent the client from sending its response to the authentication challenge because the authentication challenge wasn't signed?

I sometimes read about the mitigation being to disable LLMNR, however it seems to me that the same could then be achieved via ARP spoofing or via DNS poisoning (i.e. sending a response to clients because you are suitably positioned to view requests), albeit this would be limited to the current network segment only. Is this correct?

Can this be mitigated by requiring SMB signing by clients on the
network? i.e. Would this prevent the client from sending its response
to the authentication challenge because the authentication challenge
wasn't signed?

No, according to this NCC article:

Note that while requiring SMB signing can prevent the relaying of NTLM
authentication to an SMB server, it does nothing to prevent either SMB
or HTTP NTLM authentication from being relayed to an HTTP server. SMB
signing also does not prevent the capture and offline cracking of the
NTLM challenge response.

The recommended mitigations are as follows:

Disable Broadcast Protocols

NetBIOS over TCP/IP
LLMNR

Network segregation
Apply the principle of least privilege

So it appears there isn't actually a solid way to prevent hashes from being MITM'd. The above reduces the likelihood, but doesn't set the risk to zero.
Enforcing long passwords (15 characters and more) and encouraging users to select passwords based upon passphrases can help mitigate captured hashed being cracked and then used by an attacker.


force uploading a file to a server with an open port Recently my web server was hacked. someone uploaded a php file manager called extplorer and changed all of my web pages and i was wondering what possible ways they could of uploaded something to my server without direct access to it i know that you can sometimes execute a php script on a servers webpage if it is not designed correctly but i had no entry points like that and i just had php installed in case i needed it i wasn't using it anywhere and i didn't have anything else installed on that system there was not ftp or ssh are there any other methods the attacker could of used to get those files in the root directory of my server?

As @SmokeDispenser mentioned in is comment, this is a very broad question, so the list below is very general.

Stolen Credentials - You need to be able to update the PHP files yourself, so you need to have some sort of interface to do that.  It's possible that an attacker stole those credentials and used the interface just like you did.
Remote Code Execution Bug - It's possible that your code has a bug which allows users to execute arbitrary code, and the attacker exploited this to download the file to the server.  If you are using a framework, such as Wordpress, cakePHP, etc., the bug might exist in that software.
Another with another application on the system which allowed the user to gain access to the filesystem.

The first two items are the most likely attack vectors.  Do you know the original owner of the file?  That might be the best clue as to how that file was created.


Verifying users location & authenticity I am builduing a business to business website, and users are able to sign up with a personal profile and create a business (like linkedin).

I need to verify the following:

Business Name
Representative First & Last Name
Address
Phone Number

Other business sites such as Groupon (wikihow article) verify identity by contacting each user (I'm not familiar if they ask for a business regestrition copy or how do they verify once they contact you).

But this seems slow, expensive and annoying, yet probably an effective way to verifying.

I was thinking of the sms verification code, that way I can takle down Location & Phone number, but there is all sort of way around this...

Is there a more effective way of verifying business/business owners identity and location?

One possibility: you could look up the company in Dun & Bradstreet database of businesses, look up the contact information for their professional contact, and contact the person listed in D&B to request verification of the business's status.

Another possibility: if the business has a Google+ business profile or a Facebook business page, you could use various methods to have them prove ownership of that profile.  In that case, you'd basically be outsourcing verification to Google or Facebook.  I don't know how secure that is.


How does varying character type increase strength of password? When creating a new password, people often recommend you use both uppercase and lowercase characters, numbers, and symbols. How does adding any of these increase the strength of a password?

There are 26 lowercase alphabet characters. Lets assume that there are 100 characters in the entire group of capitalized alphabet characters, symbols, and numbers. Now let's look at any password of length 6. There are (26 + 100) ^ 6 possible passwords of length 6. A hacker would have a [1 / (26 + 100)] ^ 6 chance of guessing such a password. The hacker has no way to tell if you used only lowercase alphabet characters or you mixed lowercase alphabet characters with special characters, so he must guess with the entire sample space on each character. If, however, he knew you were only using lowercase alphabet, then, yes, the probablity of guessing your password would increase to (1 / 26) ^ 6. But in the real world, a hacker wouldn't be able to figure which set of characters you used.

Your assumption is that attacker password guesses are uniformly distributed among the domain of potential passwords. This assumption is incorrect: guesses are skewed toward more likely passwords, which are lower-case dictionary words as those are easiest for users to type and to remember.

The benefit of using a complex password then is that it will probably take a longer time for the attacker to try your password as a guess. Incidentally, when considering a large multi-user system, the "no need to outrun the lion" rules apply and in many cases a good password is one that's more complex than another user's. That is not always true if an attacker is specifically targeting you rather than the system.


When using Dropbox to sync Keepass db, is it ok to open it in synced folder? I'm going to be storing a Keepass 2 database file (.kdbx) in a local folder that's synced by Dropbox. Is it safe to use Keepass to open the database directly considering everything in the folder is synced?

For example, if I have Dropbox syncing C:\Users\Me\Dropbox and but passwords.kdbx in it, if I then open passwords using Keepass, would temporary plaintext files get created in C:\Users\Me\Dropbox and synced to Dropbox that would allow someone to access to Dropbox to figure out my passwords?

I'm just switching to this system of backing up my passwords with Dropbox so any tips are appreciated. I won't be storing the key file for the db in Dropbox. I won't have Dropbox startup with the computer as I only use it for backups so will manually start it periodically (the other files, like my resume/CV, I don't care if they are stored in plaintext in the cloud).

TL;DR
Is it safe to open a Keepass2 database file that is in folder that's synced with Dropbox, or do plaintext temporary files get created that could leak information to Dropbox?

The short answer is Yes, it is safe. KeePass does not write any plain text passwords to disk, instead it keeps the database and passwords in memory.


Why does OpenVPN require securely sharing certs with clients? The ubuntu docs on OpenVPN have this part in the instructions:

  Copy the following files to the client:

  /etc/openvpn/ca.crt
  /etc/openvpn/easy-rsa/keys/hostname.crt
  /etc/openvpn/easy-rsa/keys/hostname.key
  /etc/openvpn/ta.key

Isn't it possible for a vpn scheme to only require an admin to install the client's public keys in order to give a client access, instead of requiring the sharing of sensitive certs first? Are there other VPNs that do this?

Let's look at a breakdown of all the files, whether they're sensitive, and where they came from.

/etc/openvpn/ca.crt

Publicly disposable, this is the certificate for your VPN's certificate authority. It can be shared with anybody and allows the client to verify the VPN server.

/etc/openvpn/easy-rsa/keys/hostname.crt

This is a certificate identifying the client. It was signed by the client's private key and then that was signed by the CA's key.

/etc/openvpn/easy-rsa/keys/hostname.key

This is the client's private key. In the documentation you're looking at, it was generated on the server for convenience so that the client certificate could be signed by the key there and then signed by the CA key. The private key could be generated and kept on the client without the server ever seeing it, but that would make the process a lot more complex. If you're interested, do some Googling or open another question creating a private CA -- it's a whole other department.

/etc/openvpn/ta.key

This one is a bit special, so I'll just paste some related I found at http://openvpn.net/index.php/open-source/documentation/howto.html:

  tls-auth

  The tls-auth directive adds an additional HMAC signature to all SSL/TLS handshake packets for integrity verification. Any UDP packet not bearing the correct HMAC signature can be dropped without further processing. The tls-auth HMAC signature provides an additional level of security above and beyond that provided by SSL/TLS. It can protect against:

  DoS attacks or port flooding on the OpenVPN UDP port.
  Port scanning to determine which server UDP ports are in a listening state.
  Buffer overflow vulnerabilities in the SSL/TLS implementation.
  SSL/TLS handshake initiations from unauthorized machines (while such handshakes would ultimately fail to authenticate, tls-auth can cut them off at a much earlier point).

  Using tls-auth requires that you generate a shared-secret key that is used in addition to the standard RSA certificate/key:

  openvpn --genkey --secret ta.key

Summary

Yes, it is possible to share everything necessary in the clear except for ta.key if you generate the client's key locally and have a good method of verifying that you used the right keys. The system can be secure without ta.key -- it's just an extra measure to limit outsiders. That said, it's a really good measure.


Refurbished laptop computer - any advice? I just recently bought a refurbished laptop. I have seen stories of refurbished phones being sold with spyware, trojans etc installed on them. My question is, what steps should I take (outside of running a virus protection scan) before i start using the laptop to ensure there is no spyware, trojans, keylogging, etc? And this second part question may be harder (or impossible) to answer, but is there a way to be absolutely certain it's a clean laptop?

Update the motherboard firmware, manually, and reinstall the OS, reformatting the drive. It's not a complete guarantee of security, but it will get rid of 99% of the likely threats.

By "refurbished", not just "used", do you mean a proper manufacturer refurbished item? In that case your risk is somewhat lower than with a plain used item, as the manufacturer won't deliberately install malware.

There is no way to be absolutely certain. Theoretically, if you were a high value target, someone could even install a hardware chip to spy on you.


Can Penetration Testing be considered as a part of a Vulnerability Management Program? Can Penetration Testing be considered as a part of an exhaustive Vulnerability Management program?
P.S: I realise the difference between penetration testing and vulnerability assessment. But I want to know if both fall within Vulnerability Management umbrella ?

Absolutely. Penetration testing can be considered a key part of both vulnerability management and vulnerability assessments. Penetration testing is quite different to vulnerability scanning although vulnerability scanning may be one of the initial tasks performed in a penetration test to identify obvious issues in the environment.

Penetration testing within a vulnerability management program should be done when obvious issues have been addressed so the environment is subjected to a real life attack scenario. It is only at this point that the defences in place can truly be measured.


If I am trying to clean install a MacOS with internet recovery, is it safer to use mobile network than WIFI network? I just clean installed my MacOS Catalina on my MacBook due to virus on my PC that I worried got on my MacBook via usb file transfer.

I did an internet recovery to reinstall MacOS Catalina with my home WiFi network, with password protected. However, since my Pc was had a virus, I was worried that my IP addresss and home WiFi network has been compromised, can I still trust that the installation was not tempered with? Or should I perhaps reinstall it again using mobile network? Since I have heard that mobile data are much more secure than WiFi network.

However, since my Pc was had a virus, I was worried that my IP
  addresss and home WiFi network has been compromised,

I suggest you to reset your WiFi, try to check the authenticity of firmware cross-checking hash(if present) in the admin panel to the documentation provided with the product to ensure installation of wifi firmware is not tampered and then update the firmware later, change all your default WiFi password (admin login and WPA2) to complex long custom ones. Make use of mac address whitelisting on wireless router and allow only limited number of users on it. It will be added benefit if you consider educating yourself on how in general evil twin works or other general techniques to avoid giving up your secure password.

  can I still trust that the installation was not tempered with?

I am pretty sure that the installation of MAC is done after establishing secure connection to system. MAC OS is not easy to play around on the fly. Tampering should be difficult if not impossible on the connection which is established from WiFi to machine. Installation is susceptible to corruption and can break easily.

  should I perhaps reinstall it again using mobile network? Since I have heard that mobile data are much more secure than WiFi network.

Please check if the installation is clean and free from the virus detected earlier or any virus in general. This should suffice to ensure safe environment to operate and continue using current installation


Recommended key usage for a client certificate My program has the following flow: a client sends a CSR to server, the server sends back a client certificate and after that the client communicates with the server to a path that requires a certificate signed by the server (the client certificate)

My questions are:

I've set clientAuth extended key usage in the generated client certificate. Should I add any additional key usages? Maybe "digitalSignature" KU?
What does "digitalSignature" key usage mean? I have read about it as much as I can, but I'm still not sure if it's applicable to me (the best source of information I could find so far was this).
What is the practical meaning of adding this key usage? (which actions will be prevented by well behaved SSL clients/servers?) As opposed to not specifying any key usages? (only the clientAuth EKU)

TL-DR SSL client cert doesn't need KeyUsage but if present it should be digitalSignature except for very-rare-if-ever fixed-*DH.
Caveat: You tagged SSL so I assume by "path that requires a certificate" you mean SSL/TLS or something over SSL/TLS (not necessarily HTTP/S). If you mean something more like CMS or S/MIME, or XML-sig, or even PGP, the answer may be different.
I'm surprised you don't find other references since X.509 certs are so widely used. My first page of google X.509 key usage extension gives PKIX rfc5280 which is the currently effective Internet spec and (the text form of) its predecessor rfc3280; the not-terribly-good wikipedia article; and https://access.redhat.com/documentation/en-us/red_hat_certificate_system/10/html/administration_guide/standard_x.509_v3_certificate_extensions which has (possibly over-) specific instructions for several cases including SSL client. Quoting the relevant part of 5280 (which your IBM site more or less copies):
   Bits in the KeyUsage type are used as follows:

      The digitalSignature bit is asserted when the subject public key
      is used for verifying digital signatures, other than signatures on
      certificates (bit 5) and CRLs (bit 6), such as those used in an
      entity authentication service, a data origin authentication
      service, and/or an integrity service.

      The nonRepudiation bit is asserted when the subject public key is
      used to verify digital signatures, other than signatures on
      certificates (bit 5) and CRLs (bit 6), used to provide a non-
      repudiation service that protects against the signing entity
      falsely denying some action.  In the case of later conflict, a
      reliable third party may determine the authenticity of the signed
      data.  (Note that recent editions of X.509 have renamed the
      nonRepudiation bit to contentCommitment.)

      The keyEncipherment bit is asserted when the subject public key is
      used for enciphering private or secret keys, i.e., for key
      transport.  For example, this bit shall be set when an RSA public
      key is to be used for encrypting a symmetric content-decryption
      key or an asymmetric private key.

      The dataEncipherment bit is asserted when the subject public key
      is used for directly enciphering raw user data without the use of
      an intermediate symmetric cipher.  Note that the use of this bit
      is extremely uncommon; almost all applications use key transport
      or key agreement to establish a symmetric key.

      The keyAgreement bit is asserted when the subject public key is
      used for key agreement.  For example, when a Diffie-Hellman key is
      to be used for key management, then this bit is set.

      The keyCertSign bit is asserted when the subject public key is
      used for verifying signatures on public key certificates.  If the
      keyCertSign bit is asserted, then the cA bit in the basic
      constraints extension (Section 4.2.1.9) MUST also be asserted.

      The cRLSign bit is asserted when the subject public key is used
      for verifying signatures on certificate revocation lists (e.g.,
      CRLs, delta CRLs, or ARLs).

      The meaning of the encipherOnly bit is undefined in the absence of
      the keyAgreement bit.  When the encipherOnly bit is asserted and
      the keyAgreement bit is also set, the subject public key may be
      used only for enciphering data while performing key agreement.

      The meaning of the decipherOnly bit is undefined in the absence of
      the keyAgreement bit.  When the decipherOnly bit is asserted and
      the keyAgreement bit is also set, the subject public key may be
      used only for deciphering data while performing key agreement.

This is necessarily somewhat general because X.509 (and PKIX) certs were designed to be used for a range of things, not just SSL/TLS, although that's the only usage most people know about. It does distinguish several types of signing, encryption, and keyagreement (which in practice is used for encryption).
5280/3280 only mandate KeyUsage for CA certs, implicitly leaving it optional for EE certs. I don't have actual X.509 but AFAIU it says if KeyUsage is not present it is treated as all bits set, because that is compatible with v1 and v2 before there were any extensions. CABforum baseline explicitly specifies it as required for CA certs but optional for "subscriber" (meaning EE) certs.
TLSv1.2 (or its predecessors) requires a client cert "allow ... signing" except for the fixed-DH and fixed-ECDH key-exchanges which no one seems to use at least on the public net, and related sections explain how except for fixed-DH the client key is actually used only for signing handshake data to prove possession by and thus authenticate the client.
This means if KeyUsage is present for SSL client it must include digitalSignature, and since in general a crypto key should not be used for multiple purposes without strong justification, KeyUsage for SSL client should not include anything else. If the client cert does not have KeyUsage or has a non-restrictive KeyUsage, a conforming SSL/TLS implementation will still use that key and cert only in the way specified by the protocol, which except fixed-DH as noted is only signing/verifying data that is not a cert or CRL.


How to keep database record secret even from developer having access to it? Imagine a web-based email app, such as GMail. The email should only be readable by the sender and the recipients. No one else, including the developer having access to the database server or application server should be able to read it.

Is there a way to do this? If not possible, what is the best we can do?

If I understand you question correctly, you could encrypt the email before it leaves your computer and only allow it to be decrypted by the recipient.  Take a look at a product called Virtru (http://www.virtru.com). I am not affiliated with the company but am a happy user. The recipient doesn't have to be a Virtru user to be able to read your email securely (just prove they have access to the email account).  All that is stored in the database server is the encrypted message (using something called Trusted Data Format (TDF)).


How to manage admin rights for helpdesk staff? My question is about issuing administrative rights to helpdesk staff in a large Active Directory setting.

Helpdesk staff commonly require administrative rights to provide support for end users. I know that this is commonly done (see [1] [2] [3]) by creating a "Workstation Admins" group, and adding that group to the local Administrators group on each PC. Ideally, the helpdesk staff will use a low-privilege account for daily tasks, and only use their "Workstation Admins" account when needed.

System Administrators commonly do the same thing, and use an account with higher privileges when accessing servers. This makes sense because servers are trusted machines that are protected both physically and electronically. Therefore, logging in to a server with a privileged account is basically safe.

However, staff at the helpdesk will be logging into machines that were probably constantly left unattended and used for daily email or web browsing. These computers can't be trusted the same way servers can. It's easy to imagine a staff member at the helpdesk logging in to a computer which contains a malware payload that immediately spreads across the network because it has admin rights on many other computers.

Or worse, a malicious user could perform a real-life phishing scam by having a keylogger on their computer, then having somebody from the helpdesk log in.

Is there any way to give helpdesk staff the access they need without creating a significant risk? (I can imagine an ideal solution would use a one-time password for authentication, and the logged-in the user would only be authorized as a local administrator. In other words, I want the helpdesk staff to have access to ANY computer, not EVERY computer.)

Mitigation 1: Use two-factor authentication, for logging into admin accounts.

Mitigation 2: Give helpdesk staff a tablet or netbook that they can carry with them.  Instead of typing their password into the user's machine, they could log into their tablet/netbook and use the internal remote administration services to administer the user's machine.  Make this workflow as easy and frictionless as possible.

Mitigation 3: Have the helpdesk staff change their admin password regularly (once a week might not be overkill).


Is it safe to give my email address to a service like haveibeenpwned in light of the publication of "Collection #1"? There is a new big case of stolen login/password data in the news. At the same time, I am reading that there are services that let you check if your own login data is affected, e.g.
Have I Been Pwned.

Is it safe to enter my email address there to find out whether I need to change my passwords?

This question was explained by Troy Hunt several times on his blog, on Twitter and in the FAQ of haveibeenpwned.com
See here:

When you search for an email address
Searching for an email address only ever retrieves the address from storage then returns it in the response, the searched address is never explicitly stored anywhere. See the Logging section below for situations in which it may be implicitly stored.
Data breaches flagged as sensitive are not returned in public searches, they can only be viewed by using the notification service and verifying ownership of the email address first. Sensitive breaches are also searchable by domain owners who prove they control the domain using the domain search feature. Read about why non-sensitive breaches are publicly searchable.

See also the Logging paragraph
And from the FAQ:

How do I know the site isn't just harvesting searched email addresses?
You don't, but it's not. The site is simply intended to be a free service for people to assess risk in relation to their account being caught up in a breach. As with any website, if you're concerned about the intent or security, don't use it.

Of course we have to trust Troy Hunt on his claims, as we have no way of proving that he is not doing something else, when handling your specific request.
But I think it is more than fair to say, that haveibeenpwned is a valuable service and Troy Hunt himself is a respected member of the infosec community.
But let's suppose we don't trust Troy: what do you have to lose? You might disclose your email address to him. How big of a risk is that to you, when you can just enter any email address you want?
At the end of the day, HIBP is a free service for you(!) that costs Troy Hunt money. You can choose to search through all the password databases of the world yourself if you don't want to take the risk that maybe a lot of people are wrong about Troy Hunt, just because then you would disclose your email address.


Can keyloggers intercept passwords when a password manager autofills a field? I know that keyloggers primarily work by logging key presses, either through software or hardware. And some will also check for clipboard contents.

But can a keylogger (or some other malware) intercept the data when a password manager autofills a password or other field?

Offline Password manager autofills can work in two ways (at least most of them):

By copy-pasting data quickly from your manager to the site or
By simulating keystrokes for all the data on file

Both these solutions have their fair share of advantages which are listed below, but before anything it's important to note that - nothing is 'perfectly secure' from a decently featured keylogger

What does this mean? Well. By definition, a keylogger is generally assumed to be software that captures keystrokes. Now it'd be part of this program's functionality to record any keystrokes - so it would capture all passwords entered by a password manager that simulated keystrokes. However, there are other types of password managers that don't do this. But today, many 'commercially' sold keyloggers even include the capability to take screenshots at particular intervals of time and save all the contents of the clipboard to a file. The last bit is  important, because it sort of renders even password managers that use the clipboard to fill in these forms useless.

But.

Here's the thing - password managers aren't meant to prevent keyloggers from capturing  your data as this answer points out well. Quoting directly:

  "The point of keepass is not to prevent keyloggers. (Granted incidentally it will almost prevent hardware keyloggers; someone inserting a keylogging device between your keyboard and computer will not be able to observe a password you used once via cutting and pasting."

So the real solution to preventing these attacks is to monitor your system for any keyloggers or use some sort of AV solution. All of this, you've stated pretty well in your question. So:

  But can a keylogger (or some other malware) intercept the data when a password manager autofills a password or other field?

The answer to this is yes. Since we've already spoken about how keyloggers might steal passwords when they're being filled, the simplest type of malware that fits this question would be a malicious browser extension. It's simple to write a nefarious extension that saves all entered form data or sends it to a C&C server. In fact, you might even give it permission (because Chrome in question just asks you for permission during installation and you're likely to click through all requested perms without really reading them. But again, who does?)

Or if you'd like to put in a bit more effort, malware could also intercept and log all network traffic and then search the decoded output for any password fields. The real kicker here is that since it's on your device, you won't even know that you are being MITM'ed.


Asymmetric/Symmetric Encryption of a TPM key hierarchy I know that keys in a TPM key hierarchy are encrypted with their parent keys. But I read that those parent keys (for instance an asymmetric SRK) need to have some symmetric secret for said encryption. Is is mandatory to encrypt child keys with a symmetric key or can I use the asymmetric keys as well? And if I can only use the symmetric ones, how are they generated?

Because of the limited size of the possible payload of an RSA encryption, most systems use a hybrid approach. The details are usually hidden from the user: you never see the symmetric session key used in TLS or OpenPGP behind the scenes.

The TPM takes care of the symmetric key that is used to encrypt something using an asymmetric key.

When you ask the TPM to create an "RSA 2048" key, it creates a "RSA-2048 RSAES-PKCS1-v1_5 AES-128-CFB" key, and it uses the AES key in Cipher Feedback mode to encrypt stuff. You can control the details (e.g. use OAEP instead of bad old padding, use AES-256 instead of AES-128), but basically the TPM handles it - don't worry.

Pedantically, the asymmetric key stores the configuration of how to generate the symmetric key, not the symmetric key itself, but that doesn't matter. It is the same way it stores which padding scheme should be used and whether the key should be used for encryption, signing or both.

You can read about it in chapter "22.4 Symmetric Encryption" in "TCG TPM 2.0 Part 1: Architecture" from TCG TPM 2.0 publications, but it's not a fun read.


Breaching a computer knowing only IP when all ports closed - possible? I'm checking my setup for security holes with some dedicated Linux distros. First thing I did was to scan all ports, and beyond that - it seems like it's pretty much unhackable. Since all ports were closed, I feel safe, but I wonder - am I wrong?

The only way someone could hack my setup would be through some sort of malware of backdoors, which is not very realistic considering I don't download stuff I don't know about nor do I visit suspicious websites... The only concern left for me is Skype, but my ports are still closed, so the most someone could do is jack my Skype account, and even that's a maybe.

So those are my thoughts. How wrong or right am I thinking this way regarding closed ports and potential vulnerabilities excluding something you could download? Let's assume that whoever might want to hack me only knows my IP (which is pretty easy to find out in a lot of situations).

You could be breached by:

Browser exploit (e.g. this one for IE). There are browser vulnerabilities found all the time.
Through a malicious message to exploit a Skype vulnerability. The one here just causes a crash, however sometimes exploits like these can be further developed to enable code execution.
A Flash exploit allowing an attacker to gain code execution.

Even though you don't directly visit suspicious websites, any of the trusted websites you visit could have been compromised, or they could be unwittingly hosting content containing exploits like described above. For example, via adverts or via user hosted content on those sites.

Once an attacker has gained code execution, they can often create a "reverse shell" where they make your computer connect outbound to their system - incoming ports are not required. Through this shell connection they can then run whatever commands they want.

You are more secure running Linux because attackers do not target these system en-masse like they would do with Windows. However, exploitation of any client-side vulnerabilities is still possible.


Is ECB secure if I can guarantee that I never encrypt the same block twice? After reading about modes of operation for block ciphers, I've found that basically all discussions about ECB end with: "never use ECB". For example this security stachexchange answer. However my understanding is that ECB is only insecure if you may send the same block twice. So, is ECB safe to use if I can guarantee that I never send the same block twice?

For example, suppose I have a home automation system where I have a number of commands that can fit in less than 8 bytes. I then append a unique 8 byte message ID to this data to form a 16 byte block. I then encrypt this block using AES128. Thus I would never send the same message twice as I never expect to give more than 2^64 commands. Also, say I use a counter as the message ID, then I would also prevent replay attacks.

"Never use ECB mode" is generally solid advice.  Not because ECB can never be used safely, but because almost any cryptosystem that is build using EBC is going to use it in a way that ensures it will be badly broken.   Ancedotally, the most common reason I see people choosing ECB (when they do) they choose it because it doesn't require an IV or nonce, which makes it slightly simpler to implement.

That said, your understanding (and the answers to the other question linked in the comments) is correct.  ECB mode can be used securely in your scenario, if you never repeat a key/block combination.  You can safely encrypt the same one-block message twice (for instance, if you reset the counter and start over) but you must at that point switch to a new key.  Under a static key, you are correct that you must never send the same message twice.

Additionally, heed CodesInChaos' comment.  If at any point the encrypted message might be tampered with, you need a MAC to ensure its integrity.


Sharing login session from one website to another? Given two companies managing two separate websites, the client wants the user to be able to log in to one website, and then click a link to navigate to a certain part of the second website. The client wants to eliminate the need to log in a second time upon arriving on the second website.

I'm thinking the solution is

Rather than linking directly to the second website, link to a redirect page within the first site.
The redirect page would generate a random string, and notify the second website what the random string is, and which user ID and IP address it is for.
The user would be redirected to the second website with the random string included in the URL.
The second website would check the random string + IP + date/time.
Once validated, the second website would initialize a login session giving the user appropriate access.

Caveats I am aware of are

The second website's security is limited to that of the first website.
If the user logs out of one site, they would not automatically be logged out of the other one.

So my question is

Is this solution a good one, would it be secure if properly implemented?
Is there another obvious/better solution I should be reviewing?
Please let me know if there are any other caveats I should know of, or things to watch out for during implementation.

Using something like oauth would probably be easier and safer.  The main issue with it is that you can't use the user password for user level encryption, but if that isn't needed by the site the user isn't logging in to directly, then you are fine.

You have the basic idea right, in that you want the one server to be responsible for the login and the other to trust that server, but I would suggest that you want a system that relies on trusted communication between the two servers rather than a string to validate the session.  That's basically the idea with oauth, where the one system has the other system process the login and return a validation that the user authenticated.  You could hide the oauth process because the user is already logged in to the site that will validate their identity, so it could be done behind the scenes.


Sending noise over wire, using hashes of noise to carry data Imagine highly dystopian environment, where oppressive evil government MITMs over all connections and uses DPI to thwart any attempts to use TLS/SSL, TOR, I2P etc. To establish connection, these protocols first need to communicate a little in cleartext, and if DPI can identify handshake packet, connection will be closed. Using custom protocols or protocol modifications to fight this mechanism is not viable option, because officials monitor everything passing through network filter and almost immediately adapt DPI rules to new versions.

I had thought of an idea to make a protocol that would be practically impossible to create a rule against. Something that can be used to make otherwise plaintext data (protocol versions, list of ciphers, public key fingerprints, DH exchanges) look random and uniform, but yet be easily reversible.

I could think of following option:

Infinite alphabet hash substitution cipher

Each octet of plaintext string gets mapped to a large chunk of completely random data. First octet of hash of that data matches desired octet.

Encoding procedure in almost Python:

pool = {}
stegotext = ''

for octet in cleartext:
    while octet not in pool:
        chunk = generate_randomness(bytes=32)
        digest = calculate_hash(chunk)
        hash_octet = digest[0]

        if hash_octet not in pool:
            pool[hash_octet] = []

        pool[hash_octet].append(chunk)

    chunk = draw_and_remove_random_element(pool[octet])
    stegotext += chunk

Given N bytes of input, result will be N * H bytes, where H is hash function size.

Decoding procedure:

plaintext = ''

for group in split_in_groups(stegotext, group_length=H):
    digest = calculate_hash(group)
    octet = digest[0]
    plaintext += octet

However, in case some computationally simple hash function is used, it's not hard for MITM to add rule that calculates hash function over each packet, and filters on results. To protect against this, PBKDF2 or scrypt could be used, so for legitimate party it does not take much resources to accept or initiate connection, yet MITM will be overwhelmed.

Question is: does it make any sense? Is it any better than just using headerless scrypt with large r value and prepended publicly sent key?

In an authoritarian dystopian environment, the authorities aren't going to permit every network transmission they can't prove is harmful, they're going to use a default-deny rule, and only permit transmissions they can prove are safe.  In such an environment, you'll need to disguise your transmission as a known-safe protocol, such as HTTP or Telnet.

Even without that, your proposed protocol is statistically identical to strong encryption.  Any dystopian authority worth their salt is going to block anything that looks like encryption.


Digital Signature and Verification? AFAIK , When Alice wants to write a message to Bob -- she uses Bob's public key  and encrypt the message - and then Bob - using his private key - use to decrypt it.

So public key is used to decrypt and private key is used to encrypt.

But then I saw this explanation ( in digital signature conext):

here it says that the hash value(signed) is encrypted with her private key  ?

so private key uses not only for decryption(messages which sent to me) but also for encryption(hash which i calculate) ?

That's the usual confusion of "signing is like encrypting with your private key".

Just forget it. It is a terrible explanation which does not work. It just seemed to work in days of yore, when the very first digital signature algorithm (based on asymmetric cryptography) was first described (I am talking about RSA and it was in the Disco era); but even for RSA it is not correct since it fails to take into account padding, which is critical for security.

Have a look at PKCS#1 to see how RSA is used. In particular, when encrypting data with RSA and a 1024-bit key, the most you can encrypt in one go is 117 bytes, but the encryption result is always 128 bytes, and that's what a decryption engine expects. Regardless of how much you try, 128 bytes will not fit in less than 117 bytes...

What must be remembered is that a private key is what is used to do something that should not be doable by everybody. This means data decryption (anybody can encrypt a message to Bob, but only Bob should bee able to read it) and signature generation (everybody can verify a signature, but only Bob should be able to produce a signature that everybody can verify as being from Bob).

Although there are asymmetric encryption algorithms which can use the same kind of key as digital signature algorithms (there is RSA encryption and there is RSA signatures, and both use "RSA keys"), using the same key for both is not a good idea.


What does “PIN encrypted under LMK” mean? What does PIN encrypted under LMK mean? From what I understand the Local Master Key is only there to encrypt other keys. I was reading some code and I saw function names like encryptClearToLmk or decryptLmkToClear.

Does the expression have something to do with the LMK key pairs?

In short, no, because the LMK is a single key.  The Hardware Security Module (HSM) has it's own master key called the LMK, and this is generally not dealt with in the clear.  Any keys you generate will be done so using that LMK.  The functions you mentioned are used to encrypt and decrypt to/from ciphertext from/to plaintext, both procedures of which use the LMK as a shared secret to either function.  The LMK is also a symmetric key, not asymmetric. This is a gross oversimplification, but if you would like to learn more about this, take a look at the following link:

http://jpos.org/w/index.php/HSM_basics

Hope this sets you on the right track.


Find hash algorithm and work factor Knowing a password, corresponding hash value and the used salt I was able to reduce the possible algorithms used.

How can I obtain the hash algorithm used and its workfactor?

Note: This question is not a duplicate of
"How can I find what hashing algorithm was used?" as that questions doesn't contemplate the workfactor.

The work factor only applies to some hashing algorithms, so you still need to find a reliable way of identifying the hash - and most hashes are pretty much indistinguishable in terms of output, beyond having set lengths:

539080ba278cf4cf4db2e4a32642ff30
8d777f385d3dfec8815d20f7496026dc
042636dba1586150f13670473360ca06
2eb9b7b30492034d392888f72ace81a1

are all 32 character hashes of the same input. The only way to tell which is which is to try hashing them all with functions which produce 32 character output (128-bit, in Base-64 representation).

Since the work factor needs to be known in order for the legitimate user to be able to recreate the hash, it has to be stored in some way. For example, bcrypt hashes have the cost included as the second parameter:

$2a$04$BsM7V0W/.V5z.p//XMUJeu.C537J/XoMYYKuCV8vDBq65KgKiDH4.
$2a$12$noxpk3amerDxXofuz4ViS.nOsnK4TWqXnmlfj6Y8b71ERVeZ7Bj5G

In these (which hash the same string as before), the cost for the first example is 4 (2^4 key expansion rounds), and for the second is 12 (2^12 key expansion rounds).

For other algorithms, it's usually part of "common representations", else it has to be stored in code, which tends to be more difficult to update should advances in hash calculation mean that increased work factors should be used. If you've only got the raw hash, without the other parts, the only way is to brute force your way through possible work factors...


How to secure shared user on build server? We have a CI server which is installed as the builduser and all tasks are executed as that respective user at the OS level. We have many teams sharing the build server which means the build user and its resources are shared.

Each team also manages different environments and this requires ssh connectivity from the build server. Because we are driving automation, passwordless connectivity was initially setup to facilitate running automated tasks remotely  (build user's public key copied to the deploy user's authorized_keys file on the remote host).

This as you can imagine poses a security concern since any user running a task can access any environment.

One solution would be to use something like sshpass (provide the ssh password as an argument) and have different user/password combinations for each environment. At the task level create role based ACLs to lock down who can see the password as it seems like it will be in plaintext. Another concerning thing I'm curious to find out more about is the command exposure here. I have been lead to believe that users can peak into the running process and see what commands the build user has executed - is this possible without root privileges? (even better if someone can illustrate how this can be done or point me to some documentation)

Apart from validating my approach, I'm also looking for recommendations on how this problem can be potentially solved.

If the build account can execute arbitrary commands as a production user on a production server, it will need to be locked down.  Only a select group of privileged users should be able to use it, ideally without the ability to alter the (hopefully small set of pre-defined) commands.

Do you really need this ability?  Maybe there's a better solution, such as a drop area on the production server(s) that the build account can write to, complete with scripts on the production server(s) that quickly move the payload into the appropriate area (so it doesn't get overwritten), extract it, and then install it as needed.  The installation would be done with a application-specific user account rather than a generic build or deploy account.

When I have set this kind of thing up in the past, I made copious use of sudo and /etc/sudoers to limit individual users' ability to act as any role account (such as build).  I also used drop areas, which were typically either SFTP or revision control (subversion, git, etc).

Revision control is nice because the logs are more accessible than sudo logs.  Just add a tag and the cron job that runs every five minutes will recognize the tag, check out your update, and kick off a new build.  Successful completion of the build (and a smoke test suite) automatically triggers installation on a staging server, after which the QA team gets an email.  When QA is content, they add another repository tag and the staging package is installed in production.


Cloning problem of VM license keys How do software companies ensure that their product or app can only run in a given number of bare-metal or VM instances? I'm curious about the cryptography behind the scenes. What prevents a user from cloning the application indefinitely in a cloud environment?

In a virtualized environment, since the application could move around datacenters (with VM migration) binding the license to attributes like the IP or MAC could invalidate the license, which isn't the right behavior either.

One system I've seen is to use dynamic license codes.

Each time the software is run, it connects back to the vendor's server. It submits the current license code, and is issued a new one. The old license code is invalidated. If the VM is cloned, then only one clone will have the new license code.

Drawbacks with this system:

Internet access is required to run the software.
Legitimate users can lose the license code, for example, if they use System Restore.
It is still vulnerable to cracking - someone modifying the application code to tamper with license checks.

In the example I saw, the need for Internet access and vulnerability to cracking were considered acceptabe. However, the System Restore issue was not, and led to them stopping using this approach.


Security of KeePass and Yubikey OATH-HOTP How secure is KeePass in addition with a Yubikey with OATH-HOTP?

I read in Yubikey with KeePass using challenge-response vs OATH-HOTP that with OATH-HOTP there isn´t added a real second factor.

But what I don´t understand is that without the plugin and only with the master password I can´t open the database. The only way I see is to open the database with the "recovery" key.

So I think with OATH-HOTP you can use longer password (master password + OTPs) because you have to memorize a shorter master password. Thereby the security is increased if you use a long "recovery" key for OATH-HOTP.

Is that right?

You can not use HOTP for encrypting data. HOTP is a symmetric algorithm that relies on an authenticating party to verify the OTP value, which the user enters.

The OTP value is calculated based on a shared symmetric key and a counter.

shared means, that the user (in his device) and the authenticating party (usually the server) both have the very same key to calculate the same value. The security lies in protecting this key! Everybody who has the key (well, an the counter, but this is no problem) can calculate the OTP values.

In the keepass scenario the authenticating party is the program or better the vault-file. But you encrypt the vault file, since you want to avoid compormizing the data in case the file is stolen.

Now there is no easy way to protect/encrypt the secret shared key, if this is what you want to use to encrypt the data. You somehow encrypt the data with the data itself.

You could however try to initially encrypt the secret key and the data encryption key with the next OTP value. When the user enters the next OTP value which he can calculate with his OTP token, the secret key and the data encryption key could be decrypted. Then keepass could calculate the next (n+2) OTP value with the decrypted secret key and re-encrypt the secret key and the data encryption key.

But honestly there are so many possible flaws in such a setup, that it is much likely that you will loose your data rather quickly. Simples thing is that you push the button of your OTP token twice... or ten times.
keepass would not have ten versions of the encrypted secret key and data encryption key...

So you might end up encrypting the secret shared key with the static password. Hm. Then all your security only depends on the strength of this static password and you end up with... ...guess what: one factor.