Need to ephemerally store third-party password One particular web service that I am writing interfaces with an API. Each API call requires the user's username and password to be sent, no state is maintained.

Ideally, when using my web service the user will enter his API username and password once, and my web service will store that information until the session ends. I understand that I should not store the API password using PHP sessions nor in a database due to security concerns. Therefore, how can I securely store and access the password for the duration of the session?

Would it be secure to encrypt the password, store the encrypted password in a cookie and the encryption key in a session?

Note that I originally asked the question (without the proposed solution) on SO:
https://stackoverflow.com/questions/15084025/storing-third-party-passwords-for-reuse-across-pages
Had I drank coffee first, I would have known to post here instead of there. The SO post can be deleted, but not by me.

The answer given there is the one I am now using in production, so if there are flaws in the approach (store encrypted password in PHP session, encryption key in cookie) then I would very much like to know.

$encryptionKey = sha1(microtime(true).mt_rand(PHP_INT_MAX / 10, PHP_INT_MAX));
$encryptedPassword = mcrypt_encrypt(MCRYPT_BLOWFISH, $encryptionKey, $password, MCRYPT_MODE_CFB);
setcookie('atwood', $encryptionKey, 0);
$_SESSION['encryptedPassword'] = $encryptedPassword;

$password = mcrypt_decrypt(MCRYPT_BLOWFISH, $_COOKIE['atwood'], $_SESSION['encryptedPassword'], MCRYPT_MODE_CFB);

The question to ask is: what is the security model here ?

You apparently need to transmit the user password (a sensitive piece of data) from the user to the back-end servers. But the timing matters: the human user enters his password once, at the beginning of what the user thinks of as "the session", and the password must be transmitted at later times to the back-end (the "API calls"). So there must be some storage somewhere.

PHP sessions are server-side storage, as a collection of small files with time-based expiry. What you write in a "session variable" ultimately goes to the hard disk. Therefore, it could be considered as bad form to store a plain password in a session variable, because hard disk physical contents are not reliably destroyed when the file is deleted (upon deletion, the storage area dedicated to the file is marked as reusable, but the data itself won't be overwritten until the area is indeed reused for another file). But there are details:

If you fear a data leak through post-mortem access to an old disk (or a backup tape), then what you want to avoid sending the file to the physical medium. Some people put the PHP session files on a RAM disk: the RAM disk is setup with the OS facilities for such things, and the path to it is adjusted with session_save_path(). Files in a RAM disk never make it to physical storage, so the leak is adverted. On the other hand, all sessions will be lost if the server reboots (this is probably tolerable, but it depends on the setup). Sharing the session across multiple front-ends would also be more complex.

Note: on Linux systems, there are three ways to create RAM disks: the "true" RAM disks (size up to 16 MB each, adjusted at boot time), "ramfs" and "tmpfs". This last one will use RAM but also swap space, so contents may still hit the disk. See this page for some details.
If you fear leakage of session data through a live hack of your server, then consider that someone who could get read access to some OS-protected file is probably not far from taking control of the complete machine as well, at which point he will just plug into the PHP engine and grab the user passwords as they arrive. There is little point in going to that level of protection.

What you suggest is encrypting the user password, and storing the key in the client browser (as a cookie) and the encrypted password in the session files; or you could do the reverse (key in the PHP session, encrypted password in the cookie). In both cases, the idea is that the attacker needs to grab both the session data and the cookie to unravel the password. This makes sense only if your security model assumes that an attacker would be able to read the session files (even when they are only in a RAM disk) but not the RAM allocated to the PHP engine (through which passwords necessarily travel at some time). This does not seem a very realistic model to me.

If you do want to use encryption, regardless of its apparent uselessness in that specific situation, you may as well do it properly:

Generate the (user-specific) key with a cryptographically secure PRNG (openssl_random_pseudo_bytes()).
Use proper encryption. This means the usual assortment of encryption mode, random IV (to be stored along the encrypted file), padding... which is easy to get thoroughly wrong. It is possible to do correct encryption with PHP, but you have to understand what you are doing down to the fine details. In that specific case where a new key is generated for each encryption instance, it should be enough to use a strong block cipher in CFB mode and a fixed, conventional IV, although it would leak the password length; and PHP has a habit of doing weird things (e.g. its "CFB" mode is actually CFB with 8-bit feedback, which is slow and of questionable security for long inputs).

but I still recommend not doing that, and instead use RAM-based storage of PHP sessions on the server.


How were Facebook accounts compromised? I was reading this BBC article about compromised Facebook accounts, and was wondering if anyone knows the technicalities of how they did it? All I understood is that there were some breaches due to the VIEW AS feature.

Does anyone have any technical information about this?

The article in Wired has a little more information.

The social network says its investigation into the breach began on September 16, when it saw an unusual spike in users accessing Facebook. On September 25, the company’s engineering team discovered that hackers appear to have exploited a series of bugs related to a Facebook feature that lets people see what their own profile looks like to someone else. The "View As" feature is designed to allow users to experience how their privacy settings look to another person.
The first bug prompted Facebook's video upload tool to mistakenly show up on the "View As" page. The second one caused the uploader to generate an access token—what allows you to remain logged into your Facebook account on a device, without having to sign in every time you visit—that had the same sign-in permissions as the Facebook mobile app. Finally, when the video uploader did appear in "View As" mode, it triggered an access code for whoever the hacker was searching for.


Is it secure to store the salt along with the hashed password in the database? After reading some posts and articles about how to store user credentials in a database, in which all said that we should use a different salt for each user and save the salt in the database along with the hashing of password + salt, I still have one question.

Is it secure to store the salt along with the hashed password in the database?
Please correct me if I'm wrong but if I get access to the database and see what the salt was for that password, I can create a rainbow table with that salt, no?
I'm trying to understand how secure is too store the salt not how to store the salt.

but if i get access to the database and see what salt was used to that password i can create a rainbow table with that salt no

Yes you can, but it would only work that one password. The whole point of rainbow tables is that you can compute one once and reuse it again and again. The per-password salt means that each password hash must be attacked individually.

So to answer the question, no, the salt is not a secret.


How are AV scanners protecting against encrypted (PGPd) malicious code? As a user of PGP I worry about receiving a virus that was previous encrypted with my public key, which anybody can get by querying many PGP key servers. What prevents an attacker to target a PGP user by sending a virus encrypted with the user's PGP public key? AV scanners operating at the mail-server level would not be able to detect such virus.

What you've described is only a problem for network-based Antivirus systems, and I don't believe there is currently a way for such systems to detect encrypted malware if they are utilizing a signature based detection algorithm.

I believe the solution here is to implement a good host-based Antivirus program that can perform real-time AV analysis as files are being accessed, and consequently would detect any known viruses after the e-mail was decrypted. Of course, you'd also want to disable displaying images inline or otherwise interacting with file attachments automatically after decryption. Norton Antivirus and Intego Virus Barrier are two examples of products that can offer real-time, host-based virus detection.

Theoretically, you might still be vulnerable to malware that targets the PGP decryption implementation used on your system. This seems like an extremely low probability, but if you were concerned about it you could mitigate the risk by only checking PGP e-mail within a Virtual Machine on your system.


Certificate-verification in TLS Out of curiosity I wonder why in the Handshake Protocol of TLS there is an explicit message, i.e. CertificateVerify, that serves to verify that the client is indeed the owner of the certificate he claims to own, while such a message is lacking for the server's certificate? Verification is achieved through signing a hash of the formerly exchanged messages.

In my understanding it is at least equally as important for the server to verify his ownership, because in practice it is often the client who is going to trust the server with delicate information.

I don't know how you get the impression that there isn't a message to verify the servers certificate, there is a message to request certificate verification in both directions, though the server certificate request is always implied with the ClientHello and the client certificate verification response is bundled with the ServerHello:

The key exchange mechanism also validates that the peers own matching private keys. Due to the maths involved, it is not possible to successfully do the key exchange unless both parties have the private keys matching their respective certificates.

Image credit: https://zoompf.com/blog/2014/12/optimizing-tls-handshake


Deleting a webpage via 'malware DoS' I mean, we all know the DoS/DDoS where machine(s) are flooding servers/computers with traffic that it cannot handle. Eventually, it just goes down and nothing can connect to it, neither connect itself to anything.

But if I was for example, to make malware that would delete some important files and put itself on the server which hosts that site (or something else), and delete files which would cause it to again, go down. Would this be considered a DoS? Because I've technically denied the service of that server.

Denial of Service, as its name suggests, is any event which causes service to be denied, either to users or administrators, or any other entity which relies upon the system.

This can include anything from synfloods to smashing the server with a sledgehammer. As such, yes, your example would be considered a denial of service.


Using sqlmap --crawl without asking questions I'm using sqlmap with --crawl option. Whenever a URL is found, it asks me whether to scan it

GET http://127.0.0.1:80/demo/sqli.php?id=1
do you want to test this URL? [Y/n/q]

How should I ask sqlmap to test all URLs without asking?

P.S SQLmap also asks the following questions, I'd like to answer them automatically as well:

please enter number of threads? [Enter for 1 (current)]
do you want to check for the existence of site's sitemap(.xml) [y/N]

Try this out:

 --answers="follow=Y" --batch

From SQLmap wiki:

  Act in non-interactive mode Switch: --batch

  If you want sqlmap to run as a batch tool, without any user's
  interaction when sqlmap requires it, you can force that by using
  switch --batch. This will leave sqlmap to go with a default behaviour
  whenever user's input would be required.

  Set answers for questions Option: --answers

  In case that user wants to automatically set up answers for questions,
  even if --batch is used, using this option he can do it by providing
  any part of question together with answer after an equal sign. Also,
  answers for different question can be split with delimiter character
  ,.

Everything is here


REST and confidential state - the trusted client problem etc? With REST client sessions are not handled by maintaining server side state. Any such state needed for subsequent calls is passed to the client and then passed back to the server as part of those calls.

So what's the standard approach to state that you don't want the client to have?

E.g. I have a resource X, internally instances of this resource have simple names like "A", "B" and "C". Multiple instances of resource X can be associated with a given user - and in each REST call I want to specify which specific instance of X is currently being operated on.

In the simple case I'd just include something like this in my REST calls:

"xId" : "B"

However there are a number of things I want to prevent...

I want to prevent the user fishing for other instances, by e.g. specifying arbitrary IDs like "Z" in the their calls.
I don't want the internal names of the resources ending up on client machines (these might be useful in attacks via completely different vectors).
If a given instance of X is reassigned to another user I want to prevent the old owner using its ID (that they validly obtained) in further calls now that it is no longer assigned to them.

I'm guessing people will reply that there are two issues here:

That I'm not talking about session state here but rather the assignment of resources to users and that on the server side I just need to validate that the resource specified in a call is really associated with that user.
That there's a separate ID masking issue here - that if I have internal IDs that I don't want exposed to the client I should just create long lived aliases.

Are there a good set of guidelines covering the specific security issues that arise with REST as a result of storing session state on the client side (as opposed to keeping it on the server side)? E.g. the trusted client problem isn't REST specific but perhaps there are REST specific aspects to this and other problems that one should generally be aware of.

In the specific situation I've described I would assign random UUIDs generated by a CSPRNG as aliases to my underlying resources, validate that a given resource is associated with a user when it's specified in a call and assign a new alias to the underlying resource whenever it is reassigned to another user (a step that shouldn't actually be necessary given that one always validates the current association of an ID with a user). However with security I generally find that when non-experts think they've got all the angles covered they're generally wrong!

What you are proposing sounds reasonably secure. The one change I would make is to move from UUIDs to a simple 128-bit cryptographically secure random number. I suggest this because, while UUIDs are intended to be unique, they are not designed to be unpredictable. Depending on the UUID implementation details, perhaps an attacker can start to predict subsequent IDs based on having obtained one or more through legal means.


Why enter again (or at the very least confirm) my email address when I click "Forgot password"? In most, if not all, web forms for logging into a site, you have your forgot password link. When clicking the link, you get a new form (usually in a new page) either empty (!) or prefilled with the email address you put in the login form, where you have to click again to actually get the site to send the reset password link.

I think what should happen is that when clicking over the forgot password link, a reset password link is automatically sent. Then the link text changes to "Reset password link sent to xx@yy.zz" until you enter again a wrong password.

Is this worse in any way than the standard procedure, security-wise?

PS: The UX side of the question's here.

PS2: I'm thinking about sites where your username is your email address (of which there are aplenty), otherwise BadSkillz's answer points to a very valid information leak risk which could be mitigated via changing the message.

This makes (somewhat) sure that you really are the user associated with the account, you should at least know what email address was used to create the account.

Filling the email address automatically could already give an attacker the opportunity to get all the email addresses in the database, just request a new password for every account you can think of. The same goes for showing the message "an email has been send to xzy@abc.com". Now you have the email associated with the account and had the server send an email. Imagine doing that 1,000,000 times.


Can I view a user's browser history if the history/cache has been cleared? A client wants to track a specific employee's browsing habits. Assuming that the employee knows how to clear their browser history, is there any way to recover the history so it can be read by BrowserHistoryView or some other software?

There's two ways, the hard and the easy.
The hard way: use forensic software to recover deleted files, identify the folders and files responsible for history and cache, and read those files.
The easy way: use forced proxy company-wide, and configure the network to only allow browsing by using this proxy. With user authentication enabled, it's possible to know exactly what every employee is accessing.
Either way, usually the employer have to tell every employee about the inspection and require them to acknowledge that they know about the monitoring. It depends on your jurisdiction and current laws, but usually is a good thing to do.


How is Sandboxing implemented? What I would like to know is two fold: First off, what is sandboxing? Is it the trapping of OS system calls and then secondly deciding whether to allow it to pass through or not? How is it implemented to begin with? Would it be by way of hooks in the SSDT (kernel level)?

Well this answer ended up fairly long, but sandboxing is a huge topic. At its most basic, sandboxing is a technique to minimize the effect a program will have on the rest of the systems in the case of malice or malfunction. This can be for testing or for enhancing the security of a system. The reason one might want to use a sandbox also varies, and in some cases it is not even related to security, for example in the case of OpenBSD's systrace. The main uses of a sandbox are:

Program testing to detect broken packages, especially during builds.
Malware analysis to understand behavior of malicious software.
Securing untrusted or unsafe applications to minimize damage they can do.

There are many sandboxing techniques, all with differing threat models. Some may just reduce attack surface area by limiting APIs that can be used, while others define access controls using formalized models similar to Bell-LaPadula or Biba. I'll be describing a few popular sandboxing techniques, mostly for Linux, but I will also touch on other operating systems.
Seccomp
Seccomp is a Linux security feature that reduces kernel attack surface area. It is technically a syscall filter and not a sandbox, but is often used to augment sandboxes. There are two types of seccomp filters, called mode 1 (strict mode) and mode 2 (eBPF mode).
Mode 1
Seccomp mode 1 is the most strict, and original, mode. When a program enables mode 1 seccomp, it is limited to using only four hardcoded syscalls: read(), write(), exit(), and rt_sigreturn(). Any file descriptors that will be needed must be created before enforcing seccomp. In the case of a violation, the offending process is terminated with SIGKILL.
Taken from another answer I wrote on another StackExchange site, a sample program that securely executes a function that returns 42 in bytecode:
#include <unistd.h>
#include <stdint.h>
#include <stdio.h>
#include <sys/prctl.h>
#include <sys/syscall.h>
#include <linux/seccomp.h>

/* "mov al,42; ret" aka "return 42" */
static const unsigned char code[] = "\xb0\x2a\xc3";

void main(void)
{
    int fd[2], ret;

    /* spawn child process, connected by a pipe */
    pipe(fd);
    if (fork() == 0) {
        close(fd[0]);

        /* enter mode 1 seccomp and execute untrusted bytecode */
        prctl(PR_SET_SECCOMP, SECCOMP_MODE_STRICT);
        ret = (*(uint8_t(*)())code)();

        /* send result over pipe, and exit */
        write(fd[1], &ret, sizeof(ret));
        syscall(SYS_exit, 0);
    } else {
        close(fd[1]);

        /* read the result from the pipe, and print it */
        read(fd[0], &ret, sizeof(ret));
        printf("untrusted bytecode returned %d\n", ret);
    }
}

Mode 2
Mode 2 seccomp, also called seccomp-bpf, involves a userspace-created policy being sent to the kernel, defining which syscalls are permitted, what arguments are allowed for those syscalls, and what action should be taken in the case of a syscall violation. The filter comes in the form of eBPF bytecode, a special type instruction set that is interpreted in the kernel and used to implement filters. This is used in the Chrome/Chromium and OpenSSH sandbox on Linux, for example.
A simple program that prints the current PID using seccomp-bpf:
#include <seccomp.h>
#include <unistd.h>
#include <stdio.h>
#include <errno.h>

void main(void)
{
    /* initialize the libseccomp context */
    scmp_filter_ctx ctx = seccomp_init(SCMP_ACT_KILL);

    /* allow exiting */
    seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(exit_group), 0);

    /* allow getting the current pid */
    seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(getpid), 0);

    /* allow changing data segment size, as required by glibc */
    seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(brk), 0);

    /* allow writing up to 512 bytes to fd 1 */
    seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(write), 2,
        SCMP_A0(SCMP_CMP_EQ, 1),
        SCMP_A2(SCMP_CMP_LE, 512));

    /* if writing to any other fd, return -EBADF */
    seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EBADF), SCMP_SYS(write), 1,
        SCMP_A0(SCMP_CMP_NE, 1));

    /* load and enforce the filters */
    seccomp_load(ctx);
    seccomp_release(ctx);

    printf("this process is %d\n", getpid());
}

Because the Linux syscall ABI keeps arguments in general purpose registers, only these registers are validated by seccomp. This is fine in some cases, such as when an argument is a bitwise ORed list of flags, but in cases where the argument is a pointer to memory, filtering will not work. The reason for this is that the pointer only references memory, so validating the pointer only ensure that the pointer itself is allowed, not that the memory it is referencing has not been changed. This means that it is not possible to reliably filter certain arguments for syscalls like open() (where the path is a pointer to a null-terminated string in memory). To filter paths and similar objects, mandatory access controls or another LSM-based framework must be used.
Pledge
OpenBSD has added a syscall filter similar to (but more coarse-grained than) seccomp called pledge (previously tame). Pledge is a syscall that applications can opt into, essentially "pledging" that they will limit their uses of various kernel interfaces. No matter how much the application begs, the kernel won't revoke the restrictions once they are in place, even if it changes its mind.
Pledge allows an application to make a promise, which is a group of actions which will be permitted, with all others being denied. In essence, it is promising to only use functions it explicitly requests beforehand. Some (non-exhaustive) examples:

The stdio promise allows basic functionality like closing file descriptors or managing memory.
The rpath promise allows syscalls that can be used to read the filesystem.
The wpath promise allows syscalls that can be used to write to the filesystem.
The tmppath promise allows syscalls that can read/write, but only in /tmp.
The id promise allows syscalls that are used to change credentials, like setuid().

Although pledge is much more coarse-grained than seccomp, it is, for this reason, much easier to use and maintain. Because of this, OpenBSD has progressed to adding pledge support to a wide variety of their base applications, from things as security-sensitive as sshd to things as trivial as cat. This "security by default" architecture ends up greatly improving the security of the system as a whole, even if individual promises are coarse-grained and not particularly flexible.
Chroot
A chroot is a *nix feature that allows setting a new path as the root directory for a given program, forcing it to see everything as relative to that path. This is not usually used for security, since a privileged program can often escape a chroot, and because it does not isolate IPC or networking, allowing even unprivileged processes to do mischief like killing other processes. In a touch, it can be used to augment other security techniques. It is very useful for preventing an application from doing accidental damage, and for giving legacy software a view of the filesystem that it expects.
Chrooting bash, for example, would involve putting any executables and libraries it needs into the new directory, and running the chroot utility (which itself just calls the syscall of the same name):
host ~ # ldd /bin/bash
        linux-vdso.so.1 (0x0000036b3fb5a000)
        libreadline.so.6 => /lib64/libreadline.so.6 (0x0000036b3f6e5000)
        libncurses.so.6 => /lib64/libncurses.so.6 (0x0000036b3f47e000)
        libc.so.6 => /lib64/libc.so.6 (0x0000036b3f0bc000)
        /lib64/ld-linux-x86-64.so.2 (0x0000036b3f938000)
host ~ # ldd /bin/ls
        linux-vdso.so.1 (0x000003a093481000)
        libc.so.6 => /lib64/libc.so.6 (0x000003a092e9d000)
        /lib64/ld-linux-x86-64.so.2 (0x000003a09325f000)
host ~ # mkdir -p newroot/{lib64,bin}
host ~ # cp -aL /lib64/{libreadline,libncurses,libc}.so.6 newroot/lib64
host ~ # cp -aL /lib64/ld-linux-x86-64.so.2 newroot/lib64
host ~ # cp -a /bin/{bash,ls} newroot/bin
host ~ # pwd
/root
host ~ # chroot newroot /bin/bash
bash-4.3# pwd
/
bash-4.3# ls
bin  lib64
bash-4.3# ls /bin
bash  ls
bash-4.3# id
bash: id: command not found

Only a process with the CAP_SYS_CHROOT capability is able to enter a chroot. This is necessary to prevent a malicious program from creating its own copy of /etc/passwd in a directory it controls, and chrooting into it with a setuid program like su, tricking the binary into giving them root.
Namespaces
On Linux, namespaces are used to isolate system resources, giving a namespaced program a different understanding of what resources it owns. This is commonly used to implement containers. From the namespaces(7) manpage:

A namespace wraps a global system resource in an abstraction that makes
it appear to the process within the namespace that they have their
own isolated instance of a global resource.  Changes to the global
resource are visible to other processes that are members of the
namespace, but are invisible to other processes.

There are 7 namespaces supported under Linux currently:

cgroup - Cgroup root directory
IPC - System V IPC and POSIX message queues
Network - Network interfaces, stacks, ports, etc
Mount - Mountpoints, similar in function to a chroot
PID - Process IDs
User - User and group IDs
UTS - Hostname and domain name

An example of PID namespaces using the unshare utility:
host ~ # echo $$
25688
host ~ # unshare --fork --pid
host ~ # echo $$
1
host ~ # logout
host ~ # echo $$
25688

While these can be used to augment sandboxing or even be used as an integral part of a sandbox, some of them can reduce security. User namespaces, when unprivileged (the default), expose a much greater attack surface area from the kernel. Many kernel vulnerabilities are exploitable by unprivileged processes when the user namespace is enabled. On some kernels, you can disable unprivileged user namespaces by setting kernel.unprivileged_userns_clone to 0, or, if that specific sysctl is not available on your system, setting user.max_user_namespaces to 0. If you are building your own kernel, you can set CONFIG_USER_NS=n to disable user namespaces globally.
Mandatory Access Controls
A MAC is a framework for defining what a program can and cannot do, on a whitelist basis. A program is represented as a subject. Anything the program wants to act on, such as a file, path, network interface, or port is represented as an object. The rules for accessing the object are called the permission, or flag. Take the AppArmor policy for the ping utility, with added comments:
#include <tunables/global>

/bin/ping {
  # use header files containing more rules
  #include <abstractions/base>
  #include <abstractions/consoles>
  #include <abstractions/nameservice>

  capability net_raw,  # allow having CAP_NET_RAW
  capability setuid,   # allow being setuid
  network inet raw,    # allow creating raw sockets

  /bin/ping mixr,      # allow mmaping, executing, and reading
  /etc/modules.conf r, # allow reading
}

With this policy in place, the ping utility, if compromised, cannot read from your home directory, execute a shell, write new files, etc. This kind of sandboxing is used for securing a server or workstation. Other than AppArmor, some popular MACs include SELinux, TOMOYO, and SMACK. These are typically implemented in the kernel as a Linux Security Module, or LSM. This is a subsystem under Linux that provides modules with hooks for various actions (like changing credentials and accessing objects) so they can enforce a security policy.
Hypervisors
A hypervisor is virtualization software. It usually leverages hardware features that allow isolating all system resources, such as CPU cores, memory, hardware, etc. A virtualized system believes not just that it has root, but that it has ring 0 (kernelmode). Hardware is either abstracted by the CPU (the case for the CPU cores and memory itself), or emulated by the hypervisor software (for more complex hardware, such as NICs). Because the guest is made to believe it owns the whole system, anything that can run on that architecture will tend to also run in the virtual machine, allowing a Linux host with a Windows guest, or a FreeBSD host with a Solaris guest. In theory, a hypervisor will prevent any actions in the guest from affecting the host.
A useful resource that helps with a low-level understanding how a guest is set up is an LWN writeup on the KVM API. KVM is a kernel interface supported on Linux and Illumos (a family of open source forks of Solaris) for setting up virtual machines. As it's fairly low level (interaction only being through IOCTLs on a file descriptor opened against the /dev/kvm character device), it is typically the backend for projects like QEMU. KVM itself makes use of privileged hardware virtualization features such as VT-x on Intel processors and AMD-V on AMD.
It's common for hypervisors, such as with the popular Cuckoo sandbox, to be used to assist in malware analysis. It creates a virtual machine that malware can be run on, and it analyzes the internal state of the system, reading memory contents, dumping memory, etc. Because it runs a full operating system, it is often more difficult for malware to realize it is running virtualized. Common techniques like attaching a dummy debugger to itself so it cannot be debugged can be fooled, though some malware can attempt to detect virtualization (with varying levels of sophistication). Hypervisor detection itself is a very broad and complex subject.
Hypervisors are often (ab)used for security, such as by Qubes OS or Bromium (using the Xen hypervisor to isolate Fedora and Windows, respectively). Whether or not this is a good idea is often debated, due to bugs in Xen cropping up repeatedly. A famous and rather abrasive quote from Theo de Raddt, founder of OpenBSD, on the topic of virtualization when relied on for security:

You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes.

Whether or not a hypervisor is a good choice for security depends on many factors. It is typically easier to use and maintain, since it isolates an entire guest operating system, but it has a large attack surface area and does not provide fine-grained protections.
Containers
Containers are similar to hypervisors, but rather than using virtualization, they use namespaces. Each container has every resource put in its own namespace, allowing every container to run an independent operating system. The init process on the container sees itself as PID 1 running as root, but the host sees it as just another non-init and non-root PID. However, as they share the host's kernel, they can only run the same type of operating system as the host. Additionally, while containers can have root processes that can do privileged actions like setting up network interfaces (only in that container's namespace, of course), they cannot change global kernel settings that would affect all containers. Docker and OpenVZ are popular container implementations.
Because containers fundamentally rely on user namespaces of various implementations (standard Linux namespaces for Docker, and a bespoke namespace technology for OpenVZ), they are often criticized for providing poor security. Container escapes and privilege escalation vulnerabilities are not uncommon on these systems. The reason for these security issues stems from the fact that the namespace root user can interact with the kernel in new and unexpected ways. While the kernel is designed not to let the namespace root user make any obviously dangerous changes to the system that cannot be kept in a namespace (like sysctl tweaks), the root is still able to interact with a lot more of the kernel than an unprivileged process. Because of this, a vulnerability that can only be exploited by root in the process of setting up a virtual network interface, for example, could be exploited by an unprivileged process if that process is able to enter a user namespace. This is an issue even if the syscalls can only "see" the network interface of the container.
In the end, a user namespace simply allows an unprivileged user to interact with far more of the kernel. The surface area is increased to such an extent that many vulnerabilities that otherwise would be relatively harmless instead become LPEs. This is what happens when kernel developers tend not to keep a security mentality when writing code that only root can interact with.
Other technologies
Linux is certainly not the only operating system that has sandboxing. Many other operating systems have their own technology, implemented in various different ways and with varying threat models:

AppContainer on Windows provides isolation similar to a combination of chroots and namespaces. Domains, files, networks, and even windows are isolated.

Seatbelt on OSX acts as mandatory access controls, limiting the resources a confined application can access. It has seen its share of bypasses.

Jails on FreeBSD build on the concept of chroot. It assigns an IP address to the program running in the jail and gives it its own hostname. Unlike a chroot, it is designed for security.

Zones on Solaris are advanced containers that run a copy of Solaris' userland under the host's kernel. They are similar to FreeBSD Jails, but more feature-rich.


One time passwords using Mobile phones It is safe to assume that the majority of users accessing the internet also possess the mobile phones. So can we take advantage of this and relieve users of remembering any passwords.

Instead of registering users on the website, the site can register their mobile phones. The mobile phone number is being used by gmail as the optional second-factor authentication.

Could any such schemes be designed and implemented in which user always login using one time passwords and do not have to remember any passwords for any of the websites? If the mobile phone is lost, then all accounts are compromised. To counter that the mobile phone will have 1 master password or a biometric password. Apart from saving users the burden of complying with the different password policy of every site, such schemes will also prevent offline attacks as there are no passwords stored on the server.

Can such cost-effective schemes or protocols be designed so that users do not have to remember any passwords at all?

Using the mobile phone as single authentication factor would be very bad.

  The mobile phone number is being used by gmail as the optional second-factor authentication

The import part here is "second-factor". It sound like you are proposing to use the mobile as a single authentication factor. That would be very bad because mobile phone are not secure. If your device get compromised the attacker would also get access to your webpage.

Like on normal computer there are many ways to attack a phone. Think about remote exploit or an evil app. If you lose your phone it even worse. If you did not fully encrypt the device your lock screen would not protect you. Even with encryption the attacker could brute force the password.

Anyway using the mobile phone as second-factor is a good idea but it can not replace a password.

By the way: biometric passwords are bad because mostly you can copy them very easy and you have big trouble changing them.

Update in response to the comment: Password manager vs one time password via mobile phone

Mobile phones and password managers are very different. One is a mostly bad protected device that is very likely to be lost, while the other is an encrypted file on a device.

You could intercept the one time password while it's send to the device (SMS is not encrypted). HTTPS might be broken. Phone numbers can be highjacked and routed to other devices. You would need to authenticate your phone to the website.

Assume you have done that and you fully encrypted your phones with a strong password. Now it's like a password manager? Nope. Phones are mostly turned on even if lost, so you can recover the encryption key from RAM.


How does a Certificate Private Key get transferred on import / export? I am fairly new to certificates in general and have setup my own standalone CA for testing purposes. I have noticed some interesting behavior of private keys which I'm trying to find some documentation on.

In Certificate Authority Console (certsvr / Windows Server)

If I create a certificate request marking my certificate as exportable, submit it, approve it and then export it in the certificate authority (export as binary), I am able to export it with the private key. However, I can only do it once. The next time I try it again, the private key is no longer there. Is this correct? Is the private key always included only on the first export?
When importing a certificate with a private key, whether using certutil or the mmc snap in, sometimes I notice that the file I exported from is no longer valid. So now to make sure I don't lose the key in the file, I always create a copy first.

I seem to keep losing the private key. I'ved often saved files (.pfx) and import them, delete the certificate in my store only to find out that the same file doesn't have a private key anymore when I tried to import it again.
This is okay for now since I'm just using this for testing but if any one has detailed understanding of how this work then that would be great.

One of the important detail that I discovered about exporting and importing private keys from a Windows Server Certificate Authority scenario is that it is important that the certificate request is made on the same machine where you will be importing the request. This is why there were some instances where after importing the certificate, the private key is not present. This is common since I was playing around with a stand alone server.

https://social.technet.microsoft.com/Forums/windowsserver/en-US/66f1181b-7a51-4943-949e-933b94b5f712/how-do-i-create-certificate-w-private-key-with-my-standalone-ca?forum=winserversecurity

I have found some documentation regarding key archival and retrieval but is only relevant if you are using an enterprise CA.

https://technet.microsoft.com/en-us/library/cc781351(v=ws.10).aspx


OpenPGP Master Key Size Currently the default maximum key size is 4096. I know this can be changed by recompiling the software, and I don't mind doing that.

My problem is about compatibility issues. It makes sense that some implementation may not / may have trouble supporting 8k or 16k keys.

However, I've heard of sub-keys. I don't want my "day-to-day" encryption / signing keys to be incompatible with others. Its also likely that those sub-keys should have an expiration date.

A "master signing key" (ie your identity) should be safe enough for a lifetime, because ideally you don't ever want to change it, right?

I am considering using 4k keys for encryption and documents signing, and a 8k+ key as "master key". That means I will use my master key only to sign my owns keys, and other people's keys. That should be ok, as my gpg2 binary would support 8k+ keys. Is that a correct assumption ?

However, I also need other people signing my key. And that is when trouble could arise. Would a default implementation be able to sign a 8k+ keys?

Have a missed something? Would you consider that a good way to start using OpenPGP?

A "master signing key" (ie your identity) should be safe enough for a lifetime, because ideally you don't ever want to change it, right ?

Yes, that's the idea.

  I am considering using 4k keys for encryption and documents signing, and a 8k+ key as "master key". That means I will use my master key only to sign my owns keys, and other ppls keys.

Also the route I was going, and was fine with that up to now.

  [...] as my pgp2 binary would support 8k+ keys. Is that a correct assumption?

I don't know of pgp2, but if you're speaking about gpg2, namely GnuPG version 2: yes if it's new enough. And this includes all versions of the last few years.

  However, I also need other ppl signing my key. And that is when trouble could arise. Would a default implementation be able to sign a 8k+ keys?

In theory, this should not matter, as other users just sign your key and user ID fingerprint with their own key. But in the end, the implementation will have to understand what it's signing (for example to display the user ID string) and might fail for large keys. What reason for will you be using the key? Most people in the free software world use GnuPG, which supports large keys since a really long time (was it ever limited?). If you have to deal with some businesses with really old versions of PGP, you might have to think a little bit deeper about compatibility.

  Have a missed something? Would you consider that a good way to start using OpenPGP?

Even if you're using smaller subkeys, the "other" client/user must support that large keys to verify your primary key. Also remember that the actual gain in key strength is not linear to the RSA key size!

Creating large keys like 8K RSA does not require recompiling GnuPG any more on most systems and since quite some time. I think I created mine by using batch key generation.

I put together a list of pros and cons of large keys on SuperUser, also giving references further references. This answer on the purpose of multiple keys also might be of interest, although you already seem to be aware of the implications and possibilities using subkeys.


Decoding SHA-512 value How does the SHA-512 decoder on the following page work?
http://md5hashing.net/hashing/sha512#main

Hash values supposed to be unable to reverse. Is this page fake?

The site does only provide a rainbow table (a lookup of the possible text from the hash).

So it is simple a database with all hashes saved (so far because a user has entered the text for the searched hash before).

If you enter a hash value (e.g. 3d24c2171cac6da8435ff671c8408189688101be2581d20870a2cb508870048afec15eecd7ed8c406d4d86da746c8caf66db75d9060543dd5d29faca95819707) that was not hashed by them then the following error message appears:

Results not found in DB or your request exceed execution time. Anyways - please try again later.

Also they clearly state that they only provide a rainbow table:

"Decryption of hash (unsolted) is impossible, but we offer reverse decryption via our database (~245M records, and counting)."


Sandbox for GNU/Linux secure enough to run malware in it without harm I am seemkng for a sandbox for Linux secure enough to run malware in it securely. It should allow

create different sandboxes
run different programs in them, including the ones requiring admin privileges (in this case sandbox must give them simulated admin, indistinguishable from real admin if low level access to OS internals and hardware is not needed).
restrict their access to different APIs, for example restrict internet access to non-whitelisted processes, driver installation, access to different folders, launching processes except the ones from whitelist, low level media access, etc ... The restrictions must be configurable.
each sandbox should have its own folder/fs where modified files are stored, copy-on-write should be used to allow the sandboxed processes to write
sandboxed processes within the same sandbox should be able interact with each other, but shouldn't with the rest of the processes (unless allowed).
all the changes made in the main system should be available in sandbox
You should be able transfer files from sandbox to the main OS easily
You should be able to run apps utilizing GPU in it.

The example of such a sandbox for Windows is SandboxIE. Sometimes I had to run malware in the sandbox, the malware hasn't infiltrated the main system. There is even a malware analisys solution (bsa.isoftware.nl) based on SandboxIE.

Is there any solution for Linux which gives comparable security without virtualizing the whole OS in KVM/Xen? Is it possible to achieve this effect combining SELinux with LXC and some copy-on-write file system? Is there a solution which does this?

Create different sandboxes

Linux currently supports six kernel namespace types:

IPC namespace
Network namespace
Mount namespace
PID namespace
user namespace
UTS namespace

  run different programs in them, including the ones requiring admin privileges (in this case SandboxIE gives them simulated admin).

fakeroot can give programs simulated root access, but you'll find that this is actually not as useful as you think. A fully sandboxed program is a useless program and a program that's not sandboxed enough fails to fulfill the security requirements.

  restrict their access to different APIs, for example restrict internet access to non-whitelisted processes, driver installation, access to different folders, launching processes except the ones from whitelist, low level media access, etc ...

In Linux, these access are restricted using regular system privileges mechanism. There are several systems:

traditional Unix filesystem permission: restricts who can access which files
capabilities: restricts the system calls that can be made by a root process
SELinux/AppArmor/TOMOYO: mandatory access control to enforce security policies

  each sandbox has its own folder where modified files are stored, copy-on-write is used to allow the sandboxed processes to write

Linux supports copy on write filesystem like btrfs, or an overlay filesystem like UnionFS or OverlayFS may be used.

  sandboxed processes within the same sandbox can interact with each other, but cannot with the rest of the processes (unless allowed).

This is kernel namespaces.

  sandboxed processes in fact have the lowest integrity level, but they don't sense this at most cases.

Linux don't have a concept like integrity level. However, Linux allows much more fine grained integrity configuration with the capabilities system and the mandatory access control frameworks.

  all the changes made in the main system are available in sandbox

You can do this with an overlayfs.

  you can transfer files from sandbox to the main OS easily

This depends on how the containers are configured.

These are the kernel features that exists for programs that can be used by program to take advantage of. The userland programs you would use to use these kernel features are usually either Linux Containers (LXC) or Docker.


Does shuffling a hashed password increase its security? I am making a web app and I'm now stuck on making the login secure. I'm thinking of adding a salt to a user-inputted password and then hash it. (md5 or sha for example)
and then I will reshuffle the results.

eg:

$salt = "hello";
$password = "password";
$newpassword = md5($salt.$password); //lets assume the result is 1234567890

I will reshuffle the order of the hash like exchanging the first and last character then 3rd and 3rd to the last.

the result will look like:

0284567391

Does this make the password more secure? Please don't suggest some hardcore encryption stuffs. I just need something that will make the passwords secure than just having them encrypted using a cracked hash algorithm.

The "shuffling" you intend is conceptually a kind of encryption: you apply a secret convention on the result. This changes anything to the security only if the convention is indeed kept away from the prying eyes of the attacker -- the attacker who just plundered the database of hashed passwords, and thus had some extensive access to the internals of your server. But the server must know of the shuffling (since it applies it). Therefore, it seems rather improbable that your shuffling is unknown to the attacker. Conclusion: your shuffling is probably not useful.

What would increase security would be to use a proper password-hashing function, which includes a salt in a cryptographically sane way, and is adequately slow (i.e. made very slow through thousands or even millions of iterations). This is called bcrypt. This sort of thing must not be improvised; homegrown schemes are very rarely secure (most are deemed secure by their inventor, but reality has a tendency to be unkind to the dreams of the self-made inventors, especially in highly technical areas where success cannot be tested, in particular cryptography).


How to generate an OpenVPN 4096 or 8192 bit static key? How to create an OpenVPN static / pre-shared key with key size 4096 or 8192 bit?

openvpn --genkey

Creates 2048 bit strong keys only.

Static key. Not CA.

The static keys are used to derive symmetric keys and authentication keys. There is no need to have a larger key. In fact, it would have been perfectly fine if OpenVPN used a 256-bit static key and used a KDF (Key-Derivation Function) to expand it into however many bits it needs. It's important to know that symmetric cryptography differs from asymmetric cryptography in that you only need enough bits to make exhaustive search impossible. Larger key sizes do not meaningfully improve security.
According to OpenVPN documentation, the 2048-bit key houses four independent keys which are used for encryption and authentication. You can't increase the size because no more bits are needed.


Securing data and files so as they won't be openable anywhere else but your own server? I know this question might seem a bit weird, but I believe there should be a way, at least to reduce the ability to download or use script to download files from storage. I tried a lot but found nothing useful.

Consider that you have a storage server containing thousands of millions of files and data, how can you make them openable only from that server and un-openable from any other machine?

I know it's not possible to fully avoid attackers, so after securing all servers I thought by myself if it could be possible to make data more secure than what they are at the moment. So even if someone could hack servers, won't be able to carry your data anywhere since the file will be nothing but a broken stuff from that time on.

Maybe my question is not 100% right, so I'm completely open to any suggestion and edit for my question. The only thing I need, is to secure my data in a way that no one can use them outside of my server.

Why do you believe there should be a way? If an attacker can hack your server, they can presumably look at the data on that server - from that point, they could copy the plain data to anywhere else. We know the data must be plain at that point, since your server needs to be able to read it, and you need to be able to access the files (else it's a bit of a black hole). You could encrypt files in such a way that only your specific server can decrypt them - you could even use a hardware security module to make exporting the keys more difficult - but since they have to be decrypted for use, an attacker could simply take a copy at that point.

Think of it as being like a painting - you can protect the painting itself relatively easily, by locking it in a safe, but as soon as you want to display it, anyone can wander in with a camera and make a copy. For paintings, that's less of an issue - you can easily tell when a copy has been made. For digital data, there isn't any difference between the original and the copy, so whatever you can do with the original, you can do equally well with the copy.


nmap detects opened port but can't connect with telnet I've made an scan to one single IP with nmap and it reports that the port 65301 is opened, and even it detects that it's maybe the service pcanywhere.

sudo nmap -p 65000-65535 -sV x.x.x.x
Starting Nmap 6.00 ( http://nmap.org ) at 2015-06-04 22:43 CEST
Nmap scan report for x.x.x.x
Host is up (0.96s latency).
Not shown: 336 closed ports
PORT      STATE SERVICE     VERSION
...
65003/tcp open  unknown
65301/tcp open  pcanywhere?
65308/tcp open  unknown
...

But when I try to establish a connection to that port with telnet, it just refuses the connection:

$ telnet  x.x.x.x 65301
Trying x.x.x. ...
telnet: Unable to connect to remote host: Connection refused

What may be the cause of the "connection refused": has nmap returned a false detection and the port isn't really opened? Or maybe there is some additional restriction that makes telnet not being able to connect though the port is opened?

The same happens with the other port with service "unknown", but that fact that thugh it has detected a possible service (pcanywhere) but telnet get connected intrigues me.

UPDATE: I attach the results of the execution of the command proposed by StackzOfZtuff, it detects the port as closed, which I think it's the normal behaviour (moreover the first command now reports the port as closed now):

$ sudo nmap -vv --packet-trace -p 65301 -sV x.x.x.x
...
Initiating SYN Stealth Scan at 10:24
Scanning x.x.x.x [1 port]
SENT (0.1877s) TCP y.y.y.y:53502 > x.x.x.x:65301 S ttl=53 id=3258 iplen=44  seq=3444593130 win=1024 <mss 1460>
RCVD (0.1881s) TCP x.x.x.x:36876 > y.y.y.y:41094 RA ttl=255 id=62429 iplen=40  seq=0 win=0
RCVD (0.2064s) TCP x.x.x.x:21053 > y.y.y.y:41094 RA ttl=255 id=62430 iplen=40  seq=0 win=0
RCVD (0.2084s) TCP x.x.x.x:42352 > y.y.y.y:41094 RA ttl=255 id=62431 iplen=40  seq=0 win=0
RCVD (0.2110s) TCP x.x.x.x:4036 > y.y.y.y:41094 RA ttl=255 id=62432 iplen=40  seq=0 win=0
RCVD (0.2308s) TCP x.x.x.x:30952 > y.y.y.y:41094 RA ttl=255 id=62433 iplen=40  seq=0 win=0
RCVD (0.2352s) TCP x.x.x.x:65301 > y.y.y.y:53502 RA ttl=255 id=62434 iplen=40  seq=0 win=0
Completed SYN Stealth Scan at 10:24, 0.05s elapsed (1 total ports)
Initiating Service scan at 10:24
NSE: Script scanning x.x.x.x.
NSE: Starting runlevel 1 (of 1) scan.
Nmap scan report for x.x.x.x
Host is up (0.0061s latency).
Scanned at 2015-06-06 10:24:17 CEST for 0s
PORT      STATE  SERVICE    VERSION
65301/tcp closed pcanywhere

It's possible that the device is only allowing connections from specified IP address ranges(ex:192.168.1.0/24 for it's local subnet). So while scanning it may show the port open and telnet running, unless it sees your IP address in that range, your connection will be refused.


Take ownership on TPM 2.0 When I try to take the ownership on my TPM 2.0, I run the tpm2_takeownership command. For the first time, I got this error:

 ./tpm2_takeownership -e 0123 -o 0123 -l 0123
......Change Hierarchy Owner Auth Succ......
......Change Hierarchy Endorsement Auth Succ......
......Change Hierarchy Lockout Auth Error. TPM Error:0x98e......

Now, when I want to change any authorizations, it fails :

./tpm2_takeownership -l 0123 -o 0123 -e 0123 -L 0123 -O 0123 -E 0123
......Change Hierarchy Owner Auth Error. TPM Error:0x9a2......

Or

./tpm2_takeownership -c

Start to clear the Hierarchy auth....

ClearControl Failed ! ErrorCode: 0x9a2

I didn’t find any informations about the error code, so I checked the sources, and I found this code (line 127). All these defines are of the same type as the error code printed in the tpm2_takeownership command. (line 91)
It goes up to error 0x97F, but there are no signs of the error code 0x9a2 and 0x98e.

The version of my tpm2-tools function:

./tpm2_verifysignature, version 1.0.0
./tpm2_getpubek, version 1.0.0
./tpm2_nvreadlock, version 1.0.0
./tpm2_evictcontrol, version 1.0.0
./tpm2_loadexternal, version 1.0.0
./tpm2_nvwrite, version 1.0.0
./tpm2_nvdefine, version 1.0.0
./tpm2_rsaencrypt, version 1.0.0
./tpm2_quote, version 1.0.0
./tpm2_listpersistent, version 1.0.0
./tpm2_activatecredential, version 1.0.0
./tpm2_unseal, version 1.0.0
./tpm2_getpubak, version 1.0.0
./tpm2_getrandom, version 1.0.0
./tpm2_load, version 1.0.0
./tpm2_createprimary, version 1.0.0
./tpm2_takeownership, version 1.0.0
./tpm2_hash, version 1.0.0
./tpm2_encryptdecrypt, version 1.0.0
./tpm2_makecredential, version 1.0.0
./tpm2_nvread, version 1.0.0
./tpm2_readpublic, version 1.0.0
./tpm2_listpcrs, version 1.0.0
./tpm2_akparse, version 1.0.0
./tpm2_nvrelease, version 1.0.0
./tpm2_hmac, version 1.0.0
./tpm2_sign, version 1.0.0
./tpm2_nvlist, version 1.0.0
./tpm2_create, version 1.0.0
./tpm2_rsadecrypt, version 1.0.0
./tpm2_certify, version 1.0.0
./tpm2_getmanufec, version 1.0.0

The tpm module is loaded :

lsmod| grep tpm
tpm_crb                16384  0

The resourcemgr daemon is running:

ps aux | grep resourcemgr
root     10720  0.0  0.0 170672  1024 ?        Sl   juin16   0:00 resourcemgr

And finally I use the Intel Stack, I think the problem doesn't come from here, as it passes all the tests(~/TPM2.0-TSS/test/tpmtest/tpmtest)

I am currently stuck at this point, so any ideas what these two errors mean (0x9a2 and 0x98e).

Edit: So, I ran a few tests on the TPM2.0-TSS, and especially clock tests:

    CLOCK/TIME TEST:
Q - QUIT THIS TEST GROUP
D - PRINT DESCRIPTION ON ALL CASES IN THIS GROUP
0 - RUN ALL TEST CASES
Please select an action:0

RUN ALL TEST CASES:

CLOCK/TIME TEST:
        passing case:   PASSED!

Current Time:498603768, Current Clock Info:565355598
        passing case:   FAILED!  TPM Error: 0x9a2

And, I have the same error code on this test than I have when I run tpm2_takeownership. Does this mean, the internal clock may cause damages?

EDIT 2: Actually I also have got this 0x9a2 error on these tests:

34 - ASYMMETRIC ENCRYPT/DECRYPT TESTS
35 - VERIFY SIGNATURE WITH EXTERNAL KEY TEST
36 - VERIFY SIGNATURE WITH CREATED KEY TEST
37 - NV EXTENSION TEST
38 - PCR EXTENDED TEST

The 0x9a2 means      the platform auth of the owner auth is not null. It may be from the BIOS itself, or from a previous     takeownership.

The solution is to clear theses authorizations. On a NUC NUC5i3MYHE, there is a jumper.

Pull out the jumper and power off.
Reboot. You will reach a ConfigMenu.
Press [4]Clear the TPM. Be careful, if you had already created keys, you won't be able to recover them.

Now, the 3 authorizations are null, and you can take ownership, and run the tests.


What's Google Inbox request/response obfuscation skill? I Inspected Google Inbox network resources via Chrome Developer Tool.
I saw some request/response payload and result.

This object type is not readable for human. I've never seen this kind of security. Is this general dev stack? It looks very safe.

This object type is not readable for human.

Why should it? It is intended for a computer and not for a human.

  I've never seen this kind of security. Is this general dev stack? It looks very safe.

I doubt that this is primary a security feature. My guess is that they use some higher level development tool which just generates this kind of stuff. The aim is not to be readable by a human but to provide efficient processing by a machine - which often includes that it looks strange for humans. Such higher level tools not only speed up development but also often deal with the security problems better than handcrafted code.


Is it possible to retrieve data from a intermediate node in Tor browser I'm using Tor browser for my internet surfing and check my email,
my questions are

Is my internet services provider able to see the websites I visited
Is it possible to retrieve a login information like username and
password of my email account from intermediate node between Tor
browser and web server
Is it possible to retrieve email content like mail body and
attchments from intermediate node

Is my internet services provider able to see the websites I visited

No. Your Internet service provider can not see which website you visit (I suppose you use Tor correctly without your personal settings/configurations you may have done. Tor will take care of your DNS leaks and so on)

  Is it possible to retrieve a login information like username and password of my email account from intermediate node between Tor
  browser and web server

First of all, using your credentials to log into this or that website breaks, by time, the anonymity Tor provides you. Also, an attacker may eavesdrop the exit nodes where Tor does not control the traffic.

  Is it possible to retrieve email content like mail body and attachments from intermediate node

Once again, using your credentials through Tor breaks your anonymity. Tor intermediate nodes are too hard theoretically to break (of course, there are buts). Real life eavesdropping that targeted Tor users has been done on exit nodes such as when this Swedish researcher compromised username/passwords of lot of Tor users (in which case, of course, your attachments and so on are also compromised)


Is it illegal to use Fake User-agents? Is it illegal to impersonate user-agents when you are crawling a website?

If so, what and how a legal action can be taken against the faking requester? Is this law applies only for crawlers or a user impersonating a browser from a different browser(changing user-agent as firefox but making the request from chrome)?

It is not illegal here in the US.

I would be wary of seeking legal advise on the internet, especially without giving a specific location. Laws change city to city as they do country to country.


Worthwhile from security standpoint to limit database server user for ASP.NET website to only EXECUTE on stored procedures? I know that obviously we must avoid sql injection attacks through user input validation and  parametrized queries.  There's already a firewall in place on the database server to limit remote connections to be accepted only from the web server.

Would it also add value from a security standpoint to limit the actual database user account that the ASP.NET website uses to the EXECUTE permission only on the stored procedures that they need?  All database interaction would take place using these stored procedures.

This seems to me that even in a scenario where an attacker figures out a way to access the database connection, the attack is limited to only executing predefined queries and no open ended queries?

There are two main (security) reasons to do this, above and beyond just using parameterized queries:

Parameter type enforcement
Least privilege.

The principle of Least Privilege requires you to allow any entity (user or application) access only to whatever it needs to do the defined task. If you don't restrict the webapp only to the SPs, the application could potentially execute any arbitrary query.
Note that this is relevant in two situations: preventing an attacker, that managed to find a vulnerability in your application (either SQL injection, or any other vuln that could allow him to execute code), from running malicious SQL queries; and, much lesser risk, developers that are looking for insecure, unapproved shortcuts (or even malicious developers).
Granting only EXECUTE privileges on the required SPs, will stop the application from running any query that was not predefined.

Wrt enforcing parameter types, while it is possible to implement this in other ways, this brings the type enforcement to the database, but before it hits the db server. I.e. using the types that are actually defined on the database, and without accidentally skipping a parameter.

Note that in order to do this properly, and avoid some common mistakes, you want to:

define a specific user account for the ASP.NET application
assign the account to a custom DB role
remove the account from all other roles, such as dbo.
grant EXECUTE privileges to the custom DB role you created
remove all other privileges on the SPs, tables, and other DB objects. This includes default "public" roles, and so forth.
ensure that the custom DB role has no other privileges.


What is the disadvantages of storing user role including admin in a session variable? In my projects I always fetch roles from DB and store them in a session variable, then to check If a user has access to admin pages I just check the session.
Let's consider I use a private hosting what is the drawbacks of this approach?

Let's say a non-admin user edits their session cookie and changes admin=false to admin=true.  Is that a problem, that any user can trivially bypass all your access controls?

You should give each user a session token like 3f235219b2cca1842b4ae2dd9ec4a1a8570f2edf that is stored in your database with a lifetime.  You check that the token exists by constant time comparing the whole string and if the user with a token exists and is not expired, then you check if the user has privilege or not.

You also probably want to have it be an HTTP only (not editable by javascript) and Secure cookie (only set via https to prevent MITM).

EDIT: http is a stateless protocol.  Meaning that each http request coming to your server starts over from scratch; the web server isn't aware if you've accessed this page for the first time or are continuing a multi-page visit to the site.  The basic way to create a session is to have some identifying variable get passed back to the webserver with each request; say through a hidden GET/POST variable, a changed URL, or more typically a cookie.  A cookie could be set in an HTTP response from a webserver like:

HTTP/1.1 200 OK
Content-type: text/html
Set-Cookie: user_role=guest
...

and then when you make your next request to the webserver:

GET /index.html HTTP/1.1
Host: www.example.org
Cookie: user_role=guest
...

Note that since the user has full control of their web browser, you can't really trust the variables they are sending back.  E.g., they could change user_role=admin.  So the solution is to store the information about the user on the server-side.  So a user authenticates with the server, then you give them a token (some long random string fSFrKtJXAnjo9wacE3XNMy) and store on the server-side that token=fSFrKtJXAnjo9wacE3XNMy is tied to someone with user=guest (and anything else you need to know about their session state).  You want http-only cookies, so its harder for XSS-style attacks to steal your session cookies, and secure so eavesdroppers can't trivially listen in.


What is the weakness of OFB in 8bit mode? I'm currently trying to understand the difference between "regular" OFB with full-block feedback and OFB with 8-bit feedback and, in this context, the difference between this two modes regarding security.

Please correct me if I am wrong: Given an example using AES256 and a blocksize of 128 bytes, the general procedure would be the following:

          IV     _____________
          |      |           |
          v      |           v
Key -> AES-256   | Key -> AES-256
          |______|           |____....
          |                  |
          v                  v
    P -> xor           P -> xor
          |                  |
          v                  v
          C                  C

With full-block feedback, I would get a 128 byte long output from the first AES block, which would then be XORed with 128 bytes of plaintext, which would result in 128 bytes of cipher text.

When using OFB in 8-bit mode, only the first 8-bit of the plaintext would be XORed with the first 8-bit from the output of the first AES block.

The main difference I can see is that it would take longer to encrypt / decrypt the plaintext since it would need more iterations, but what exactly is the problem regarding security?

The main reason for this question is this Post.

As explained in note 7.24 of the Handbook of Applied Cryptography, the weakness is that using less than a full block of feedback means that the algorithm will use, on average, a shorter cycle; and since OFB generates a key-dependent stream which is to be XORed with the data to encrypt, you really do not want to cycle, because that would put you in the position of the infamous two-times pad.

Now the average cycle length would still be around 264 bytes for a 128-bit block cipher like AES, so this should not be a really serious practical issue (264 bytes is still quite huge, counted in millions of terabytes). Yet this is sufficient to declare that OFB is always inferior to CTR mode. Since OFB with 8-bit feedback is also quite slower than CTR, there is no good reason to use it.


Windows BitLocker- Is the drive Password the same as the Key used by AES to encrypt the drive? I am using BitLocker on my Win10. I encryted my usb drive using my Windows BitLocker with a strong password.

I know that Bitlocker uses AES-~256 bit key for encryption. My question what is the key and where is it. Is it the same as the password i set?

BitLocker, and most full disk encryption systems, do not directly use your password for encryption. Instead, your password is used to encrypt a random, computer-generated master key which is used to encrypt data, and the encrypted version of the master key is stored on the hard drive. When you unlock the drive, you decrypt the stored master key which is then able to encrypt and decrypt the rest of the drive. This scheme makes it possible to change your password quickly without needing to re-encrypt every byte on the drive (only the comparatively small master key needs to be re-encrypted).


Why does Paypal send TWO verification payments not just ONE? The process would be easier if there was only one payment, but there must be some security or financial reason for Paypal to send you two random payments

I suspect a 1 in 99 chance of guessing the deposit amount on a fake account using a stolen card, the odds were just too high.

There's 9801 (99 x 99) possible outcomes that anyone trying to guess the deposits would have to pick from - vs the 99 outcomes from one payment.

In order to achieve the same number of outcomes from one payment they would have to deposit anything between 0.01 and 98.01 which would be very generous of them.

But not a UX question really.


A SIM module-based security system and radio signal interruptions I would like to setup a simple alarm system using something like a Raspberry Pi or Arduino, some sensors, and a SIM module to send me an alarm when an intrusion is detected.

If I were dealing with an adversary using a Cell-Site Simulator/IMSI Catcher or a signal blocker, would they be able to prevent the system from working? Particularly, can they prevent the alarm/message from reaching me?

What can I do to ensure the system works even in the presence of IMSI Catchers/Cell-Site Simulators/signal blockers?

Radio signals are public and prone to a number of issues. Not just the complex simulators you ask about, but a $10 home-made signal blocker can prevent your system from transmitting (or even a 30 yr old microwave).

The way to avoid this is to have a wired backup line or a detection process to detect signal interruptions.

A heartbeat signal to a monitoring process would alert you if the system failed or was blocked from transmitting. You then need to devise a response function for when the heartbeats stop coming in, but that's the general design pattern for this problem.


Updated version of Browser Security Handbook Google's Browser Security Handbook is a brilliant resource for web application security, and in particular, for understanding how browsers behave.  It discusses many issues, and contains tables showing behavior for a variety of browsers (MSIE6-8, FF2, FF3, Safari, Opera, Chrome, Android).  The latter are especially useful, because they concisely show the variety and diversity of security-relevant behavior among popular browsers.  If you are writing a web application, this helps you ensure that you have covered all likely behavior of all likely browsers.

However, the handbook hasn't been updated in a while.  Also, its tables don't list some of the most modern browsers (they haven't been updated to reflect the most modern versions of many browsers).

Is there an updated resource that provides information comparable to the Browser Security Handbook, but contains more up-to-date information?  Is there a place with a summary of behavior of browser behavior, across many browsers, for different kinds of security-relevant situations -- similar to the Browser Security Handbook has, but for more modern browsers?

The Browser Security Handbook laid the foundation for his book: The Tangled Web which (as of Nov 2012) is the most current book form the same author.  I purchased the book about a year ago and think it's a fantastic read.

As far as I know he hasn't released any newer or more updated information (appendix, etc) outside of his blog. But this entry as of 11/16 says he is working on a new book, though I haven't seen specifics yet.


Is this email legit or scam? got this email on gmail spam folder was wondering if this is legit or not ..

Almost certainly (~98% confidence) it's a scam. 99.9% confidence if "pfax8fg0gq" isn't actually one of your passwords, but even if you have used that password, it's still more likely to be a message from somebody with access to the password database of the site you used it on trying to scare you, rather than truthfully having compromised your machine.
A handful of clues in no particular order:

Gmail recognizing it as malicious / junk
This is a very common scam format (which is why Gmail recognizes it), practically a form letter and the modern equivalent of the "Nigerian Prince" 419 scam. I've gotten it multiple times myself (with minor variation in wording), only occasionally with an actual password from my past, and never paid or gotten "embarrassed" by the consequences of not paying
Sender name and email address don't match
Awkward, poorly-written English indicative of the author not being fluent or at least not a native speaker
An actual blackmail attempt would have no reason not to provide evidence (such as a screenshot from the supposedly-captured video, and/or one of the harvested email addresses); the lack of any is strong evidence against it being legitimate.
The terminology is vague enough ("the adult videos website" rather than any specific site, "video you were viewing" without any details, "to have fun"/"it is u" without any specific reference to what you were doing that might depend on what body parts you have or how you watch porn, etc.) to be plausibly true for a large number of people when, again, an actual blackmailer could and usually would be more specific.


How do I share secret key files with Docker containers following 12 Factor App? I am building an API and trying to follow the 12 Factor App methodology. Using Docker, the methodology says containers must be disposable.
Assuming the API will have high traffic, multiple docker containers will be running with the same app, connecting to the same database.
Certain fields in the database are encrypted and stored with a reference to the file containing the passphrase. - This is done so the passphrase can be updated, and old data can still be decrypted.
With a Docker container and following 12 Factor App, how should I provide the key files to each of the containers?
Am I correct in assuming I would need a separate server to handle the creating of new key files and distributing them over the network?
Is there secure software, protocols or services that do this already, or would I need a custom solution?
Update
I have read that Vault by HashiCorp or Kubernetes can handle secret sharing between containers however, I am not sure if that will work for me, as I need an automated task to create a new passphrase file, and then distribute it to the containers.

12 factor says that the config needs to be stored in the environment. So why not simply pass the secrets to the container over environment variables? If there are many, pass a master key to a key store that is lying on a volume mounted at start.


it is possible to make some wifi router out of service without have the connection password? Lets say i want to make some WiFi router out of service.
I can connect to the router and close the WiFi connection or change the password.

But in this case i need to have full access to the router.

But if i don't have access to the router ( i mean that i don't have password )
 ==> is it possible to damage it in such a way that disable the service.

You can deauthenticate users.
With aireplay-ng this makes users disassociate with the router denying them the service

This with the option -0
So

Aireplay-ng
    -0 [how many packets you wannt to send] \
    -a [mac of ap] \
    -c [mac of client you want to deauthenticate] \
    [interface]

If you are associated to the network you could arp-spoof the clients to belive you are the router and just do whatever you want with the traffic


Is the mount manpage saying nosuid *is* secure, or is *not*? I'm a bit confused about the description of nosuid in the mount manpage on this RedHat system I'm setting up:

nosuid Do not allow set-user-identifier or set-group-identifier bits to
       take  effect.  (This seems safe, but is in fact rather unsafe if
       you have suidperl(1) installed.)

So I looked up suidperl(1) and discovered The suidperl Story, and was properly entertained for five minutes. I also learned that setting nosuid may not improve security as much as one might like, but I'm back to wondering how nosuid decreases the overall security, compared to not using it.

As far as I understand, (I'm not using perl and even less suidperl), the manpage doesn't says nosuid is less secure, just that despite being more secure at first sight, it can be easily defeated by suidperl.


Application Security Input Validation: Validating Environment Variables and Config files I am watching a training video called "Creating Secure J2EE Code". The video makes this statement:

  Perform all validation in a secure context on the server. Do not rely
  on client-side validation as a security mechanism. Validate all
  application input, including user input, API return values,
  environment variables, configuration files, and other applications.

Validating environment variables and config files is a new concept to me. Can you please provide a high level overview of what this might look like?

My thoughts are to treat both Environment Variables and Config files similar to user input. I would:

Sanitize it,
Test Length (Min & Max),
Test Range,
Test format
Test type (int, decimal, char, etc)

I am assuming config files would contain Key/Value pairs. Im not certain how to handle a configuration file that may contain any other format.

Am I on the right track?

(this should probably be a comment but i's a bit verbose)

  Validating environment variables and config files is a new concept to me

At first this struck me as odd - then I remembered that not alJ2EE applications run in a controlled environment. It's a question of trust. I deal with web applications where I'd put more trust in the config of the environment than in the code itself - here that statement makes no sense. OTOH if I were writing an app to be run on desktop PCs then I'd be a bit suspicious of anything fetched from the local system.

  I would....sanitize it

No.

Validate inputs
(i.e. accept or reject them in their entirety)

Sanitize outputs
(convert them to a representation appropriate to the medium they are going into).

Sanitizing inputs is a really bad idea. You don't know where the data is going until your code looks at it. If it can arrive in your code in a state where it can do something unexpected (code injection, buffer overflow etc) then its too late to fix the problem.


Given two passwords, what is the fastest way to compare the strength of them with john? Given two different known passwords, let's just call them A and B for now, what is the fastest way to compare their strength with John the Ripper?

I know that I could just add two users to my Linux system and run john on my /etc/shadow. It will be more efficient to then just extract those two users from /etc/shadow and run john on those two only. But that would still use Blowfish or whatever secure algorithm is used, and I do not want to test the algorithm, just the passwords. I could configure my system to a weaker algorithm for that purpose. But I'm looking for an even smarter, faster way. Preferably even adding a custom dictionary for words that might be used in one of the passwords.

The actual use case is to compare the strength between:

a slightly longer password that contains words from a dictionary but is obfuscated to use characters from four character classes
a slightly shorter password that uses characters from three character classes but no dictionary entries

There's essentially no way to determine which password is stronger in absolute terms because the strength of passwords depends on the way an attacker is approaching cracking the passwords.  However, it is possible to figure out (for a given wordlist and set of mangling rules) which one would be cracked first by an attacker.

Start by determine what wordlist and rules you want to use.  I would probably use the rockyou.txt wordlist that is well known and combine it with one of the rulesets listed on the openwall wiki.

You can run john in a mode where, rather than cracking passwords, it will just generate the candidate passwords to be tried.  This is called stdout mode.  For example, you can use:

john --wordlist=rockyou.txt --rules=Korelogic --stdout

This will produce a list of all of the candidate passwords, in the order that they would be tried by JtR.  If you have enough disk space, you can just tee this to a file for later analysis.  If you really only care about the two (or so) passwords you're studying, you can just grep for those to get the order they would be tried:

john --wordlist=rockyou.txt --rules=Korelogic --stdout | grep -E -n '^(password1|password2)$'

Thanks to Hector for reminding me of the -n flag to grep.  This will give you the line number for each of the passwords when attempted, showing you (relatively) how far down the generated password list they are -- in other words, how quickly an attacker gets to them.

Alternatively, grep as follows (suggested by dave_thompson_085) to not care about special characters:

john --wordlist=rockyou.txt --rules=Korelogic --stdout | grep -n -x -F -e 'password1' -e 'password2'


How to reliably backup to cloud services without hampering security? There is a huge number of articles advising to enable two-factor authentication on sensitive cloud services. I understand the benefits for my accounts' security, but doesn't it defeat the purpose of cloud backups ?

For example, if both my phone and my laptop get stolen (not far-fetched), I just lost my two-factor auth app and my recovery codes. I therefore lost all access to my data with my devices, which was what I wanted to protect myself against when I set up cloud backups.

So, what's a good strategy to backup data in the cloud, keeping a good level of security while being sure not to loose access when I need it ?

If your concern is avoiding losing all of your physical assets (laptop, phone, etc...) you could simply encrypt your files using any software you like and then upload redundant copies to two or more storage services which you think are the most stable and secure. That said naturally you would want to choose a great encryption algorithm and use a strong password that would be very hard to break. This could be done easily with PGP, TrueCrypt, or VeraCrypt but there are also plenty of other options. A simple SFTP server on a cloud compute platform like AWS would work well for what it sounds like you need.


Using an in-browser tabula recta to generate passwords I've been working on an idea for a stateless password manager, inspired by this blog post. I'm using a in-browser pseudo-random number generator (seedrandom.js) seeded with a user's master password to create a unique (?) 26x26 tabula recta of characters.  The user then chooses a starting point for each website and follows a chosen pattern across the grid to create/access their passwords.

Seedrandom.js uses the RC4 (RC4-drop[256]) stream cipher, which I don't think is considered secure for encrypting information anymore.  Q1: Does this matter if I'm only using it as the source of randomness for a 26x26 grid of characters that won't ever pass over a network (everything is generated client side in the browser)?

Q2: Also, what's your analysis of the strength of this system against an attack, both before and after the master password for a user's grid has been exposed?  This previous question talks about possible attacks on a tabula recta, but answers focus mainly on keeping the physical token safe, which doesn't apply here.

These are my back of the envelope calculations:

Before master password is known, guessing a 16 character password:

log_2(88^16) = ~103 bits of entropy, which will take a very long time to crack in any context.

After master password is known, brute forcing a password from the grid:

(26*26 cells) * (20 common patterns) * (8 pattern directions, including diagonals) * (20 potential password lengths, 10-30chars) = ~2 million options

So on average this would take about 2 million/2 = 1 million guesses to crack.  Depending on the context, this would be cracked in anywhere from ~400 days (rate limited web form, 100 guesses/hr) to << 1 second (database leak, fast hashing algorithm, 1e10 guesses/second).

There's a basic demo of this project here.

Your system would probably work in theory, but seems significantly flawed in practice.  There are several practical weaknesses in the way it will be used:

You don't describe how you will convert the master password to the seed for the RNG.  This is potentially a weak point.
You haven't specified how users will associate a starting point with a particular site.  Without a way to save this, it will be impossible to use.  Depending on a user's memory will lead to password reuse.
Users will tend to pick the same or a small number of starting points in the tabula recta based on human tendency, significantly reducing your entropy.
A tabula recta involves more manual work than users will actually want to use in practice.
RC4 has biases in the initial keystream.  If this is not corrected for in your RNG, this will insert biases into your tabula recta.
You do not provide a good way for users to rotate passwords other than picking a new starting point for that site.  Combined with #2, this will make it even harder for users to remember the starting point for a given site.


How is TDS authentication data protected? I'm currently testing an application, which connects to a MS-SQL database. Through Wireshark, I can see that the application uses TDS to connect to the database. Furthermore, I can see that both the queries and results are UTF-16 encoded and provided in plaintext.
However, I am unable to find the credentials used to authenticate with the database. How are they protected? And how can I access them without reverse-engineering the application?

It sounds like (§2.2.6.4) the password is obfuscated with some simple bit flipping:

Before submitting a password from the client to the server, for every
byte in the password buffer starting with the position pointed to by
ibPassword or ibChangePassword, the client SHOULD first swap the four
high bits with the four low bits and then do a bit-XOR with 0xA5
(10100101).

If you can pull the password bytes out of the TDS stream - which presumes TLS is not in use, and I don't know how well Wireshark's parser highlights the password data - just reverse the process to get the password:

After reading a submitted password, for every byte in the password
buffer starting with the position pointed to by ibPassword or
ibChangePassword, the server SHOULD first do a bit-XOR with 0xA5
(10100101) and then swap the four high bits with the four low bits.


Should IDM be private or exposed for app login? In the diagram below, I have two options for authenticating into a protected resource. Both options use an Identity & Access Management (IDM) tool (in this case keycloak) to store credentials and present as a JWT once properly authenticated. The only real difference between both methods is where the IDM (keycloak) sits and thus where it is exposed. In option 1, the IDM is private and not exposed to the internet (but only exposed to the application doing the authentication) whereas in option 2, the IDM is exposed publicly such that the application redirects to the IDM to handle all of the authentication.

On the surface it seems pretty logical to protect such a crucial piece of software infrastructure (the IDM) but then why would Keycloak in particular advertise/support such a robust login page?
Which option is preferred for security?

I am not familiar with the acronym "IDM", but for this answer I will assume it means the same as an Identity Provider (IdP) in the SAML / OIDC sense.
The only difference I can see between those diagrams is whether you use your login page, or keycloak's login page.
I see your concern that Option 1 exposes the IdP to direct attack, but isn't your login page just a shallow skin for the keycloak login page? What are you really hiding? Do you believe that your developers can build a better and more robust login page than the keycloak developers?
Also consider also these points:

With Option 2, your application never handles passwords, which can save you substantial engineering effort to harden and protect them. Also, if you are in an audited environment, being able to say "We don't handle passwords, and here are keycloak's security certifications" is a much easier story to tell.
With Option 2, you can configure your app to accept 3rd party identities that your app should not ever see the password for -- for example if you allow partners to log in to your platform by authenticating against your partner's Active Directory. Same if you want to allow users to link their Google or Facebook accounts, etc.
Sometimes the fact that the client (browser) can reach the IdP is actually an important piece of information; for example if the IdP is in a backend prod network or a corporate network (ex.: ADFS in front of the prod AD), then redirecting their browser to the IdP proves that the client is also VPN'd into the backend network.

Summary: I don't see a security upside by replacing the IdP vendor's login page with your own; and actually a lot of security downside if the login page you build is less robust than the one built by a security specialty vendor. Also, Option 2 gives a lot more deployment flexibility, which you can leverage for increased security.