How long would it take to bruteforce a PGP-Encrypted-Mail?

OpenPGP (including the widely-used "GnuPG" program gpg) typically uses two keys when encrypting an email: the content itself is encrypted with a symmetric key (which is randomly generated by the sender), and then the symmetric key itself is encrypted (by the sender) using the recipient's public key. Brute-forcing either of these keys is sufficient to decrypt the message.

However, asking "how long will it take to brute-force a key?" is kind of like asking "how long will humanity survive as a species?". There are some factors we can control today (key size, cipher used, and entropy source), some that we can imperfectly prognosticate about based on past trends (Moore's law, total amount of compute resources available to an individual or an organization, etc.), and some that are basically total guesses that might have a breakthrough tomorrow or might never get further (with specific relationship to the algorithms in question) than they are today (quantum computing, theoretical mathematics, cryptanalysis in general). Finally, who is doing the breaking? The NSA has access to a lot more compute resources, and possibly more advanced algorithms, than either of us is likely to have available. The timelines (for reasonable choices among the stuff we can control today) range from "a few months" to "beyond the heat death of the universe".

A few more specific points:

The asymmetric (public) key used to wrap the symmetric key is probably the weakest point most of the time. People tend to not rotate public keys very often, so they're most likely to have been generated relatively weakly (using strength that was considered sufficient years ago but might not be considered sufficient anymore) or using an old random number generator that was found to have weaknesses. For RSA public keys in particular, see https://crypto.stackexchange.com/questions/8687/security-strength-of-rsa-in-relation-with-the-modulus-size for a discussion of the relationship between key size and amount of entropy. For other public key algorithms, though, the relationship is quite different (elliptic-curve keys, for example, achieve what are considered the same amount of entropy as RSA keys in vastly shorter key sizes).
Public key algorithms in general (and RSA in particular) are also more likely to be vulnerable to quantum computing, if that ever goes anywhere. For a symmetric algorithm, quantum computing would probably roughly halve the effective key length; a quite-secure 128-bit key would become effectively a dangerously-insecure 64-bit key, but a 256-bit key would remain very secure at 128 bits of effective entropy. If you expect quantum computing to go anywhere within the time window that you need your email to remain secure, you may want to treat our current algorithms and recommended key strengths as being as obsolete as Enigma machines.

Some math (and its underlying assumptions):

Assume a modern cryptographic processor can try 2^30 (roughly a billion) keys per second. This isn't too far off from what a typical commercial Intel or AMD CPU can achieve using its hardware-accelerated support for the AES symmetric cipher.
Assume that the attacker has access to a decent cluster of such processors - nothing you'd need to be a nation-state to have, but something a well-resourced individual could assemble or purchase in cloud compute time - of perhaps 2^10 (1024) such processors.
Assume that the increase in compute power per money goes at a rate of doubling every two years (this is roughly in line with Moore's Law, a little lower than it historically ran but it has been seeming to run into limits recently).
Multiply that all up, and an attacker can try 2^40 possible keys per second right now, and that exponent will increase by one every two years.
Assume that if the brute-forcing attempt will take longer than 2^25 seconds (just over a year), it'll be faster/more effective to wait and build the brute-forcing rig with more-advanced future technology.
Assume quantum computing doesn't go anywhere, and there's no major breakthrough in cryptanalysis of the encryption or key-generation algorithms that were used.
Here's how long it'd take to fully brute-force a given key strength (measured in entropy; maps exactly to size for symmetric keys but you'll need to apply the appropriate transformation for asymmetric keys) given the above assumptions:

56-bit key: Less than half a day.
64-bit key: Half a year (starting today).
80-bit key: One year of brute-forcing after 30 years of tech improvement (or roughly 33 thousand years with today's tech).
96-bit key: One year of brute-forcing after 62 years of tech improvement (or over two billion years with today's tech).
128-bit key: One year of brute-forcing after 126 years of tech improvement (or many times the expected lifetime of the universe, with today's tech).
192-bit key: One year of brute-forcing after 254 years of tech improvement.
256-bit key: One year of brute-forcing after 382 years of tech improvement.

Remember that these are numbers for what a moderately wealthy / capable individual could do, and that we're assuming they're willing to work on it for a year per key. A large company, university, or government agency could certainly throw more resources at the problem, cutting the brute-forcing time to a fraction of the estimates above (or cutting a decade or more off the development time... but not both).

Of course, the high-end numbers are totally meaningless here; the sheer number of assumptions of "things continuing as they have" that go into them - including no major breakthroughs that make decryption easier, the continued increase in availability of compute power, and the continued existence of humanity or anything else that would care - mean that they have error bars possibly larger than their already-large timeframes.


I am Timothy Hobbs, the author of subuser.  I'd like you to first read my article on subuser's security philosophy so that you can see what I'm aiming for.  I'm aiming for protecting a wide user base from run of the mill attacks, and not for protecting specifically targeted users from the NSA/other nefarious organizations.

First of all, docker doesn't yet support user namespaces. This means that every 'container' runs as root on my host, even if it's isolated by lxc.

While current versions of subuser still build the image as root, subusers do not run as root unless specifically specified to do so.

this also means that, if I follow subuser's recommendations, I have to add my user to the docker group. since dockerd runs as root, having access to it means that I have full access to the whole host filesystem as root, I can run privileged containers, etc. If this isn't enabling privilege escalation (even if not from 'guest' apps, I hope), I don't know what it is.

It is true that Docker, and as consequence, subuser, gives the normal user full root privileges.  I do consider this to be a flaw in Docker.  I will certainly try to alleviate this problem, if the Docker folks don't do it for me.  However, on a single user system, I do not believe that it is a security problem for the normal user to have root access.  Because if someone gets control of the normal user, that is just as bad as root.  It's really a question of what you are trying to protect: system integrity or your data and your privacy.

furthermore, let's say that I'm running chrome in subuser. Now I have a chrome browser running with its sandbox disabled (one less layer) inside another sandbox under the root user. Is it really a benefit from simply running chrome with its sandbox under an unprivileged user?

Chrome is a special case.  It is the only program that I have come across that has this limitation.  I do not recommend that you run chrome in subuser.

I'm starting to think that the least cumbersome solution would be to simply use standard unix users. One user per application, maybe install an app and its dependencies under ~local, ~bin, etc.

I certainly considered this approach when designing subuser.  However, sharing files between users is either messy, insecure, or both.  Furthermore, you can't simply display x11 windows from other users to your user's x11 server.  You have to set up XPRA, VNC, RPC or some other network solution.  This is tedious, and one of the main goals of subuser is to eliminate the tedium of such a setup.

which package managers support installing a package, mantaining a package tree, as a user inside a user's home directory? are there any third party package managers for linux that support this?

There are many package managers that support installing programs as normal users.  You can see an incomplete list http //subuser.org/related-projects.html (not enough reputation to post more than 2 links) on the subuser website.  Just scroll down till you get to zero-install.  Of course, these package managers don't do anything in terms of security.

````
how would you share files between users? I'm thinking of the possibility of running an unprivileged ftp daemon on localhost, let's say as a 'standard' or 'storage' user and use virtual users to export parts of that home dir (eg, /home/me/apps/webdownloads) to other users, applications, and mount that via fuse.

Is this reasonable?
````

The sub-identity toolkit http //ccl.cse.nd.edu/software/subid/ (not enough reputation to post more than two links) provides a tool named subuserchown which assists in sharing files between users.


Does the endianness used with an encryption algorithm affect its security?

Firstly, let's make sure we get endianness:

// needs a C99 compiler like gcc. Will work with msvc as well.
#include <stdint.h>
#include <stdio.h>

union endian_test
{
    struct
    {
        uint8_t a;
        uint8_t b;
        uint8_t c;
        uint8_t d;
    };
    uint32_t x;
};

int main(int argc, char** argv)
{
    union endian_test e;
    e.x = 0xAABBCCDD;
    printf("%x %x %x %x", e.a, e.b, e.c, e.d);
}

If your system is little endian, you'll get DD CC BB AA as the output and big endian will give you the opposite. All we're doing here is allowing the processor the opportunity to represent an integer in whatever endianness it uses, then using  a little C trick to output the bytes in the order they are represented in memory.

AES works on 128-bit blocks, which is kind of convenient, really, since if you multiply all the field sizes in that union by four, you'd get an AES input block.

So now your question boils down to:

  If I were to reverse the order of the input of my block, would that create a security problem?

Well, that depends on the output. Let's assume something naive, like reversing the order of the input produces a reversed ciphertext, so if the input is AABBCCDD that encrypts to 12345678 and DDCCBBAA encrypts to 78563412.

This is a problem for a certain class of cryptographic vulnerability called CCA2, or a chosen adaptive ciphertext attack. As a result of the fact that the ciphertext is malleable you can then request various decryption operations be performed and whilst you do not know the plaintext, you would be able to deduce something about it. You might like to read a little on ciphertext indistinguishability.

As such, a cryptographic scheme should not be affected by endianness. If it is, or is malleable, it has some security concerns which may need to be addressed (and are, in some implementations, for example, by not providing a decryption oracle).


how do I find out where my sd card was used last

Probably not.  I'll elaborate.

FAT12/16/32 and probably NTFS, do not last I checked receive any marker from the system that mounted them as to what system used it last.  This is likely also true with ext2/3/4, jfs, xfs, reiserfs, reiser4, ufs and btrfs.

ZFS keeps a fingerprint of the last system to use the pool, but that's more for preventing damage to the pool in case the pool was accidentally moved and may still theoretically still be "active" than for "Where the hell was I just now?" purposes.

Setting the filesystem itself aside, there is a possibility that what system created the files may be something that could be determined with forensic analysis, but depending on file type this is totally not guaranteed and methods exist to fraudulently modify said markers in files that provide them as a possibility.  But, this is also not necessarily helpful because the files could have been passed from neutral device to neutral device countless times, without modification before finally arriving at your storage device.


IT security audit : is threat modelling key to reproducible success of just following a methodology (ex : ethical hacking)

You are exactly right about the need for realistic threat modeling before conducting any type of security audit. If you don't understand or realize the threat actors (e.g: cybercriminal , disgruntled inside actor), it will be very difficult to know

What security controls to audit
How to interpret the results of your security audit as the severity of any vulnerabilities / findings must be put into the context of who / what is likely to defeat / bypass your security controls

  What security controls to audit

Depending on the threat actors you believe are most likely to attack the assets your are trying to protect with security controls, the criticality of each security control to be audited differs. As an example, security controls that guard against attacks from threat actors looking to attack a web application may not be as applicable (if at all) when your most likely threat are in the physical environment - e.g: tailgating of individuals through electronic doors.

  How to interpret the results of your security audit such as vulnerabilities detected

If you don't have a realistic and clear idea of who the threat actors are and the attack vectors they are most likely to use to exploit vulnerabilities detected, it is difficult to evaluate the likelihood and impact of the vulnerabilities noted. Likelihood and impact assuming exploitation are 2 key dimensions when ranking the severity of vulnerabilities, which in turn should influence how you prioritize the remediation of such vulnerabilities.


Is OAuth 1 less secure than OAuth 2 in an SPA

Basically you are leaking the secret... so its no longer a secret.
With oAuth 2 you have the option of not using a static key by implementing PKCE in your flow. meaning you can get the best of both worlds (Easy login and secured secrets).
A big difference between oauth 1 and oauth 2 is that with oauth2 you dependent on the browsers implementation of crypto while for oauth1 you need to bring your own.
This all means that unless you have additional security measures in place, and since you leak the secret, your application is not safe from abuse and eavesdropping. therefor I would go with a switch over to oauth 2 with PKCE.


What is the state of the art for forcing logout on browser quit?

The best here would be to use a combination of cookies AND Rolling session IDs in URL (where a session id is put after the Query, like thisfile.php?sess=biskgndjkgnsldgsgdj) where this session ID Changes with each request.

This ensures only one tab or browser window is valid at one specific time.

Then you use the heartbeat system. The heartbeat can easly be constructed to send like 1 beat per 4th second, giving 15 beats per minute.
And then logout the user on server-side if ALL beats are absent for a whole minute.

15 beats are not going to get "delayed or lost" due to network latency. If one single beat arrives to the destination, timer is reset and allows up to 15 beats missing again.

Note: You CANNOT prevent that sensitive information is visible in the last browser window visible, since that is often based on information cached in the client, even if you use no-cache and no-store pragmas.
Thats why you should construct the UI to require a separate action for each opening of sensitive information dataset.
Requiring a separate action also make sure you can log the access to each dataset.

Example for a Medical data application (change to fit your application):
Lets say that you in Medical application can view a patients adress, a patients medicine history and patients 10 last visits.

Instead of showing all data on same page, allowing this information to be unauthorizedly cached, you can for example instead have a button to "reveal patients adress", a button to "reveal medicine history" and a button to "reveal patients 10 last visits", all these do a request to the server.

Thus if the user of application never press "reveal patients adress", then Anonymous medical data is going to be cached on the client.

If application has some sort of transaction log containing highly sensitive data, its better to split it up in Days, weeks, months or whatever is suitable with regards to how frequent events is, so each block of log data must be opened separately.


List of PKCS7 certificate file extensions

The S/MIME standard (RFC 5751) in section 3.2.1 states that the file extensions SHOULD be appropriate:

certificate management message: .p7c
CompressedData: .p7z
SignedData: .p7s
SignedData + EnvelopedData: .p7m


Find and kill process that create malicious connections

Nuke it from orbit.  It's the only way to be sure.

Seriously, if you're certain your server has been compromised, the only certain way to clean it up is to wipe it clean and rebuild, this time making sure that whatever vulnerability was used isn't present.

Sure, you could spend time playing whack-a-mole, but how can you be sure that you've removed a file, when the attacker could have patched rm and ls to lie to you?  Replaced ps and top with versions that won't list the attacker's bot?  Replaced ufw to let their connections through without telling you?


Serving data from an encrypted database over an encrypted connection

Sending the private key along with the encrypted data is the same as having no encryption at all, as anyone monitoring the traffic would be able to decrypt the data.

However, if the client has its own private/public key pair and tells the server its public key, then the server can encrypt data just for that client -- this is the entire point of asymmetric cryptography. The way SSL/TLS works is essentially doing this on the fly: when a client connects to a server, they work out keys to do asymmetric encryption.

My personal recommendation is to just use TLS for securing the client<->server communication rather than essentially roll your own protocol.


No, it is no Denial of Service vulnerability. Even if a single browser were to constantly request resources from your server, it would likely not go down.

A Denial-of-Service attack can have multiple reasons:

A vulnerability that causes the server to crash.
For example, an attacker can cause the server to read /dev/zero. As the file is of infinite length, the server never stops and hangs.
A vulnerability that causes the server to work a lot more on a response than the client for a request. This is called an amplification attack.
Many many people request resources from your server, and your server doesn't have the memory and/or bandwidth to keep up. This is usually refered to as "Distributed Denial-of-Service" (DDoD).

As you see, your "redirect to self" vulnerability really doesn't fall in any of these categories, for multiple reasons:

Any modern, non-malicious browser will stop redirects after a certain amount, and display an error message, as answered by Joseph.
Even if that were not the case, URLs can only have a limited length, so you would end up with ~100 requests, not infinite ones.
A malicious user could just keep holding Ctrl+F5 to infinitely refresh your page and get the exact same effect. The fact that they can do this is independent of your redirect, and can be done to any server.


What client side encryption algorithm/libraries should I use to make syncing easier?

Let my rephrase your preconditions:

All data stored at the server or transferred to the server are encrypted.
The encryption key is only known to the clients.
There can be multiple clients, all use the same encryption key or some key derived from a shared secret. How this key/secret is shared between clients is outside of your question.

Then you are assuming that two clients might edit the same data and ask for a way  to merge these edits at the server side.

First, it is unclear what the result of this merge should be in your opinion even if the data are not encrypted. Therefore I'm simply assuming that you can somehow split the data into independent parts (like sentences or paragraphs) and treat these parts as fully independent entities when merging, i.e.:

If both clients have edited different parts just make each client replace this part only. Similarly you can detect and resolve if both clients have added new parts at different places or if one removed a part which the other did not touch.
If both clients have conflicting edits on the same part someone would need to resolve the conflict. This could be done that the first edit wins (i.e. you need timestamps) or that you ask for manual conflict resolving.

Note that with above merging algorithm there is no need to actually look at the contents of the parts, i.e. the algorithm could be executed on plain text, on hashes of the parts and also on encrypted parts if all parts were encrypted independently from each other. Only the manual conflict resolution would need to somehow present the contents to the user so that he is able see what he is actually resolving. But since all clients share the same key/secret each clients could also decrypt any part encrypted by the other client and display it within the manual conflict resolving.

In other words: how the merge is done can be made independent from the data being encrypted simply by splitting the data into independent parts (which you would need for merging anyway) and then encrypting each part individually and independent of the others. The exact implementation, libraries etc to do the merge are thus not a problem of information security anymore and thus would be off-topic here.


Limit attempt of user login against PBKDF2

1) Is my rationale for wanting to limit the number of tries a user can login reasonable ??

No, absolutely not the way you describe it. It's fine to limit the number of failed attempts in a short period of time and scale it up from there but you should never set a hard limit for a long period like an entire day. Who are you to tell me I cannot login to my account for the 201st time today?

  2) Are there any flaws in my argument

Yes. MD5/SHA1/SHA256/SHA512 etc is stupidly flawed for password hashing. Also, PBKDF2 has been widely used for quite a number of years. There are no signs that it will be broken "in a few years". See this answer for more details.

  3) Is my boss correct ???

Absolutely, yes.


In full-disk encryption you usually have a key hierarchy. A Key Encryption Key (KEK) is derived from a user password, as you stated often this is done using PBKDF2 (alternatively nowadays more preferred is scrypt). The KEK then is used to encrypt the Disk Encryption Key (DEK) which is actually used to encrypt the storage media.

I am not entirely sure if TrueCrypt really uses the password derived key to encrypt the disk. However, coming to your first question: Where exactly are these random keys stored? Every FDE solution has one tiny part of the disk which is not encrypted and where the DEK is stored in a secure manner (encrypted, see process above). This is the reason why attacks such as the Evil-Maid can work. On boot, the system needs to start a minimal environment which prompts the user for his password, derive the KEK and decrypt the DEK. It then checks whether the DEK is actually correct (probably by decrypting a fixed known pattern). If so, the disk decryption starts and the system continues its boot procedure.

Your next question: Why are random keys used for FDE? Imagine you don't use random keys and instead a fixed-pattern-key that for example is time based. An attacker only has to identify the appropriate setup time and can reduce the amount of keys to brute-force largely!

  If someone is able to get the password, the hacker would get the cipher key anyway.

That is true, this is why we need strong passwords, strong cryptographic primitives to derive the keys from them and strong keys that encrypt the disk. The first two are essentially to make brute-forcing the KEK take as long as possible. An attacker will eventually be successful, after all it's a brute-force. However, we want him to not even try because it would take far too long and the information stored on it by then probably outdated and worthless. Alternatively we include penalizing actions, i.e. an increasing timeout on false password entry, or a forced wipe after a specific number of tries.

The key encrypting the media must be random and hard to brute-force, as otherwise an attacker could easily target that key instead of the KEK derivation process that is designed to be slow.


Automated tools to manage or monitor authorized_keys?

While I do not want to promote commercial software, I know ssh.com is selling a software called "Universal SSH Key manager" that can discover, monitor, remidiate and manage SSH keys throughout an enterprise.

They describe their product with the following quote:

  Your enterprise may have more Secure Shell identities than employees.
  A lot more. Gain visibility and control over who has access to what
  and when, with the only comprehensive identity and access management
  solution for Secure Shell.

I have not tried their software, and are not affiliated with them.
It would be interesting to see if anyone can recommend open tools that do more or less the same task.


Creating secure communication line for mobile payment

SSL is probably not the most "efficient" way, but I'm not aware of any alternative that would be worth going to.

Mobile devices had WTLS to streamline the process for lower-bandwidth devices, but that's not a very viable system...  While you could roll your own, the rule of thumb (for crypto) is never roll your own.

Flaws have been found in SSL, and addressed; and they will be again.  However, your bank and your credit card company still use SSL, because it's the only widely supported method of providing reasonable security.

If the server in your case is hosted by your payment provider as @CodesInChaos suggests, they most likely only support SSL.  If you're planning on terminating the encrypted connection on your own server...  you should use SSL or expect massive hassles with your PCI (DSS and/or PA-DSS) certification.

In short... Just use SSL.


Can Windows Theme files (aero.msstyles) be sideloaded with spyware in their resources, specifically in UI scripts

I used vBinDiff to compare the hex code the altered VARIANT/NORMAL binary to that of the original theme. You can also copy the binhexes and save them to two text files which you would compare with WinMerge.

vBinDiff and WinMerge will highlight what modifications and what additions/substractions were made to the binaries, displaying them side by side. I read through the differences, 90% of them were no larger than 4 octals (4bytes), typically what you would expect to see when modding colors using a hex editor. The biggest divergence was an added 32bytes of code.

There are two possible explanations for the such an addition: (1) the author added extra image resources and added the entries necessary to reference them, (2) there is some kind of unwanted code that has been slipped in.

To address the possibility of 2, I did a search to see how small trojan code can get. How likely is it that a trojan has been stuffed into 32bytes if compiled UI scripts? I found a few mentions of an old 17byte virus from the DOS era called trivial which I disegarded right away because it would become apparent very quickly given it's known behavior. As far as full fledged trojans with backdoor and downloading abilities, the smallest I found was 20kb (trojan tinba), discovered in 2012. There is also Catchy32 which is still considered a Trojan but with simpler and very specific  functionalities and that one's about 580 bytes (reference). Based on this info, I established that it is highly unlikely (if not impossible) to slip any code in 32bytes of code and established that the resource in question is clean.

Mind you, this doesn't answer the question I asked but it comes pretty close. Thought I'd share it.


Add SSL on top of existing TCP connection

Can't I do it without writing code?

  Basically I want my above mentioned TCP connection and read/writes to go through some secure tunnel such as SSL. Or maybe even VPN?

You can use stunnel, use a VPN, use a tunnel done with SSH etc. Details depend on your infrastructure, that is which software you can install, which is already available etc. Since you want to have end-to-end encryption you need the necessary software on both sides of the connection.


Analyze my custom web authentication scheme, based on a token derived from username and password

So there are a few reasons why you don't want to do this, although I do not understand the code you presented as I do not deal with that. You should use a third party library to manage your sessions. There are several reasons...

Code is vetted, tested and improved across a much wider audience when you use a built in or well know authentication scheme.
When and if you leave, someone is not stuck dealing with a custom created authentication mechanism
There are probably vulnerabilities in the code, it may or may not be directly in your code but in a service you call, updating that single service may cause issues through the rest of the code, such as deprecated arguments and variables.  This may not make your program less secure but it may break it.
Self support is tough, especially when you do a good job and it is running without issue for a year or two, then bam!! in the middle of another project something breaks and you have to take the time to troubleshoot it from the bottom up.
CYA, if you make a mistake and something bad happens, you are the one people will come back to and ask, why didn't you use this or that scheme that is not vulnerable to some attack and you will have to explain that.

Anyway, I hope that helps


What a malicious user could do with a refresh token that cannot be revoked and has 1 year expiry time?

If a user or attacker has a refresh token, then they can easily ask for an access token  and then access any protected resource. This is the definition of refresh/access tokens. They would also have access for the entire year, though even if they only had it for a day they could do just as much damage. Even with very short expiry times, if they were able to a get a token in the first place, they could replicate what they did the first time to get more tokens.

Now, can anyone get the refresh token? Not unless their computer is already compromised. Doing it remotely is going to be blocked by the ADFS most likely through methods of secure only / HTTP only cookies, forcing them to be transmitted over an encrypted connection and preventing JS leakage (Non web platforms will have similar protections). If someone is able to physically get on the computer and see the cookie, then they might as well just download a keylogger anyway.


Reusing passwords that can possibly never be cracked

You don't need to bruteforce a hash to steal a password. A website might be compromised by an attacker so that they can read the passwords directly from the login form, in plain text. Or the website owner might be doing this, they could always do it if they wanted to, it's up to you whether you trust the owner or not (you wouldn't want to use the same password on Facebook and SomeBlackHatCommunity dot com). Also, there is always the good old shoulder surfing for stealing passwords. A password is like a key, and by using the same password you are actually giving the same key to different doors to different people. You can see it's never a good idea.

So you should never use the same password in different places, unless that password protects the same data or gives you the same privileges, so for example I believe you can use the same password to protect your backups.


Are VPNs that expose device ID a security risk?

You mention different threat models: does it matter if a banking/shopping website can use this information to identify you? Probably not, because you are likely logging in with an account that is already tied to your identity, payment information, home address etc. However, regarding "restricted sites", where you might be trying to hide your identity, this leaked information could reduce your anonymity.

The information leak is not characteristic of VPNs—the VPN is operating on a different/lower layer; it does not control or affect what code you allow to run on your device (unless the VPN provider is actively modifying your traffic—bad). Code that runs on your device, JavaScript, WebRTC-related, or otherwise, can access device APIs that provide information such as location, interface IP addresses, browser/OS information, battery state etc. So VPN or no VPN, this information can be accessed. This leak can only be resolved by changing browsers or browser settings, and there are certain web browsers and browser extensions that are designed to help with this, usually by disabling the features or providing false information.

In the webkay screenshot you posted, there is information that may help you disable these forms of tracking; disabling JavaScript and WebRTC is a good start. However, VPNs aren't truly designed to provide anonymity, although they may help to a degree. Solutions such as the Tor network and the Tor browser bundle are designed for anonymity and privacy and may be a better choice in this case.


Integrity attacks and encryption at rest

Absolutely. Data at rest will presumably eventually be used for something, and you don't want that use being influenced by an attacker. Most attacks on data integrity are the sort of thing that work best if the attacker knows at least the structure of the plaintext and ideally some of the content (which is easy with HTTPS, for example, but possible with many file types that use known offsets or similar).

The ease of such attacks depends on a lot of factors. Do you (the attacker) have write access to the ciphertext at all? Did the adversary use something like a stream cipher (trivial to flip bits in; each change in the ciphertext directly corresponds to a change in the plaintext with no side effects) or a block cipher where, even if you successfully can flip the bits you care about, you'll probably scramble other parts of the file? Can you make your desired change without editing the length of the data (which would probably screw up the decryption)?

Bear in mind that these sorts of attacks also work on data in transit. While exploiting things like padding oracles and similar can result in decrypting the enciphered data, it's often sufficient (or possibly even more useful) for your goal to just change it slightly and send the modified ciphertext on its way.

A few examples:

You have a chance to attack an encrypted file containing a report, memo, or similar. You saw the start of the document in plain text; it started with a sentence like "We have considered the proposal, and won't promote Filipe Rodriques...". You can determine the correct offset into the document, guess at the text encoding, XOR the strings "won't" and "shall", and apply that XOR mask such that it edits the document to now give yourself a promotion.
You're attacking a voting system, where the tabulated (but not-yet reported) results are stored encrypted using 32-bit integers. You know your preferred candidate/position was very likely to lose, and the roughly-expected number of results (based on polling, etc.) and you know the structure of the data in the file (where each candidate's result will be stored). You can't read the results, or set them exactly, but you can flip a few bits of suitably high order (significance) that will probably make your candidate's numbers much greater. (A data-in-transit equivalent might be to flip some moderately large portion of the votes - say, 55%, at random - before they're tabulated, resulting in an outcome that should have skewed away from your preferred candidate instead looking like a surprise win.)
You're attacking a machine with an encrypted file system that you can boot (password-less encryption with the key stored on a hardware module of some kind), and log in a low-privilege user, but can't log in a high-privilege one. The disk encryption should prevent an offline attack, but if you know where /etc/shadow (or equivalent) is, and how it's structured (even though you can't read it), you can plausibly do something like change your user ID to 0 (you know your own ID, you know where in the file and in the file system it will be; you can XOR the relevant bytes with the XOR mask of your current value and the value you want to set, and it'll be set when the machine wakes up). Then, you can boot up and log in your formerly-low-privilege account. Incidentally, this kind of thing is a real risk against disk encryption because there's usually nowhere to store the authentication tag, so most disk encryption lacks strong integrity protection; this is especially one of the weaknesses of password-less disk encryption (such as TPM-only mode).


Is it correct to consider audits as exclusively "detective" in nature?

Much like recursion, to properly understand audits we must first understand the scope and usage of audits. Audits are used to determine compliance against a benchmark. Without said benchmark, then the auditor has nothing to measure against. In some cases your benchmark may be a deeply technical document describing programming practices or operating system configurations. In other cases your benchmark may be as loose as "follow best practices as determined by $RANDOM_DEPT".

Thinking of them in this light, using your labels, audits should be classified strictly as 'detective'. So, this means that 'preventative' measures would be the benchmarks/standards/policies/whatever.

Consider the following:

  In order to avoid unauthorized access
  by ex-employees all accounts are
  disabled upon separation.

In this scenario the policy to disable accounts is your preventative measure. During the course of an audit, your auditor would attempt to determine whether or not the policy is followed.


VoIP service requires a scanned copy of my passport

No, this is not required by US law.
This does not reduce your risks; it may reduce the risk to Callcentric that you will defraud them, or use their service to harass/defraud others. But, as you point out, it's not so hard to fake a foreign passport. It's unlikely that Callcentric has infrastructure in place to verify that the passport you provide is authentic. This actually increases the risk to you, as it's possible that Callcentric will have a bad employee or a data breach and thereby transfer your information to hostile third parties.

Ultimately, you've got to choose whether or not using their service is worth the risk to your privacy/security. I can't imagine giving someone a copy of my passport just to get VoIP service, but everyone's got to make that call for themselves.


This is essentially not domain fronting, domain fronting is when you use a legitimate domain like a public CDN to send messages, but they are afterwards redirected to you.

If a website has the same origin policy set to allow everything you can use XMLHttpRequest from the victims browser to access those resources. You can't set things like Host headers and cookies.

A good starting point regarding this is BeEf framework.
https://github.com/beefproject/beef


Plausible deniability regarding KeepassX files

I think you need to decide what your threat model is: things like who your opponent is, what capabilities they've got, what information you need to keep secret, and so on.  It sounds like you're applying security-related techniques you've heard of without understanding what those techniques do or why you should (or shouldn't) use them.

The precautions needed for dealing with a "nosy little brother" threat are different from those for a "foreign intelligence agency" threat.  In the first case, simply keeping your secret information hidden is good enough; in the latter, you need to keep the fact that you have a secret hidden, so they won't be tempted to beat it out of you.


using bcrypt without salt/pepper is a bit complex for my case

Use bcrypt with the cost parameter specified for key stretching, examples in the official doc: http://php.net/manual/en/function.password-hash.php

password_hash("unsalted password", PASSWORD_BCRYPT, ["cost" => $cost]);

Is it more complex? I don't think so.

Side note: all PHP versions where password_hash is supported, have automatic salt generation enabled by default. If not using PHP7, you can specify your own (salt parameter in the array) but I don't see the point of doing so.


There's no contradiction here as long as you consider the issue in probabilistic terms.  For example:

  The reason I'm confused is that I thought that all encryption was supposed to do is make it as difficult as brute forcing the key to go from the cipher text to the plain text. It seems to me like there could be an AES key that would produce an all 0 ciphertext given a certain plaintext.

Yes, it's certainly possible that some combination of key and plaintext might produce all-zero ciphertext.  But since keys are meant to be selected at random, if such a combination even exists the chance that it would occur in practice is just astronomically unlikely.

One of the key security notions for ciphers is indistinguishability under chosen-plaintext attack ("IND-CPA"), which says (roughly) that an adversary cannot efficiently tell ciphertexts apart from uniform random bits, even if they choose the plaintexts to be encrypted.  More precisely, any algorithm that succeeds at distinguishing the cipher must be prohibitively expensive (e.g., brute-forcing a 128-bit key).

This means that we can draw good conclusions about the compressibility of ciphertexts just by reasoning about the compressibility of uniform random bit strings.  And it comes down to this: for a fixed compression algorithm, if you pick an n-bit string at random, the chance that the algorithm will compress the string you picked to a length of m bits (m < n) goes down exponentially with m.  If you could write an efficient (non-brute force) algorithm that achieved better success than this at compressing ciphertexts, then the cipher's security would be suspect.


What is the difference between PCI-DSS compliance and certification?

You are compliant if you follow all the rules of PCI-DSS that apply to your situation.

You are certified if an accredited independent auditor asserts, in his professional statute, that you are compliant to PCI-DSS.

If you apply for certification and the auditor finds out that you are not, in fact, compliant, then he will say so and point out the problems. It would still be up to you to fix the issues and try again.


Decrypt Passwords based on using a user's password

I'm not sure this really offers much security, but the best way I see to do it is:

Have a master key.
Encrypt each customer password with the master key.
Encrypt the master key with a password derived (PBKDF2 or similar) from each employee's password.

Then, when an employee logs in:

Generate the employee's key from their password.
Decrypt the master key.
Use the master key to decrypt customer passwords.


Why companies do not simply use hackers' tools to find their own vulnerabilities prior to the release of their software?

They are doing it, or at least they're expected to do so, as part of their Software Development Life Cycle (SDLC).

In terms of vulnerability management, a best practice would be to first perform a source-code review (static/dynamic), and to scan their product using a vulnerability scanner. Note that there are also other steps to enforce a secure SDLC, such as threat modeling, secure coding guidelines, etc. that should be performed as well.

In real life, this is 90% of the time seen as a "useless" activity, because it requires resources but doesn't generate revenue or add new functionality to the application.


Can data be uploaded to iCloud without your consent?

theoretically you can't confirm. Apple can lie to you. But you got no reason to think they will.

The real answer is for data linked to your Apple ID you can confirm. By going to the Apple privacy portal. You can request to download every single bit of data they got on you. And see for yourself.

This includes:

  Apple Media Services information    Includes App Store, iTunes Store, Apple Books, Apple Music, Podcasts activity
  Apple ID account and device information
  Apple Online and Retail Stores activity  Show more Apple Online and Retail Stores activity
  Apple Pay activity
  AppleCare support history, repair requests, and more Show more    AppleCare support history, repair requests, and more
  Game Center activity
  iCloud Bookmarks and reading list
  iCloud Calendars and Reminders
  iCloud Contacts
  iCloud Notes
  Maps Report an Issue
  Marketing communications, downloads, and other activity
  iCloud Drive files and documents
  iCloud Mail
  iCloud Photos
  Other data

No need to download everything. Just what you want to view.


X-Frame-Options Absent but cant load the page in iframe

The HTTP header Content-Security-Policy can be used to protect from loading the page in an iframe.

In this case, its value is set to default-src 'self' *.xyz.com which means that only the current domain, and *.xyz.com can load this page in an iframe.

That HTTP header has other uses like protecting from XSS attacks. You can find more information on the OWASP guide.


How to verify correct, secure and test setuid?

According to standard practice, only critical files

All executables you run are "critical", as they run with your UID and have all your permissions! They could do bad things to your files, that's "critical" to me. Executables run by root are even more "critical".

It is common, but incorrect to focus on SUID files when discussing possible security flaws of a Un*x system; all executables should be considered. There are just more ways to corrupt a SUID program.

  According to standard practice, only critical files should be suid like chmod and passwd.

No, only executables specifically designed to run as SUID.

Writing SUID program is a whole topic, way too big to be appropriate for an answer here.

  My question is, how do I test this file for vulnerabilities

In order to do a vulnerability assessment of a program, you have to first learn what purpose it serves, how and when it should be run.

  My question is, how do I test this file for vulnerabilities beyond just turning it off?

You just don't "turn off" parts of your system just because you are afraid! A program is SUID for a reason; if you remove the SUID bit, the system might misbehave.

  For example, I was able to vi the file itself and have it run a simple command but couldn't get it to chmod another user account.

A trusted program that can be modified by anybody is a security issue, even if it isn't SUID.

  If you know of a insecure 3rd party *nix apps or distros vulnerable to suid privilege escalation to learn on, that would be doubly excellent.

There is a long and shameful history of vulnerabilities in SUID programs. Just searching for "exploit" or "vulnerability" and "suid" returns plenty of these.


Security Implications of setting passwd as suid

"Exploiting" an application means making it do, with the privileges under which it is running, some things that it was not meant to do. passwd runs as root because it needs to read and modify files (in particular /etc/shadow) that can be read and written only by root. The normal behavior of passwd is to alter the password of the user who runs it (passwd is SUID-root so it has the privileges of the root user, but it stills remembers who executed it) and there is code in passwd which enforces that rule. To exploit it, one would need to find a way to bypass that code, i.e. a bug in passwd.

Being SUID-root does not automatically imply being exploitable. Rather, a non-SUID-root application does not have extra privileges so there is no point in exploiting it.


How to protect against skimmer attack like in the BA data breach

how to you protect against these kinds of skimmer attacks when modern websites rely so much on third party javascript libraries?

Simple answer, you cannot. If you use a third-party library by referencing it by URL and not copying the actual library files to your site, then you trust the third-party library maintainer to do his job (keeping you safe).

Miscreants know this and try very hard to infiltrate code into these third-party libraries.

More techy info on the subject: https://www.theregister.co.uk/2018/09/12/feedify_magecart_javascript_library_hacked/

Option 1: Do not use third-party libraries.

Option 2: Copy the actual JavaScript files to your site*, purge all unused code, maintain them yourself (you are creating a fork - added later after comments)* a̶n̶d̶ ̶u̶s̶e̶ ̶t̶h̶e̶m̶ ̶f̶r̶o̶m̶ ̶t̶h̶e̶r̶e̶. You will have to make sure you are allowed to do this (e.g. copyright, license), obligations might apply.

EDIT (after one comment):

Does not matter what you use, if you load resources from third parties, any resources, even encrypted, you trust the third party to keep you safe. Even option 2 (Copying the files) is not safe, unless you vet each line of every file you have copied and even then ...  Option 1 is, imho, the only way to be sure.

Option 2 is safer than linking to remote resources because the punk would have to change the code on your server (provided, of course, the code was "clean" when you copied it), and if you have a punk on your server then you have other problems ...

Any 3rdparty can potentially be defeated and will attract more attackers if it is widely used. This has happened in the past already, with punks injecting cryptominers in JavaScript libraries, defeating Subresource Integrity, the code was sneaked into the libraries, the 3rdparty server "thought" the code was genuine ... not sure what happened with B.A., how the changes made their way into the website ...


Can a certificate have multiple chains and multiple self-signed roots?

Multiple roots are created when

A certificate is renewed  or
A certificate is re-keyed

This applies to every certificate in the CA hierarchy.

Just to make things more interesting, the revocation list itself (CRL/OCSP) is signed and may have it's own PKI.  They may also have their own set of keys. (To verify the verifier?)

In other words,

The chains discovered while verifying the CRL, Deltas, and OCSP responses also count towards a CA root that is discovered.  (note that OCSP verification can be suppressed via id-pkix-ocsp-nocheck )

The CA architecture has an effect on the chain-building process. Before a distinct certificate chain is considered valid, the chaining engine builds all chains that are possible with the certificate that is being verified. If an end-entity certificate was generated by a freshly set up CA, the certificate chain is straightforward. However, a certificate that was issued by a renewed CA or where a cross-certification exists between the issuing CA and another CA, multiple certificate chains might exist.

The entire graph of certificate chains is constructed and then ordered by the “quality” of the chain. The best quality chain for a given end certificate is returned to the calling application as the default chain.

Below are illustrations of validation processes in a Single, N-Tier, Cross, and Bridge PKI

Single CA

N Tier

Cross Trust CA

Bridge CA

More information on PKI topology and cert renewals is at the bottom of this article


Is Webroot's Business Endpoint Security up to snuff for mobile workforce?

An independent review of various AV products by AV Comparitives put it in 20th position out of 22 tested - hardly a glowing review. You can get the PDF of the report for free.

It scored 1/3 for detection rates, 0/3 for proactive detection, 3/3 for suite performance, 3/3 for AV performance, and 3/3 for anti-phishing[pg.3]. However, this rating is only for scanning when internet access is available, since it uses cloud-based scanning. If no internet access is available, the detection rate drops significantly and misleading alerts are logged about various networking operations being monitored[pg.177]. If they're out in the field and might not always have internet access, I'd probably avoid this solution.

Possible alternatives in terms of performance are ESET and avast!, both of which have a reasonably low footprint. If you're looking for maximum protection, you may want to look at BitDefender or Kaspersky. If you're hoping to heavily leverage cloud-based scanning, Panda Cloud AV might be what you want, though it does hog resources a little.


This is most likely a blind SQL injection, testing whether you're vulnerable to SQL Injection by checking whether your server takes the specified time or more to reply to the request. This is not actually doing any data edit nor exposing anything; it's just checking whether you're vulnerable.

It's also worth noting that this specifically targets MySQL databases, as the if and sleep syntaxes are the ones of that db engine.

If the attack is isolated, you were probably "probed" by an automated vulnerability scanner that is preparing a large-scale attack, so if your webapp is not vulnerable you have nothing to worry about.

However, if you recieve more weird requests with different attack patterns, you could be the specific target of those attackers, and should take actions to prevent all attacks that may succeed.

See Time-Based Blind SQL Injection Attacks for more information.


Bypass Asp.Net 4.6 "A potentially dangerous Request.QueryString value was detected from the client"

As long as a standard charset is being used, there is no known publicly available way to exploit this in HTML context for any common browsers. Source: A lot of research and experience.


What would stop me from cracking a certain bcrypt hash?

Yes, it's possible. Don't need the rainbow table - that would only benefit you if you had multiple passwords using the same salt - since you can directly test the passwords.

Could take a while though - if you can calculate 1000 hashes per second, and you are using an alphabet of 64 characters (A-Z,a-z,0-9, plus a couple of symbols), looking for passwords of exactly 8 characters, the formula would be 64^8 (to get the number of passwords) divided by 1000, to get the number of seconds required. For that example, it's 281474976711 seconds. Or 8925ish years. Input your own hash checking speed to work out the actual time - it will vary based on your system.


How do I ask nmap to probe designated service type, and do not run scripts?

The first thing to do is to remove -A from your command, since that implicitly requests scripts in the "default" category (being the equivalent of -sV -sC -O --traceroute.

Next, you will still have scripts in the "version" category running. These are specifically designed to enhance the -sV version scan by probing services that will not respond adequately to a single static probe. If you really need to turn these off, you can (since Nmap 6.49BETA1) set the script-intensity script argument to 0: --script-args script-intensity=0. This will prevent version-category scripts from running unless you select them by name.


Does EV SSL certificate makes any difference while used instead of self signed ssl in case of API for android app?

Generally speaking there are three types of certificates:

Self signed certificates:

These are certificates that are often generated by an internal certificate authority (CA) where the root certificate is injected in all clients. This way when visiting an internal web application over TLS, no certificate warnings are displayed to the end user.

Signed certificates:

These are certificates that are signed by public or internet facing certificate authorities (CA). The root certificates of these CA's come with the web browser.

EV signed certificates:

An EV certificate is the same as described in the section signed certificates however, by obtaining such certificate the issuer is required to retrieve a lot more information regarding the company requesting this certificate.

Extra checks are in place before the EV certificate is handed out.

  Does EV SSL certificate makes any difference while used instead of self signed SSL in case of API for android app?

Yes, it does make a difference and self signed certificates should not be used in production environments.

The difference is that with a self signed certificate, users are presented with a warning. In case of a man in the middle attack, the certificate is not valid and a user will also be presented with a warning.

Users that are taught to always accept these warnings are prone to man in the middle attacks.

When using a valid certificate, users are not displayed with certificate warnings. When a man in the middle attack takes place, the users will see a warning which should indicate something is wrong.

Nowadays there is no valid reason to use self signed certificates. Free certificates can be obtained quite easily. The use of an EV certificate would be overkill in my opinion.


The Payment Card Industry DSS rules also apply to banks.  I was at a large UK bank that had to change it's customer database to make the card information more secure from staff as part of a PCIDSS initiative.  This included obscuring part of the PAN (the long number) from operators in the call centres etc.

It should be noted however, that in certain jurisdictions (i.e. the UK) there are a lot of other regulators that have much more effective security controls that are placed on banks and so whilst PCI DSS is applied to the cardholder data usage, it is not the be all and end all.


Can I place a private key on a sim card?

In answer to (3)- It was not until recently that API's to do this were readily available without having some significant resources behind you.

Here is a guide to doing what you describe in (1) and (2). http://nelenkov.blogspot.com/2013/09/using-sim-card-as-secure-element.html

There are some applications doing this- the article comments say a bitcoin app is doing exactly as you describe.


I have just 4 hours a month to security check a cloud based application - How to use my time?

As mentioned in the comments, I too agree 4 hours in a month is way too low. Understand, and more importantly, make your stakeholders understand that with 4h they shouldn't expect much. Considering they've given you 4h, it doesn't look like they're serious about securing this application either.

Based on the comments, answers and my own thoughts I'll try to put together something. Here's how I think your options should look like in order.

Ask for more time. Make them understand if they want to secure an application in just 4h, it's practically useless.
Hire an agency and spend your 4h defining their scope, prioritizing their actions and reviewing their results. (@Nelson)
If you can't do the above, I'd recommend securing the low hanging fruits so you're covering more ground in 4h. Here's what I think are important

Set your external facing services to update. (~1h to find and set the important applications for update). Close unnecessary ports/services that you don't find useful.
Set up MFA (~10mins) - since you don't have much time, set up things that are quick, protect you against common attacks and alert you.
Review your secrets - Ensure they're stored securely, run scanners on your code to find hard-coded secrets. (~1h)
Disaster Recovery - I'd recommend spending some amount of your precious 4h in setting up protections for when things go wrong, because they will. Start creating backups (2 if feasible) in different zones. I'm assuming the platform will help you with this but it will still take time. During this time, you can also draft out a rough disaster recovery plan. (~1.5h)
Finally, with whatever little time you have left, document. Document what you've done, what you haven't done and what should be the next steps for the next time someone gets 4h to further secure the application. (~leftover)

DoS protection is good and required but I just couldn't find a way to fit it in to the above plan and neither could I swap anything out for it. Maybe that should be documented in your next steps.

Overall, it's a farfetched request to secure something in 4h. But if I were tasked with it, I'd do it with the above steps. I'm not sure if any investigations into whether the system is already hacked is feasible in those 4h. When you are given 4h to secure, you can either chose to spend it in securing the application against potential threats or investigate for attackers in your system (needs a different plan). That initial choice is yours.


Knowing Input&Output, How to determine encode method and the passkey that was used in encoding?

First, a definition.  In computer science, an "encoding" is an alternate way of representing data, without any effort being made to disguise the data (ASCII, EBCDIC, and ISO-8859-1 are all examples of text encodings, while base64 and uuencoding are examples of binary-to-text encodings).  On the other hand, "encryption" is a method of masking the nature and value of the data (AES, DES, and RC4 are all examples of encryption, as is the much older Caesar cypher).

Figuring out what type of encryption was used to encrypt something is a form of distinguishing attack, a type of analysis encryption schemes are designed to resist.  Identifying an encoding, on the other hand, can often be done through statistical or heuristic analysis.

In your case, the data is almost certainly an encoding, base64, which is simply a way of representing binary data within the limits of a system designed to handle text.  Specifically, it appears to be a block of 64 bytes of binary data that has been base64-encoded twice (the double equals sign on the end is strongly reminiscent of base64, as is the general pattern of upper- and lower-case letters).


Hardening password-based file encryption with a synchronous stream cipher plus high-memory hashing algorithm?

That just needlessly complicated with no real payoff.  Your interposition of Argon2 into the CFB mode makes it more costly, sure, but costs are additive, which implies they're associative (a + (b + c) = (a + b) + c), which means that there's nothing to be gained by performing all that extra work with Argon2 at that precise spot—if you just crank up the Argon2 parameters at step #4 that's just as good, and simpler.

So your idea doesn't look any better than:

Generate a random Data Encryption Key (DEK);
For plaintext message plaintext compute an authenticated ciphertext = AEAD_encrypt(dek, plaintext);
Generate a random salt;
Generate a Key Encryption Key (KEK) from the password and salt: kek = argon2id(password, salt, argon2_params), supplying parameters as costly as you want to Argon2id;
Encrypt the DEK with the KEK: encrypted_dek = AEAD_encrypt(kek, dek);
Write out (salt, argon2_params, encrypted_dek, ciphertext) as your encrypted file.

Note that:

You don't really need random IV/nonces here as long as you take great care that you always choose a fresh random DEK and salt every time you encrypt.  The property you want to guarantee is that every key will only ever be used for one message encryption.
When I say AEAD_encrypt I mean some authenticated encryption scheme that works with variable length messages.  AES-GCM and ChaCha20/Poly1305 are two common and popular ones these days.  Don't futz around with modes and MACs, use something prebuilt.
When I say ciphertext and encrypted_dek I mean it in a sense that incorporates the AEAD tag.  Many libraries output the authentication tag separately from what they call the ciphertext.
The use of a separate DEK and KEK has the neat property that you can change the password without having to decrypt and reencrypt the whole file; you can just rewrap the encrypted DEK.  If you don't care for this you could just generate a DEK directly from Argon2.
You should probably use Argon2id instead of Argon2i.  Or actually, wait until the RFC is approved...


Raw Text SSN on page: Should I be worried?

As long as the page you're viewing was encrypted via TLS, (page using https:// and with a certificate that your browser trusts), then it's unlikely that your SSN will be susceptible to someone sniffing your web traffic. If you're on Wifi, make sure you're using an encrypted network that you trust also.
That being said, having it written in plaintext is a little more worrisome should someone steal your credentials to the employer site - whether by guessing or phishing it from you. If that happens they will probably have your bank info and SSN both, amid a bunch of other critical personal data. Make sure you use strong creds to access the site, don't share them across accounts-- the standard safety warning.


Which is more secure for a reset password feature - security questions or reset link in email?

I agree with your security team. The "security question" is not secure on its own: cities can be found over ip, names can be googled and nicknames of pets can be guessed.

However, you could combine both methods: first send the mail, and when the user clicks the link, ask the question. This way you would add at least a bit more security to the procedere. Also think about a lock (e.g. 12 hours) after three bad attempts to ensure bruteforcing isn't possible.


id-ce-cRLDistributionPoints ASN.1 / DER encoding question

The definitions posted here via the link are incomplete, but after supplying definitions for all of the undefined types, I get a similar error message from the OSS Nokalva ASN.1 Studio utility.  The last byte you display here is a length (58 hex 88 decimal), but based on the second byte (hex 10, dec 16) the total length of the encoding is 16, so 88 more bytes cannot be found in the buffer based on that outer length, thus the error message on encountering that length of 88.

Paul


Is it possible to construct a specific AES collision?

No. Not with the key alone.
If you have a known plaintext and a known cipher text then the problem of getting the key from that is known as a "known plaintext attack".
And any modern crypto system, including AES, is hardened against this. Several terabytes of plaintext/cipher text pairs will still not allow you to get at the key within reasonable time.
Further reading

https://en.wikipedia.org/wiki/Known-plaintext_attack
https://stackoverflow.com/questions/11716468/can-aes-be-cracked-with-enough-decrypted-data-why-or-why-not
https://crypto.stackexchange.com/questions/1512/why-is-aes-resistant-to-known-plaintext-attacks
Compute the AES-encryption key given the plaintext and its ciphertext?

However...
If you go beyond simply choosing an AES key and also allow choosing an AES Initialization Vector (IV) for an AES block mode, then, yes, you can do this. Easily. If your message is short enough. You only get one IV's length worth.
It's something of a hobby for one Ange Albertini. He likes to create "polyglot files" that can decoded/interpreted in more than one way.
He gave a talk about this in 2014:

Ange Albertini. 31c3. 2014-12-29, Funky File Formats


Website Defacing without hacking (google issue or trick?)

Yes, trying to hide hacks from the operator of a web site is common, and checking referer* is one way to do it.  If you can find a contact for the web site, it would be polite to report the hack so they can remediate. Edit: I've sent email to the "info@" email address.  If you know someone there, you might mail them directly, especially if you can write in German.

* I know it's correctly spelled with two Rs, but there's only one when it's a web "referer."  Fun facts to know and tell your friends.


httpOnly Cookies
Just to be clear, your question is implicitly excluding sites that store session ids in httpOnly cookies.  The reason is because such cookies are completely inaccessible to javascript, so it would not be possible for them to send the session id up in a custom header if the session id was stored in an httpOnly cookie.  You already know this, but I want to state this requirement out loud.
All Other Methods of Session Management
In literally every other case for session management, session fixation is possible in the event of an XSS attack.  In short, if the Session Id is in a custom header then it must be accessible to their javascript so that they can attach it.  If it is accessible to their javascript, then it is accessible to the attacker's javascript.  The only data source that javascript doesn't have access to are httpOnly cookies, which aren't being used here.
Session Ids are stored in local storage?  An attacker's javascript can replace the value stored in local storage.  The session ids are stored in a non-httpOnly cookie?  The attacker can replace it there too.  Other than an httpOnly cookie, there are no data sources that would be accessible to their javascript and not the attacker's.  As a result, session fixation is just a matter of reverse engineering the javascript to figure out where the token is stored.  There is no need to intercept requests or get web workers installed (although you can possibly intercept requests without web workers).  A malicious extension could certainly modify requests in transit, but again this is not necessary - an XSS attack alone is sufficient.
Again, to try to emphasize the important point here: you wouldn't want to bother trying to intercept requests.  That can be quite a pain.  All you need to do is figure out where and how the session id is stored client side, and inject your chosen session id there.  Since it is accessible to their javascript, it is accessible to the attacker's javascript.


Is my authentication persistence system design secure?

Some things to consider:

make sure you set the domain/path of the cookie so that only your domain (and no sub-domains can read it)
You seem to be using HTTP rather than HTTPS. This makes your cookie subject to eavesdropping. Consider using a HTTPS session and a cookie using the secure attribute.
90 days is a long time to hold such a session open. The longer the validity period of the cookie the greater the risk of theft.
By leaving the user effectively logged in you are exposing them to a Cross-Site Request Forgery

This thread from Stack Exchange might also be useful


It isn't possible to simply just "avoid the WAF" it is doing its job. Well, with the exception of specific payload bypasses. But that isn't what your question is asking.
In terms of "bypassing" the WAF in relation to something like directory brute-forcing the best course of action you can take is as suggested by Schroeder, set your scanning speed lower than the threshold the WAF is set. For example, if the WAF is configured to start dropping packets when a single IP sends 100 requests or more in a 5 minute window. Then you would need to set your scanning to send no more than that amount.
To find the sweet spot you simply start your scanning quite aggressively (depending on the environment) and lower it gradually until the point where your requests go through. I should note that these days, WAFs can have some pretty granular rules so this really only applies to the classic scenario of dropping traffic when it is too frequent.


How do governments carry out computer surveillance?

Governments purchase spyware from private companies.

Some companies like VUPEN are known for building complex 0-day exploits against browsers and selling them privately to anyone for hundreds of thousands of dollars.

Recently the Obama Administration has moved to block the sale of such technology to Iran and Syria.  Iran is known to be performing active MITM attacks against gmail.


Writing files in a sub folder of the web folder (apache security)

There absolutely is a security preference to save sensitive data outside of your web root. If you don't want random users being able to access the data, then don't put it under web root.

Sure, you can set the file permissions to be non-readable or configure Apache to deny access to the file or use mod_rewrite to block attempts to access the file, but these security mechanisms are much more error prone and more inconvenient than simply putting sensitive data outside of the web root. And session data definitely qualifies as sensitive data.

And what to set the folder permissions to depends on your server setup. On a standard LAMP setup, PHP will execute as the same user as Apache (often nobody). However, under shared hosting the PHP script is often run under the domain's own SFTP/shell user. But either way, you shouldn't be giving other users read access to your session data.


Do I need ossec for my personal home computer?

HIDS is very much overkill for a home PC unless you are doing something super-sensitive. More importantly though, HIDS is reactive and to react, you have to monitor it. So the HIDS app is only a part of the solution. You need event reporting and collation and you need both eyes on the output and a way to do something if you get an event. I've seen far too many security solutions implemented that are then ignored or only checked occasionally.

In reality, the best additional security you can put on a home PC or any PC really is something that only allows whitelisted applications to run. This massively reduces the attack surface of your PC and greatly increases the complexity of an attack.


How did GamerFood hack the Starcraft IEM Taipei Tournament?

It looks like observer chat so I would guess it is most likely the result of a password compromise. Either the tournament password or one of the official observer accounts used to televise/stream/shoutcast the game.


What is the safest and most convenient way to transfer data from my computer to "unknown" USB devices?

Unfortunately it is very difficult to plug in unknown USB devices to exchange data in a manner that is guaranteed to be safe; there's a reason secure facilities often completely disable USB ports. In some cases a USB device could even be designed to cause physical damage and there are very few devices that have circuitry designed to protect against this type of attack.

The only method I can think of that could reasonably "guarantee" safety would be to set up a sacrificial computer, probably something cheap like a Raspberry Pi, and transfer your files there. Then disconnect the sacrificial machine from the network and use it to transfer the files to the potentially unsafe drives. When you're done, wipe and reinstall the sacrificial machine. I'm guessing this is probably more effort than you're willing to expend, so if you aren't willing to accept the risks, I would suggest exploring alternative methods of file transfer.


Methods to Monitor Ads For Malware on Mobile Devices

This type of problem really needs to be addressed at a few different levels, the user, the publisher, and the programmer. Each holds a degree of responsibility and as such no matter your role, you are responsible. Based on your plan of inspecting individual code, I suspect that you are an end-user and not a programmer. As such, I'll focus mostly on that realm.

Ways to Reduce Risk as End User

An end-user can do a few things to determine if the ad is malicious. This includes the basics, such as installing a Mobile AV (Such as Sophos on Android). The steps that you are currently taking (Investigating the payload) is generally far more in-depth than most end-users would ever want to do. This gap can easily be filled with an AV and possibly a mobile IDS/IPS (Such as zIPS). The line of host-based IPS and AV are very blurred these days and can lead to some overlap. The key point is that the IPS is designed to work to prevent your system from being breached. Whereas the AV is working to clean-up the breach after the fact.

An example of a normal Advertisement Transaction:

Here's an example of the steps that lead to an advertisement being delivered:

You open the App
The app opens up and allows you to use it for X number of seconds
After a fixed time constraint or a certain criteria is reached (Eg. You complete a level in a game) the app decides to deliver an ad.
The app triggers the request to an included library
The included library then makes an API request with some of your information to an external site
The external site accepts the request and processes the request to determine the best advertisement to deliver
The ad is delivered to your device
After the ad is complete, you can continue to use the app again until another constraint is reached

An example of malvertising

List item
You open the App
The app opens up and allows you to use it for X number of seconds
After a fixed time constraint or a certain criteria is reached (Eg. You complete a level in a game) the app decides to deliver an ad.
The app triggers the request to an included library
The included library then makes an API request with some of your information to an external site
The external site uses the data to determine if you could be vulnerable to a specific exploit. This is determined based off of a number of different factors, which most off includes user-agent inspection, but may include factors like javascript checking.
Once the most effective exploit is determined, the payload to sent to the device. This is the point where the security of your device is tested.
The payload will either run, or run and then compile, on your machine. If the infection is successful, you may not be able to tell.

What an IPS will do

The benefit of using an IPS is that when a website is requested (In your case an advertisement), it will check the request and the response for signs of malicious activity. A common way that malware is delivered in advertisements is via a base-encoding and decoding formula that serves no real purpose. A smart IPS will detect when a base-encode formula is used in numerous different instances and concatenates results together followed by a final decode of the entire payload.

In the case of the above IPS solution, it will also inform you when you are at risk of MITM attacks and various other issues. It also has a built-in AV function. This falls back into where I stated that the lines are very blurred between the different tools.

Ways to Reduce Risk as a Publisher

Here are some of the ways that a publisher can reduce their risk:
 - Ensure that your code does not have major vulnerabilities or introduces vulnerabilities on end-users.
 - Monitor for any suspicious behavior occurring on your ad-network.. This should be checking for unusual advertisement payloads as well as indications that your ad-network have been compromised.
 - Perform code reviews of advertisements being delivered on your network

Ways to Reduce Risk as a Programmer

It's very difficult to mitigate the risk when the vulnerabilities exist on the user and the advertisements are delivered from your advertising partner. The biggest take-away is that you ensure that the advertising network that you choose is a trusted one. This generally means staying away from unknown third-parties or networks that offer an exorbitant PPC (Pay-per-click). These are generally warning signs. In addition you should offer the following to users:

Offer a way to report malicious ads in the application
Perform independent checks for malicious code (This may be difficult to maintain as signature sets change everyday.)
Log what ads were delivered to submit feedback to the ad-network operators.
Perform extensive QA with advertisements on numerous different OS versions and device types to check for any obvious malvertising campaigns.

Synopsis

This can really only be addressed using a layered defense tactic. If you rely on only a single link in the chain, it will inevitably break. I found that a recent study, The Dark Alleys of Madison Avenue:
Understanding Malicious Advertisements, suggests that up to 1% of ads contain malvertising code. That's a pretty incredible statistic given how many sites offer advertisements. It also highlights that if we relied solely on advertisers to ensure the security of the advertisements, we would be in serious trouble.


best practices for handling self-registration?

I would refrain from using details that, despite being personally identifying, are available to other people as well. I dont know how secret the SSN is on the US, but here in Europe it is quite possible that someone would knew my SSN. Date of birth: Is on my facebook. Adress: Is in the public phonebook.

You need to find a datum which is only accessible to you and the registrant at the time of registration and satisfies some kind of identification at the same time. It comes down to asking "Is it really you who is registering?" via some other means than the current browser session. If you do not have an email or phone number already, this will be very difficult.

If you are sending out invoices or some other kind of letters, you could ask for the last invoice number. But still, this could be found in the paper waste by someone and he could register on behalf of the poor victim.

The only remaining 2-factor-auth that would work is sending out a letter by mail with some auth code. This would take a few days, but it is rather hard to intercept since the attacker would have to live in the same househould and must be able to check the mail every day.

Are you doing payment business? It´s delicate, so it´s your obligation to really identify those people correctly.


How can you hide / fake your ip address without proxy / vpn?

No, and you're not even changing your IP address with the method you've outlined - you're effectively claiming that you're a proxy for whatever IP address you provided in that header. It might work to fool some basic analytics tools, but your IP address would still be available to whatever servers you connect to (they'd need it to know where data should be going), and it wouldn't fool any authorities who wanted to track activity back to you.


What's the real reason behind blocking the social sites? Even legitimate sites like Twitter which acts as a knowledge repository?

There are all sorts of security risks - the ones I tend to highlight are:

The big social networking sites are a
wonderful target for attackers.
Imagine a group of over a billion
users, most of whom are not
technically savvy, that all use the
same web app (eg Facebook) and have
personal data, links to others etc.
So take it as read that these sites
are continually targeted by well
funded attackers and (slightly) more
reputable companies who use the
functionality of the application to
gain significant access to your
machine or data (eg Farmville) which
may include passwords you may reuse
elsewhere.
Additionally, the large pool of users
accessing the same application means
a zero-day in that application will
be very rewarding.
A company that allows social
networking has very little egress
control over data - so how can you
protect against the leakage of
sensitive data? Think of the
Wikileaks implications...

Obviously you also have the time-wasting aspect - social networking can be a huge time-sink. One thing to be aware of is that now everyone and their dog has a smart phone, the social networks are available whether or not you allow it on the company network, so the time wasting may still be an issue.


What's the difference between HMAC-SHA256(key, data) and SHA256(key + data)

Yes, HMAC is more complex than simple concatenation.

As a simplistic example, if you were to simply concatenate key + data, then "key1"+"data" yields identical results to "key"+"1data", which is suboptimal.  HMAC will yield different results for each.  There are other flaws with simple concatenation in many cases, as well; see cpast's answer for one.

The specification for HMAC is called RFC2104, which you should read if you have this level of interest.

In summary, to implement HMAC, you should first:

Create "ipad", which is 0x36 repeated BLOCKSIZE times.
Create "opad", which is 0x5c repeated BLOCKSIZE times.

Note that BLOCKSIZE is 64 bytes for MD5, SHA-1, SHA-224, SHA-256, and 128 bytes for SHA-384 and SHA-512, per RFC2104 and RFC4868.

Then HMAC is defined as:

HASH(Key XOR opad, HASH(Key XOR ipad, text))

or, in detail from the RFC,

  (Pretext: The definition of HMAC requires a cryptographic hash function, which
  we denote by H, and a secret key K. We assume H to be a cryptographic
  hash function where data is hashed by iterating a basic compression
  function on blocks of data.   We denote by B the byte-length of such
  blocks.)

(1) append zeros to the end of K to create a B byte string
    (e.g., if K is of length 20 bytes and B=64, then K will be
     appended with 44 zero bytes 0x00)
(2) XOR (bitwise exclusive-OR) the B byte string computed in step
    (1) with ipad
(3) append the stream of data 'text' to the B byte string resulting
    from step (2)
(4) apply H to the stream generated in step (3)
(5) XOR (bitwise exclusive-OR) the B byte string computed in
    step (1) with opad
(6) append the H result from step (4) to the B byte string
    resulting from step (5)
(7) apply H to the stream generated in step (6) and output
    the result


on stack execution on windows 7 :: metasploit :: meterpreter :: executable crypter

Judging by this behavior I would say you are running XP prior to SP2 (you should have mentioned that....).   That means that the region of memory that contains your shellcode is marked with the non-executable flag.   There are a few ways to get around DEP and the NX flag.  One method is by evoking your executable with /NXCOMPAT:NO  or by using VirutalAlllocEx to allocate a region of memory that is both executable and contains your shellcode.


Wireshark captures all traffic on a network interface. The thing with HTTPS is that it is application layer encryption. Wireshark is not able to decrypt the content of HTTPS. This is because HTTPS encrypts point to point between applications.

The idea here is that HTTPS traffic that travels over the Internet is confidential, a random router or person who happens to capture your packages cannot decrypt the HTTPS without the decryption key.

So bottomline: Wireshark cannot decrypt HTTPS traffic without the decryption key.

More info: https://wiki.wireshark.org/SSL


PKCS11 key pair generation - attributes MODULUS_BITS and PUBLIC_EXPONENT

Yes, MODULUS_BITS is the key length. 4096 supposed to be good nowadays.
PUBLIC_EXPONENT is public and { 0x01, 0x00, 0x01 } = 65537 is widely used value since:

it's prime
it's not too short
it's not too long and contains only two '1' in it's binary representation - that makes binary exponentiation fast (you can encrypt or check signature quicker)

PUBLIC_EXPONENT is really required in the RSA algorithm, but it's possible that if you omit it, the generation algorithm would use 65537 by default.


What are the biggest security concerns on PXE?

In a PXE environment, as a pentester, I have 2 major classes of attack I can choose from.

1: I can capture a full machine image. Do your systems automatically connect to the domain controller after setting up the machine? If so, this image probably has domain controller credentials on it, that I can capture and use elsewhere.

2: I can manipulate images on a restored machine. After capturing, I can make an image that has, say, the corporate image with AV disabled and malware pre-installed, then MITM someone's system for a persistent foothold in the company. Since PXE isn't encrypted or authenticated in any way, this is trivial to do with physical access, a few seconds of privacy, and something like a pwn plug or a raspberry pi.


Turned on cgi.fix_pathinfo still "dangerous" in Nginx?

I would not describe this change as "critical" per se, but it still has security implications.  I'm not aware of anything that has fundamentally changed since that advice became relevant -- PHP's behavior tends strongly towards backwards compatibility, even when that has security implications.  Imagine you have a server that allows people to upload files to the server, say in a directory called upload.  Now, your upload script is careful to only allow files with certain extensions (say only .png) to ensure nobody uploads a malicious PHP file.

Now, as an attacker, I'll try to write a PHP shell into a file, name the file evil.png, and upload it.  When it uploads, I'll visit http://example.com/upload/evil.png, but I'll discover that this just downloads the file to me -- nginx never dispatched the request to php-fcgi to be processed as php, because the filename ends in .png.

If I'm an attacker who's aware of PATH_INFO, next I'll try http://example.com/upload/evil.png/index.php.  If your server is so configured, this will result in PHP being executed (because nginx sees the index.php at the end) and PHP will walk the path until it finds a component that is a file, not a directory (evil.png) and attempt to execute it.  Then my shell gets executed and I win.

That being said, there's better ways to deal with this by having the NGINX config split the path in advance, so PHP isn't walking the filesystem.

From Neal Poole's excellent blog post on the issue:

# Pass all .php files onto a php-fpm/php-fcgi server.
location ~ \.php$ {
   # Zero-day exploit defense.
   # http://forum.nginx.org/read.php?2,88845,page=3
   # Won't work properly (404 error) if the file is not stored on this server, which is entirely possible with php-fpm/php-fcgi.
   # Comment the 'try_files' line out if you set up php-fpm/php-fcgi on another machine.  And then cross your fingers that you won't get hacked.
   try_files $uri =404;

   fastcgi_split_path_info ^(.+\.php)(/.+)$;
   include fastcgi_params;
   fastcgi_index index.php;
   fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
   fastcgi_pass php;
}


How to simulate network attacks and use wireshark to detect them?

First of all I would recommend you to create a test network and isolate it from the production network.

Creating a test network: It depends upon your budget. If you have a big budget then buy couple of systems running Windows and linux, buy some switches and connect them with network cables.

If the budget is not that big then try using virtualization tools like VMware workstation or VirtualBox etc. Here is a nice paper about making a test lab.

In order to simulate attacks it is good to know about how these attacks works and how to detect them. (I assume you know this.) Also most of these attacks are not very common these days but for simulation and playing around it will be fun.

For DOS simulation:

DOS attacks usually send a lot of traffic to the victim machine to consume its resources so that the legit users are not able to access the services. A very common traditional example is Ping flood as DOS attack.

Ping flood: Send a huge amount of Ping packets with packet size as big as possible. In windows you can specify the data/buffer size too. The command is ping -l. The attacker will use the maximum value.

Detection:  The normal ping packet has default packet size of 32 bytes in case of Windows. So if you see a lot of Ping packets with unusual size of buffer for eg: like 4000 then you could say it could be a Ping flood.
You can use PING command to simulate this attack. In wireshark create a filter for ICMP Echo packets and check the buffer size.

MAC flooding:  In this attack the attacker will transmit a lot of ARP packets to fill up the switch's CAM table. This causes the switch to operate in fail open mode, which means that the switch will broadcast the incoming packet to all the ports.

Detection: If you see a lot of ARP requests coming from random source MAC addresses, then you can assume it is ARP flooding. This is not an ideal detection method. But still if you have only 3-4 devices in your network and on contrast you are seeing many ARP requests with different source addresses then it could be an ARP flooding because 3-4 devices are not going to make a huge ARP requests with different source MAC addresses. You can use some ARP flooding tool for simulation. In wireshark create a filter for ARP request to see the ARP request frames.

ARP spoofing: In this case you shall associate your MAC address to victim's IP address by sending a specially crafted ARP frame! If the attack is successful then all traffic that was destined to Victim's IP will be now redirected to you. Currently I have no idea how you can detect this attack with just a wireshark. What you could try is that you can make a filter for all the ARP probes/requests and then check for which source MAC address the source IP address has been changed in the ARP probes.

Detection:  This is not an ideal detection method because this could make a false positive if some one has merely replaced a machine in the network. But if you assume that no machine is replaced in the network then this method could help to detect the attack.

Tools for simulating the attacks: I would recommend using Kali linux it contains a lot of tools.
There are some tools that can help you:

Ping flooding tool: Nping

MAC flooding tool: Macof

ARP spoofing tool: dSniff

Also here is a good article regarding tools!.

I hope it helps.


Someone used my email address in order to access an online account

Definitely change your password, no matter what.

are you sure the email you received is legitimate? Or could it have been spoofed somehow?
if you can review logins, then check if what you see is what the email says
is there an explanation involving your own activity? Did you use a new network, your phone, something else, which you don't normally do?
could this be a matter of your connection having changed IP (possible if your were on a consummer-grade ISP) - and if so, do you still have that IP?
could this be a case of your re-using a password, for example between your.name@compromised.com and your.name@youremailprovider.com)?

If you can enable 2 factor auth, do so.

You might also consider using something like KeePass if you don't already, and go around to change all your passwords to something totally random, and unique per service.


Is enabling PHP script execution on HTML document file extensions a security concern?

Generally, configuring PHP to execute all files (as your title says) is a bad idea, especially if your website has an upload functionality. Someone could simply upload a PHP file with the extension .jpg then execute it on your server, and your server is gone.

However, in your case, if users can't upload .html or .htm files (or .php, of course) then there's almost no added security risk.


How to apply FIPS to Microsoft Access database with custom VBA

As the software developer, you need to ensure that not only the chosed encryption standard is FIPS compliant, but also the cryptographic module used. AES for example is FIPS 140-2 approved as a method, but the actual implementation of the Rijndael algorithm on Windows Server 2008 [not R2] is not approved (and is therefore not FIPS compliant ... you'd have to use 3DES or something else).

For completeness, the complete list of validated modules are available here: http://csrc.nist.gov/cryptval/140-1/140val-all.htm

To ensure FIPS compliance you'll also want the system that this is running on to enforce FIPS. On a windows system this is under the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\FipsAlgorithmPolicy

Change the DWORD value of ENABLED to 1. As a developer you'll want to test in this mode.

Ensuring that the communication channels and that the server/workstation/etc. running the application are FIPS compliant will be part of the deployment process where there is little that you can do should a separate contractor be working the installation.


Is the Facebook login form using SSL without https in the URL?

No, it is not secure to enter your username and password on http://facebook.com.

The target of the login-form points to an https URL, so a passive attacker cannot read your password:

<form method="POST" action="https://www.facebook.com/login.php?login_attempt=1"

But an attacker, who can modify the data stream, can manipulate html code which contains the login form. He can modify the target url or add some javascript code that sends a copy of the username and password to his own server.

Furthermore after logging in, Facebook sends the session cookie over an http connection. This allows even an passive attacker to act in your name. This is not a theoretical attack, there is a tool called Firesheep that is extremly easy to use.

To prevent the first risk, always use https://facebook.com to login. There is a browser extension called https everywhere which does this for you and even stays at https which prevent the Firesheep style attacks, too.