Anything particularly wrong with putting an auth code in marketing emails? I've been working on my first project, and my initial registered users haven't been particularly sticky. I'd like to send them an email with some news and information and have them be instantly logged in when they hit the call-to-action link. I was thinking about generating an auth code with PHP's random_bytes(), and storing it in a table with their corresponding user_id.

So basically, the email would be:

  Hey oldUser2017, newUser2018 sent you a message! Click here
  to see it instantly and not even have to log in or reset your password
  or anything annoying!

And on the backend

userId = getUserIdFromAuthCode($get['authCode'])
if(userId){
 $session = getUserDetailsFromUserId(userId)
}

Given that this is how we authenticate an email address and activate an account:

What would be so bad about me doing this?
Is PHP's random_bytes() good enough, and what length would you use?
Should it expire?

I have personal experience of a system that did pretty much this. I didn't develop it, I just had to handle the fall-out when the "instant login" went horribly wrong :)

The problem we encountered was that some users forwarded the emails to other people, not realising that the email effectively had a credential embedded in it. So when the person who got the email forwarded to them clicked the link, they were logged in as the original user.

You could argue that it is the fault of the original user, but to me, it's not at all obvious that clicking a link will automatically log you in as someone, so it's not reasonable to expect users to be particularly careful when forwarding.

Referring to the comment on @ideaman924's answer. I think users are more likely to recognise the risk of forwarding a password reset link to someone, than an opaque "instant login" link.

A better solution in my opinion would be to have a normal login page, but then have a session cookie that lasts a reasonable length of time, including after they close their browser or navigate away from your site. Then if they return within the cookie expiry time, either by clicking the email link or by any other route, they will be already logged in.


Is it secure to make my Threema ID public? I've had Threema for a few days (a couple of friends forced me to buy it). It's pretty neat but I'm afraid that I'm not connected to everyone since my mail/phone-number data is pretty small or outdated.

So, I thought it would be a good idea to post my threema-id to Facebook and tell everyone: "Hey if you want to connect your Threema, add me via 1F33OO7." Is this a good idea? Would that negatively effect my security somehow?

Nope, you should be just fine sharing your Threema-ID. The reason being that your communication is protected with end to end encryption.

  Strength of the encryption: The asymmetric ECC based encryption used by Threema has a strength of 255 bits. Accordingto a NIST estimate (page 64), this corresponds at least with the strength provided by 2048 bit RSA. ECDH on Curve25519 is used in conjunction with a hash function and a random nonce to derive a unique 256 bit symmetric key for each message, and the stream cipher XSalsa20 is then used to encrypt the message. A 128 bit message authentication code (MAC) is also added to each message to detect manipulations/forgeries.

Sharing your ID is akin to sharing your public key. Unless someone has the private key, your communication will remain secure, regardless of who has access to your public key. Threema does all encryption and decryption of messages locally, according to its FAQ, so your private key remains in your possession at all times. And if you want to communicate securely, you need the other party to access your public key.

On top of these facts, you don't have to reply/add anyone who you do not trust. So if anything feels fishy, you can just nuke that person from your "friends" list.

More info on the encryption techniques Threema employs can be found here


Identifying vulnerabilities in simple program with malloc My class is without a textbook, or any structured learning material for that matter. I am doing all my learning through googling and while I am picking it up as I am doing it, it is slow going to be honest.

Class assignment:

  There is a program (psuedocode somewhat) in the file prog-bad.c. This program is not written to be compiled or run, but to be read.

  Find what the vulnerabilities are, and what these vulnerabilities may cause and write a short explanation of what you found.

#include <stdio.h>
int main() {
int studentId;
char studentName[100], buffer[100], percentage[10];

char* firstName = malloc(sizeof(char)*50);
char* lastName = malloc(sizeof(char)*50);
char* graduateLevel = NULL;

printf("\n**********Welcome to Student Registration Service**********\n");
printf("\nPlease enter your 10 digit Student ID: ");
scanf("%d", &studentId);

printf("\nPlease enter your first name: ");
gets(firstName);

printf("\nPlease enter your last name: ");
gets(lastName);

{
    char level[2];
    printf("\nPlease enter your graduate level (UG/PG): ");
    gets(level);
    graduateLevel = &level;
}

strcpy(studentName, firstName);
strcat(studentName, lastName);

printf("\nPlease enter your percentage in Highschool (like 85.50%): ");
gets(percentage);
// Student record saving in file
updateStudentRecord();

printf("\nStudent record saved with the following details: \n");
printf("\nStudent ID: %d", studentId);
printf("\nStudent Name: %s", studentName);
printf("\nStudent percentage in Highschool: ");

printf(percentage);

free(firstName);
free(firstName);

return(0);
}

For my answer I am talking about the use of all the scanf, gets, and printf functions opening up the program to buffer overflow attacks. But I am a little conflicted cause I see that the program makes use of malloc, which I thought was a way to securing up the stack by moving everything to the nonexacutable heap.

So does this mean that the program is not as unsecured as I thought and it is a trick question of sorts?

Malloc is used for -

char* firstName = malloc(sizeof(char)*50);
char* lastName = malloc(sizeof(char)*50);

You are right in that these are on the heap. But what then happens to this data? And how do these functions work?

What else is read from the user? And how?

Reply to your comment below

  So as I see it in my limited scope and understanding, the vaulerabilities are: all the printf, the scanf for studentid

studentid is an int. So I believe the operations on it are safe.

  , gets for first and last name

  But because malloc was used for the first and last name, does that kinda safegaurd all instances of the gets for them.

The data immediately after the gets will be on the heap yes. But does this make it safe? What happens if the user puts in more than 50 characters for either field? I'd suggest reading up on Heap Overflow. Even if corrupting heap data wasn't an issue look at what the code then does with that data. What will the strcpy and strcat do?

  gets for level / gets for percentage

Yes. Not only can these both be caused to overflow but what happens after the "graduateLevel = &level;" line?

Reply to second comment -

  confused as about you last point and what happens after "graduateLevel=&level;"?

"char level[2];" is declared within the curly brace directly above. This means it is only protected within that blocks scope. That scope ends on the line after "graduateLevel = &level;". So graduateLevel points to the address where level used to be. But the compiler no longer has any obligation to make sure level is not overwritten. Any operations using level after this point are undefined behavior.

Now this issue is pretty minor. There is a fairly high chance the compiler won't reuse it. Compared to level being read in from a gets call above its negligible. But code like this frequently leads to odd and hard to track down bugs - some of which can be exploited.

  I am bit confused cause I have read a few places that strcpy and strcat are issues, but I have also found that they are not?

First of all you need to read and understand the definitions for strcpy and strcat. Lets take strcpy -

  Copies the null-terminated byte string pointed to by src, including the null terminator, to the character array whose first element is pointed to by dest.

So, it copies characters out of the source array into the destination array until it hits a null terminator ('\0' - usually byte value 0). Notice the warnings -

  The behavior is undefined if the dest array is not large enough. The behavior is undefined if the strings overlap. The behavior is undefined if either dest is not a pointer to a character array or src is not a pointer to a null-terminated byte string.

So - for the line

strcpy(studentName, firstName);

do these apply? Dest is studentName - a 100 character array. Source is firstName - a pointer to a 50 character array. But is firstname null-terminated? Well its value came from -

gets(firstName);

gets is defined as -

  Reads stdin into the character array pointed to by str until a newline character is found or end-of-file occurs. A null character is written immediately after the last character read into the array. The newline character is discarded but not stored in the buffer.

With the warning -

  The gets() function does not perform bounds checking, therefore this function is extremely vulnerable to buffer-overflow attacks. It cannot be used safely (unless the program runs in an environment which restricts what can appear on stdin). For this reason, the function has been deprecated in the third corrigendum to the C99 standard and removed altogether in the C11 standard. fgets() and gets_s() are the recommended replacements.

  Never use gets().

So. If I were to enter "Dylan" in firstName would contain 'Dylan\0'. What happens if I entered in 200 bytes?

The standard says its undefined but for most real systems its easy enough to guess. Its just going to keep writing into whatever memory is after firstName. What happens then? Well - if it leaves the memory space the process can legally write to the OS is probably going to kill it. But if it doesn't then it will keep running oblivious until either something goes wrong enough to cause it to crash (whatever was supposed to be stored back there isn't any more) or the program terminates. Now as you pointed out the damage is limited - this data is stored on the heap.

So. Lets assume everything continues with no issues until the strcpy. What happens there? strcpy does not know firstName is only supposed to be 50 characters. Or that studentName is only supposed to be 100 characters. Its just going to keep copying until it hits a null terminator.

lastName and strcat have exactly the same issue.


JavaScript code authenticity when loaded from 3rd party website Background

A discussion about not sourcing JavaScript files from other websites (http://www.reddit.com/r/netsec/comments/29hfhz/please_dont_use_externally_hosted_javascript/) got me thinking.

Performance and cost reasons are mentioned that might make sense to have some scripts hosted by 3rd parties.

Question

Is there an existing way to check referenced JavaScript (or maybe even images, other data) has not been changed by malicious actor?

From the top of my head, I'd say you might be able to do that with websockets to download the script and then check its hash, insert into HTML. Maybe. I do not recall any built-in solutions, like maybe <script src="https://foo/bar.js" hash="$5$0xf00...$0xbaa..."></script>.

There are no built-in solutions.  (But there certainly should be!)  You can indeed download the data using XMLHttpRequest 2 and then verify its hash using a JavaScript SHA-256 implementation before doing something with the result (e.g. evaling it, if it is JavaScript code).  This will only work if the untrusted server supports CORS.  The browser cache of the resource can still be used.


How does a key file increase the security of a password manager? Password managers like KeePass often have an option to use a key file in addition to a master password.

I don't understand how this increases security.

(Note: KeePass also allows using a key file instead of a master password, but in this question I'm asking specifically about using one in addition to a master password.)

Since the password database cannot be decrypted without the key file, the key file needs to be stored somewhere - much like the password database itself. Why is the key file harder for an adversary to get at than the password database itself?

Authentication methods can often be divided into one of three areas: something the user knows, something the user has and something the user is.

Passwords are something the user knows. The user memorizes it in his head and can "retrieve" it from memory as and when it is needed.

The key file acts as something the user has. Ideally, this key file needs to be stored in a secure location.

Personally, I have copies of my password database everywhere. My desktop has a copy, my laptop has a copy, my phone has a copy, my tablet has a copy. I store my password database on Dropbox which allows me to keep it in sync between my various devices.

However, I do not store my key file together with my password database. My phone and tablet has a copy of it, because there is no way I can insert a USB drive into those devices, but my desktop and laptop does not. I store my key file on a USB drive which I keep on my person at all times. This makes it slightly more difficult for an attacker to obtain my key file.

Using a key file in addition to a master password is helpful, as it raises the difficulty of successfully compromising your password database.


Can you say that since one time pad encryption is unbreakable, it is the best if used properly? I'm currently reading about one time pad encryption, and I have a question. They say OTP encryption is unbreakable, and this can be proved mathematically. This is provided that the key used is truly random and is used only one time, right? What if I come with a whole system (can be software or hardware or a combination of both) to force these two conditions? Will I have the best & ideal encryption solution?

Say for example the two sides willing to exchange information are getting the keys by connecting to a server that is online all the time. The server will ensure the keys generated are random, and will ensure that a key is never used again. The users at each side will only have to have an internet connection and a mechanism to exchange information. The information will travel via the internet encrypted using the one time pad key generated randomly by the server.

Am I making any sense here? I just started reading about one time pad, and started wondering about this. There are many websites that will tell you that one time pad isn't practical at all, because you can't really come up with a truly random number or something like this.

Addition:

Do these guys offer anything special in key distribution? They say they have perfected implementing OTP over time.

http://www.mils.com/en/technology/unbreakable-encryption/#1

Key distribution is the problem.

In your scenario, you use a server to communicate the one-time pads to the users.  But how is that communication protected?  Not by a one-time pad, or it wouldn't be necessary.  Let's say it's SSL with AES 128.  Then, wham, your cryptosystem is as secure as SSL with AES 128 - pretty secure, but not as secure as a one-time pad.

The mils guys you reference appear to be offering physical devices which you load a one-time keystream onto (and can use it from).  Again, key distribution is a problem.  You could buy two hard drives, load terabytes of keystream on them, and send one to your buddy... how?  Do you trust USPS?  Fedex?  Courier?  Diplomatic pouch?  All of these can be compromised.  The only perfectly encrypted way to send them would be to encrypt them with a one-time pa... crap, it happened again.


IP cameras or webcams and wifi/network security If I have a:

router with stateful packet inspection turned on, plus WPA2 security on the wifi network
an IP camera or webcam connected to this Wifi network

Is there any way to ensure that:

camera itself can't try calling some external service and bypass the SPI firewall
only way to view the video feed is to ssh into a linux server connected to the same wifi?

Preventing the camera from talking to the outside world is trivial, or nigh impossible, depending on how evil the camera is. On one hand, any decent router should be able to block or not-block traffic from any local IP to the outside world; therefore, you may configure your router to:

assign a specific IP address to the camera (based on its MAC address);
block all non-local traffic to and from this IP address.

If the camera is "mostly honest" this will work. However, if the camera is intent on evading your measures, then the situation becomes more complex:

The camera may assume another IP address on its own accord, bypassing the IP filter.
The camera may change its MAC address, so as to avoid any MAC-based filtering on the router.
The camera may try to send data covertly through DNS requests. Indeed, while the router blocks the traffic to the outside world, the camera may still talk to the router, in particular to the DNS server that the router maintains. That DNS server may then relay DNS requests to external entities. Quite a lot of data can be smuggled that way; see this presentation for an introduction on the subject.
And, of course, since the camera is equipped with some WiFi-able circuitry, it may try to talk to other WiFi access points in the vicinity.

So one may say that you will be able to contain the camera traffic to the local network only as long as the camera will try to talk to external servers only for stupid but not deliberately dishonest reasons (e.g. check for firmware update).

As for preventing access to the camera from the outside: again, you have to assume that the camera is not willingly opening a covert channel. When DNS queries carry data, it goes both ways... Let's assume that the camera behaves properly. In that case, you must ensure the following:

The WiFi layer is robust. To make things short, this means WPA2 with a sufficiently random password (see the Wikipedia page on WiFi security as a starter point on the subject). To make sure that the camera is indeed WPA2-able, configure your router to allow only WPA2 and reject WPA and WEP; if the camera still communicates, then it does WPA2 and that's fine. Otherwise, ditch it.

In any case, leave your router in WPA2-only mode.
The rest of the local network is robust. The router will act as first protection layer in this case; external packets will reach it, not other machines. You will configure the router to forward connections to port 22 to a specific local IP address, assigned to your Linux server, and that server runs a SSH daemon on that port. Make sure that security updates are applied regularly on that server; you don't want a remotely exploitable hole in the SSH daemon or the kernel to allow an intruder to hijack it.

A corollary is that some malware on any client machine connected to the local network can open doors and give access to outsiders. You should think twice before allowing friends to "connect to your WiFi" with their own devices, whose cleanliness you cannot ensure.

Another corollary is that everything relies on the absence of remotely exploitable vulnerabilities in the router itself. This might be a bit optimistic...

If you really want to be sure, do the following:

Don't use a WiFi-able or even network-able camera. Use an USB-based camera, connected to a PC running Linux (e.g. your server). That machine will receive the feed. Now the problem becomes one of controlling what that Linux system does, and that's at least doable without too many assumption on the behaviour of closed-source firmware and drivers.
Put a dedicated router/firewall between your WiFi router and the router provided by your ISP. That dedicated router should be, again, a small PC running some Unix-like system. The idea is not that Linux would intrinsically be better than the OS inside a normal, cheap router; indeed, some of them actually run a Linux kernel too. The point is that, with a PC, you can apply updates on a daily basis, whereas firmware updates for routers are rare, when they exist at all.

The whole underlying idea is that you can get decent security, as long as you spend system administration time on it, and security updates can be applied at all.


Why should one not use the same asymmetric key for encryption as they do for signing? In an answer to a question about RSA and PGP, PulpSpy noted this:

  It is possible to generate an RSA key pair using GPG (for both encryption and signing -- you should not use the same key for both).

What is the reasoning behind this?

Perhaps my understanding of public key encryption is flawed, but I thought the operations went something akin to this:

When Bob wants to encrypt a message to Alice, he uses Alice's public key for the encryption.  Alice then uses her private key to decrypt the message.
When Alice wants to digitally sign a message to Bob, she uses her private key to sign it.  Bob then uses Alice's public key to verify the signature.

Why is it important to use different keys for encryption and signing?  Would this not also mean you need to distribute two public keys to everyone with whom you wish to communicate?  I imagine this could easily lead to some amount of confusion and misuse of keys.

It is mostly that the management approaches and timeframes differ for the use of signing and encryption keys.

For non-repudiation, you never want someone else to get control to your signing key since they could impersonate you.  But your workplace may want to escrow your encryption key so that others who need to can get to the information you've encrypted.

You also may want a signing key to be valid for a long time so people around the world can check signatures from the past, but with an encryption key, you often want to roll it over sooner, and be able to revoke old ones without as many hassles.


How can I limit the consequences of a possible future identity theft? I am curious about how I can limit the consequences of an identity theft. I see a lot of discussion and advice about managing passwords securely or blocking malware. But what if it happens?

What if one or more of my digital identities get compromised? Is there more to say than doing a clean install and changing all the passwords that still work? How can I best prepare for this incident? Does someone has experience with mapping the dependencies between his online accounts? Can I valorize an account?Is there a way to compartmentalize my digital life now to limit possible future damage?

The best thing you can do to help minimize damage if one of your online accounts gets hacked is to make sure that none of the information in that account can be used to get into one of your other accounts. Say you use the same username and password for multiple accounts, if one of those accounts is hacked it will compromise all your other accounts. You can minimize this risk by:

using different passwords for every account
use different usernames for every account
use different security questions and answers for every account

Also, these are good practices:

Have all your credit card details and emergency phone numbers recorded so you can get them cancelled and re-issued if an account containing your card details is compromised
Keep a list of all your online accounts, monitor them if one of your accounts is compromised


Why can't persistence XSS be detected by a Web Application Firewall? This OWASP
article mentioned that
"Using data validation, only reflected XSS can be detected and prevented, persistent XSS cannot be detected, DOM-based XSS only to be limited degree if part of the attack is sent in parameters of the request."
Why is it so?

I understand once the malicious script gets stored in the application, now any GET/POST request won't look like malicious but the script will get executed at victim side. However to carry out a persistent XSS, an attacker has to send a malicious looking request to the server which should be sensed by WAF and hence should be stopped to get executed.

If you tightly adjust your WAF to your application so that it can fully distinguish valid from invalid input for specific input fields than you should be able to detect attempts to inject persistent XSS through the use of input fields.

But, usually WAF are not adapted that tightly to the specific application and in this case only employ some heuristics to detect common attacks. Apart from that persistent XSS can have different origins and don't even need to be added to the application by the use of input fields or even using the web interface at all. For example there was a stored XSS vulnerability within the amazon kindle store where the XSS was caused by script inside the metadata of the book description: Amazon.com Stored XSS via Book Metadata.


Sniffing WPA2 PSK traffic with the key but without association Assume a situation where a wireless access point is using WPA2-PSK, and it is configured to allow only a single client association at one time.

Client A connects to the access point with PSK and engages in some higher layer communication with hosts accessible on the AP's network.

Client B also has the PSK, but (presumably?) cannot associate with the access point while client A is associated.

Does the limitation of a allowing only one association to the access point at a time prevent client B from using his knowledge of the PSK to sniff client A's 4-way handshake[1] and decrypt client A's traffic?

By sniffing the 4-way handshake, I mean employing the tactic described in in posts like these:

http://www.howtogeek.com/204335/warning-encrypted-wpa2-wi-fi-networks-are-still-vulnerable-to-snooping/

and

Are WPA2 connections with a shared key secure?

Thanks.

No

Any user who has the psk has the ability to decrypt all traffic encrypted with that AP using WPA2-PSK. The cipher keys are generated from that PSK all the attacker has to know is the psk and what functions the AP and Client use to generate the cipher keys, which he/she already has from previously associating themselves with access point. If the traffic has other layers, ssl  for instance, well then that part of the traffic is "safe". However the Broadcast key (BES) might and should be changed by the AP
whenever a client associates and also when they leave the LAN.

Some of those attacks you posted are for attackers who don't have the PSK, i.e. it  changed or they never used that AP, can capture the 4-way  PSK handshake which usually contains a MAC, or password-key based hash of some used-once string (nonce). The attacker can then brute-force that hash key to obtain the PSK. The key used to create the MAC is the PSK which is the password or some pseudo-derived version of it. "Deauth" Allows an attacker to kick someone off the network to force the handshake to happen again so they can capture it. Basically faking packets that tell the client to disconnect.


Spoofed IPv4 and IPv6 addresses over the internet I have a few questions regarding IPv4 and IPv6 spoofing. Might as well just list them to be concise:

What's the usual routing policy for ISPs' routers in regards to spoofed source addresses? i.e. if an ISP's router manages the 123.123.123.xxx /24 block and a machine sends it a packet claiming to be from 99.99.99.99, does it still route the packet?
Normally packets from within a subnet are translated to an external IP when they pass through a NAT router. Are there any methods that someone might use to forge the internet-side source address when sending a packet through such a router?
Does IPv6 offer any mechanism or changes that mitigate (or perhaps create) such issues?

1) There doesn't appear to be a usual policy. Many ISP's do now drop packets with spoofed addresses, but there are still loads that do not.

2) When NAT'ing, a correctly configured router will have a small list of rules which define the IP address which will be attached, so the usual attack is to send from a location where this doesn't happen.

3) One of the reasons for NAT'ing is to allow you to have multiple IP addresses behind the ones you own on the Internet. With IPv6 this may be far less of an issue, so NAT'ing may end up being used less or not at all. You might think this may change the way protection against spoofed addresses would be implemented but it shouldn't - you will still implement rules which say for a router with a network A on one side, any packet with a source address that matches A coming in a different interface should be dropped as a spoof.


Does malware have to exploit a bug? Lately, I have been trying to dive into the realms of malware and hacking. I have learned that hackers exploit bugs in programs and malware does similarly, but I was wondering whether malware must exploit something or can it run without exploiting anything?

Malware is any software which performs malicious activities. Malware comes in all shapes and sizes, and with all sorts of infection vectors. Exploiting a software vulnerability is one way malware can spread, but there are many other (often more common) techniques they use, for example:

Brute forcing passwords over a network to gain access to a network.
Spreading to other computers on the same network over shares, etc.
Tricking the user into executing a malicious file with a benign name.
Tricking the user into performing an action that executes code (e.g. ldd).

Never overestimate the difficulty of tricking the average person into executing malware. Often forgotten techniques such as using unicode reversal on filenames can show a user a different filename than is really present. For example, a file called history_of_rac4pm.msi seems safe enough, right? It's actually history_of_rac4pm.msi, but due to unicode reversal, the last seven characters are mirrored, giving the impression that an executable installer is a video! Check the HTML!

It doesn't even have to involve making them run an executable file. There are many actions that execute attacker-controlled code that people do not think about. Consider ldd utility in Linux. All it does is list the libraries required by a given executable file. Seems safe enough, as long as you don't execute the file? The reality is that ldd is actually a wrapper that executes the file with an environmental variable set which causes the executable, if using a correctly-behaving libc, to output the libraries it requires to stdout and then exit. It is trivial to create an executable which will not do that, so running such a simple "safe" utility on it will actually end up executing malicious code.


How much information is released when paying with a debit card How much information is released when paying with a debit card?

Is it possible for a vendor to grab your name and address from your debit card and send you things in the mail?

I'm working from the assumption that this is a check card (it may go by various names in different places) that are part of the Visa or other payment processor network and not specifically an ATM card.  There is a difference and I rarely see the ATM cards now.

The check card, like credit cards has in its track 1 your name along with some other information about the account (expiration date, account number and such).

With just this information, there is not enough information to pin you down to an individual and your address.  However, more than companies ask for your zip code when paying by credit card (note, this is not the case when paying using a pin as it already provides the two factor identification and goes through the payment system a different way).

Asking for a zip code plays two roles - first, it can reduce their rates with the payment processing company as it adds another little bit of information about you to help ensure this isn't a fraudulent purchase (you often see this at a gas station where there is no human check on the use of the card).  Secondly, zip + name is often enough information to identify an individual with address lookups.

Going back to the tracks... a debit only card has only track 2.  This contains only the information about the account - the person's name isn't there.

When using a card with track 1 and track 2 (the visa check card), the company does have the name of the person.  However, this alone isn't enough to identify a person and the bank and payment processor under normal situations will not release the billing address of the account (gathering marketing information would not be sufficient to need the information).

Expanding on this, being able to tie a customer to an individual is a very important thing for retail companies - especially for trying to track them across multiple visits and possibly multiple stores too.  Companies are often very interested in this data and willing to spend a fair bit to acquire it (coupons, discounts and the like).  Famously, the target data mining story of 2012 shows how much data can be leaked about an individual's personal situation. (chase the links on that story - there are a couple other good reads related to it, particularly the NYT article how companies learn your secrets)

There are two forms this takes - rewards cards, and company branded credit cards.

The rewards cards are rather simple.  You use it at a check out and you get points or something.  If this has your phone number, email address, or physical address tied to it (some do) it is a rather trivial matter to attach a given purchase to a given person.

With company sponsored credit cards (the type that one typically finds with larger companies - the Macy's card, Sear's card and the like) it is possible for the company to go back either to the application that passed through them to get the card or going to the credit card company directly to get the billing information if necessary.

This also extends to company sponsored rebates, in store credit...

Thus, if you use anything else that is identifying to you as part of a purchase, it is quite possible to trace the information back to an individual (even if one pays with cash otherwise).


Mobile, WebServices and SSL I just started dipping my feet into security and SSL. I looked at various videos to try and understand how the magic happens and I have the general idea now, but most of them deal with it taking the browser and server example. With regards to mobile, I didn't find much data.

I assume the questions are dumb for veterans, but here they are anyway:

If I get an SSL certificate for the Web Server my WebServices are hosted on, do I need to change the code of my mobile app? Apart from using HTTPS instead of HTTP while calling the service.
If the theory is the same as in a browser, how is the data being encrypted? I mean who is doing it? Browsers do it while accessing a secure website. But in case of my App, will the phone be doing it?

Generally speaking, no, you will not have to do anything more that change the protocol (http to https) in order to encrypt your application's traffic.  Most web-client libraries support both protocols transparently.

Some additional things to consider as a mobile application developer:

Do not disable certificate validation routines, or catch and discard errors.  This is unfortunately common in mobile applications and completely destroys the security benefits of using SSL/TLS in the first place by allowing a MitM to capture and decrypt traffic without any warning to the user.
Consider certificate pinning.  This requires some extra work on your part, but enhances security by ensuring that not only is the certificate used to protect the users' traffic is a valid certificate, but it is your certificate, the specific certificate you expect them to use.   This is an extra security measure that may or may not be warranted, depended on what you're protecting, but is worth taking a look at.


What are the security implications of capabilities in Kubernetes pods? We have a Kubernetes deployment with an application that need to be on a VPN. We implement this requirement by running openvpn-client in a sidecar container within the pod with elevated capabilities:

securityContext:
  capabilities:
    add:
      - NET_ADMIN

We'd like to better understand the impact of this, and how exposed we'd be if this container were compromised. We want to be confident that code exec in this container couldn't view or modify packets or network configuration in other pods, or on the host node.

My current hypothesis is that since each pod has an isolated network namespace, giving CAP_NET_ADMIN to a container in the pod just provides the capability within that namespace.

However, I haven't been able to find any documentation that's definitively discusses the impact of using securityContext to assign capabilities to containers. There's a few pieces of documentation - outlined below - that strongly imply that Kubernete / Docker will provide sufficient isolation here, but I'm not 100% certain.

The pods documentation on resource sharing [1] gives a hint here:

  The applications in a Pod all use the same network namespace (same IP and port space), and can thus “find” each other and communicate using localhost. Because of this, applications in a Pod must coordinate their usage of ports. Each Pod has an IP address in a flat shared networking space that has full communication with other physical computers and Pods across the network.

The networking documentation on the network model has this to say:

  Kubernetes IP addresses exist at the Pod scope - containers within a Pod share their network namespaces - including their IP address. This means that containers within a Pod can all reach each other’s ports on localhost. This also means that containers within a Pod must coordinate port usage, but this is no different from processes in a VM. This is called the “IP-per-pod” model.

Finally, I note that pod.spec.hostNetwork is configurable, and defaults to false:

$ kubectl explain pod.spec.hostNetwork
KIND:     Pod
VERSION:  v1

FIELD:    hostNetwork <boolean>

DESCRIPTION:
     Host networking requested for this pod. Use the host's network namespace.
     If this option is set, the ports that will be used must be specified.
     Default to false.

[1] https://kubernetes.io/docs/concepts/workloads/pods/pod/#resource-sharing-and-communication

[2] https://kubernetes.io/docs/concepts/cluster-administration/networking/#the-kubernetes-network-model

For this I think it's quite probably that a rogue process running with that capability would be able to affect the underlying host, if only indirectly.

From this man page we can see that CAP_NET_ADMIN provides quite a few privileges, including interface configuration

       CAP_NET_ADMIN
              Perform various network-related operations:
              * interface configuration;
              * administration of IP firewall, masquerading, and accounting;
              * modify routing tables;
              * bind to any address for transparent proxying;
              * set type-of-service (TOS)
              * clear driver statistics;
              * set promiscuous mode;
              * enabling multicasting;
              * use setsockopt(2) to set the following socket options:
                SO_DEBUG, SO_MARK, SO_PRIORITY (for a priority outside the
                range 0 to 6), SO_RCVBUFFORCE, and SO_SNDBUFFORCE.

These permissions are restricted to the namespace of the process, but allowing an interface to go into promiscuous mode could allow for traffic to be sniffed from other interfaces on the host, depending likely on the CNI configuration.  Also as noted in this white paper there have historically being some breakouts and privescs related to NET_ADMIN.


Double hashing using a relatively new hash and a old, tested one Note: I am relatively new to cryptography in general, so please point out if I make any
misconception here.

I heard that you should always use well known crypto/hash functions, that have already been extensively tested and studied. -and I agree with that- I also read that using scrypt can be risky because it is still in its early years, but it seems to solve problems like attacks using FPGAs or GPUs.

"My" great idea was to use two hashes! One extensively tested like PBKDF2 and scrypt after it! So I would be in theory protected by scrypt and if any bugs/exploits/problems with it are found, I still have the protection of well know protection provided by PBKDF2!

Are there any flaws on this idea?

No, it is not a duplicate of this question:
This question “Double hashing” with 2 different hash functions says that I would not benefit by using two hashes, but it is regarding sha256 and sha512, so I am not certain if this also applies to PBKDF2 and scrypt.

On the other hand, this post here Are different hash algorithms ever used together? says that if used as Composition it would offer "preimage resistance is at least as good as the strongest of the two functions, but for collisions the weakest function defines the overall resistance". As far as I know, collisions would not be the issue here...

You can assume that I just want to hash and store passwords.

You should really stray away from rolling your own crypto implementation. Why not use bcrypt for password storage? It's been tested extensively for that and works quite well.

Some advantages it has are:

Resistance to brute-force
Resistance to rainbow tables
Salt generation
Scalable speeds via setting the rounds of hashing
Built upon blowfish algorithm


Why the private key is not present for the certificate retrieved from the personal information exchange file? certificate data is retrieved from the personal information exchange using the following Crypto API's

hCertStore = PFXImportCertStore( &data, wszPassword, CRYPT_EXPORTABLE );
            if ( !hCertStore )
            {
                hResult = GetLastError();
                __leave;
            } // if

            pUsrCertContext = CertEnumCertificatesInStore(
                hCertStore,
                pUsrCertContext );
            if( !pUsrCertContext )
            {
                hResult = GetLastError( );
                __leave;
            } // if

The result of PFXImportCertStore is certificate + private key.
This certificate + private key is added to the store as

pUsrAuthCertContext = CertCreateCertificateContext(X509_ASN_ENCODING | PKCS_7_ASN_ENCODING,
            pUsrCertContext->pbCertEncoded,
                pUsrCertContext->cbCertEncoded );
        if ( !pUsrAuthCertContext )
        {
            hResult = GetLastError();
            __leave;
        } // if
        //
        // Open the certificate store to add certificates to store
        //
        hUsrCertStore = CertOpenSystemStore(
            NULL,
            //L"TrustedPeople"
            L"MY");
        if ( ! hUsrCertStore )
        {
            hResult =  GetLastError( );
            __leave;
        } // if
if ( ! CertAddCertificateContextToStore(
            hUsrCertStore,
            pUsrAuthCertContext ,
            CERT_STORE_ADD_REPLACE_EXISTING,
            0 ) )
        {
            hResult = GetLastError( );
            __leave;
        } // if

Now this certificate is added to the store but it is not having the private key with it.
What is the flag that i have missed to specify for adding the certificate along with private key?

The link from certificate to private key is not written in the certificate. It is an externally maintained properly. When you called CertCreateCertificateContext(), you just imported the certificate itself, not the link.

The link is a combination of two names (two strings): the name of the CSP, and the name of the key container within that CSP. When you called PFXImportCertStore(), Windows:

Imported the private key into a suitable CSP, with an appropriate container name.
Created a temporary certificate store.
Pushed the certificate into that store.
Added a link from that certificate in that store, to the private key as it was imported in the first step.

Your code pushed the certificate in the permanent store (your "My" store) but did not transport the link. You have to get the CSP and container names from the certificate in the temporary store, and set that information on the context returned by CertCreateCertificateContext(). This is done with CertGetCertificateContextProperty() and CertSetCertificateContextProperty(), using the CERT_KEY_PROV_INFO_PROP_ID  property. The relevant names (CSP and container name) and additional flags travel as a CRYPT_KEY_PROV_INFO structure.


What is this URL that loads each time Google Chrome spawns? What does this URL do that opens each time Google Chrome loads?

  http://redirector.gvt1.com/edgedl/chromewebstore/L2Nocm9tZV9leHRlbnNpb24vYmxvYnMvOWVmQUFXS041NV9ZVXlJVWwxbGc5TUM4dw/7519.422.0.3_pkedcjkdefgpdelpbcmbmeomcjbeemfm.crx

You can see an example of this in app.any.run below:

https://app.any.run/tasks/8ba5fb73-83ea-4439-8522-8eedf4b31024

I'm thinking this might be related to Chrome checking if extensions need updates.

It's the URL used to download the Chrome Cast extension for Google Chrome.


Is Google 2-factor "Remember this Computer" secure against adversaries with root access? This question concerns the type of 2-factor authentication implemented by Google Accounts.

The response to this question describes securing transfer of the secret key via a secure cookie.

But what if the adversary can execute remote code on your machine? If they can copy the cookie off your machine, this still leaves a gaping hole. If they send it to themselves, couldn't they access your account at a later date?

Is it possible to implement a login system that protects against this scenario, while still allowing your user the convenience of "Remember this computer for 30 days"?

Yes it is possible.

If tokens are server generated by creating a cryptographically secure random sequence stored against the account, this token could be refreshed and reissued on a certain interval, invalidating the old one.

The token would only be refreshed on active use so it won't invalidate the old one when the client computer is off. This approach ensures that a copied cookie only has a limited time to be reused, limiting exposure of the attack. In the case that the attacker uses the cookie in time, the original session would be expired and the real user would be logged out (depending on how the interval is set). A message could be displayed that the account is being used elsewhere, alerting the user to the attack.

If the attacker has persistent access though and can grab any new identifiers, she has already won. The above only protects against a one time theft of the token. For example if the user left their screen unlocked and the attacker had physical access and only enough time to steal the cookie value, or if the value was stolen via a reflected XSS attack, which is code execution in the browser, and the attack cannot be repeated easily.

An attacker with root access though may or may not be able to grab a normal user's cookie. Chrome encrypts cookies when saved to disk, allowing only the current user to decrypt them as the key is derived from their password. Therefore an attack on tokens in cookies would be more difficult.


Should a mobile banking app force clients to change their password periodically, e.g. every 3 months? Is there an internet bank that forces users to change their passwords periodically?

In Poland, none of the banks forces a change of the password for Internet banking. Of course, banks educate and suggest changing the password every month, for example, but the user is not forced to do so.

Should my banking app force a password expiry to better protect my user's accounts?

The bottom line is: if you are subject to a standards body, follow their guidance. If not, do a security threat assessment.

For instance, government agencies under the US Department of Commerce must, by law, follow the NIST's Digital Identity Guidelines, SP 800-63. For our discussion, the important document is SP 800-63B, covering authentication and lifecycle management.  However, if you're processing payment card information directly, then the standard to follow is the Payment Card Industry Data Security Standards (PCI DSS).

Highlights from the NIST standards:

8 characters minimum
All printing characters in ASCII and Unicode accepted (Support UTF-8)
Smallest allowed maximum length is 64 characters
No password hints
No previously leaked passwords, dictionary words, repetitive or sequential characters, or context-specific words (such as their username again). (Half a billion previously leaked passwords are available for download at Pwned Passwords, or can be checked without leaking your user' desired passwords with the Pwned Passwords API)
Rate limit failed authentication on a host (unique IP address) AND account level
Do not impose rules that force multiple character types (i.e., requiring lower case, upper case, numbers, and symbols). (As above, you must still accept multiple character types.)
Do not require passwords to be changed arbitrarily, such as periodically
Require passwords to be changed if there is evidence of compromise
Permit users to paste passwords (encourages use of password managers)
Allow the user the option (but not default) to display their passwords in plaintext while entering it
Use an encrypted channel (such as TLS)
Store passwords in a salted and hashed form using a one-way key derivation function. (That is, it's not just SHA-256. At a minimum, something like PBKDF2 or better (Balloon, bcrypt, Argon2, etc.))
Salt will be at least 32 bits, generated using a cryptographically secure PRNG, and will be unique to each password.

Many of these requirements are in direct conflict with the PCI standards. If you handle payment card information directly (that is, any of your customer service representatives handle credit/debit cards over the phone), then the system that they use to handle those payments has a whole different set of requirements.

Highlights of the PCI standard are:

7 characters minimum
Force multiple character types in the same password
Change passwords every 90 days
Can not re-use the last 4 passwords
Users can not set their first password, nor the password immediately after a reset
Passwords must be changed when entering a first or reset password
Accounts locked for at least 30 minutes or until an admin resets the lock if authentication fails 6 times
Sessions expire after 15 minutes of idle time
Use an encrypted channel (such as TLS)

Further, the NIST standards state that you should use 2-factor authentication wherever it's possible, such as the Time-based One Time Password standard (a.k.a., Google Authenticator), printable sheets of single-use tokens, and U2F devices that perform cryptography inside a device like a USB stick.

If you're neither an employee of the US federal government nor handling payment cards directly, and there are no standards bodies that have rules specific to your country, your industry, or practices that your company is using, then you need to do a security threat assessment, including cost/benefit analysis, and design your authentication system around that.

Your conclusions may likely be different from mine. I personally follow the NIST standards as much as it makes sense. I found it very low cost and low risk to use the Pwned Passwords API to let my users know if they used a previously leaked password. However, unlike the NIST standards, I do allow my users to have a previously leaked password, showing a message stating that the password was successfully changed, but that it had been included in X number of data breaches in the past and may be used by hackers in the future. I use the message as an opportunity to raise awareness of the dangers of password reuse, introduce the concept of password managers generating truly random passwords, and I get to show off my Yubikey U2F dongle.  I have the luxury of being face-to-face with most of my users, though.


Proof of data possesion in cloud storage where you cant do calculation to the object stored in the server I was looking into some papers regarding proof of data possession like this or thisin cloud storage where you can ask for the proof of the data stored in the cloud storage by giving some kind of challenge to the server and server will reply back with the result of the challenge by calculating the object stored in the cloud server. But as far as I know some of the public cloud storages like AWS S3 does not allow for other object operations of calculating the object using some formulas other than download, upload, or listing the file (CMIIW). Now the question is the proof of data possesion still possible to do that in the cloud storage? If so, how?

Azure blob storage offers per-block MD5 (which can be requested to be dynamically calculated using an http header in the REST api request).

If you want to, you can write a client which validates the content of cloud-stored blocks by iterating over the blocks in each blob, requesting the MD5 for each range and comparing it to local data.

It's a pretty mature API at this point: here's the overview from 2011.

I'd be surprised if AWS didn't offer something similar.


Why should the *nix system administrator account (root) have a strong password if remote root logins are disabled? It is a commonly accepted best security practice to disable remote root logins on *nix systems including Linux. Thus, in order to log in directly as root, you need to have physical access to a trusted console (in the case of many Linux systems, one listed in /etc/securetty).

As a consequence of the above, to gain root access remotely, you first need to break into an ordinary user's account, then additionally escalate to root access. In this case, the password on the root account only protects against a password-cracking attack on the root account, not any of the other multitude of possible ways for an attacker to escalate privileges.

Given that the system console should be physically secured anyway (even in most homes it's usually kept behind a locked door when unsupervised; many homes have burglar alarm systems installed; and even workstations in corporate locations are almost always either behind locked doors or in alarmed areas; servers even more so), and that if an attacker has physical access already file system permissions present barely an obstacle, why would the root account need a strong password? Couldn't we use a simple password for the root account more to protect against simple mistakes or casual attackers, than determined attackers?

If you follow the principle of least privilege and layered security you have to make sure that on each level of a system you implement strong security measures. At each level means you do not make any assumptions about how easy/difficult it might be for an attacker to get to that level in the first place.

When you write

  As a consequence of the above, to gain root access remotely, you first
  need to break into an ordinary user's account, then additionally
  escalate to root access. In this case, the password on the root
  account only protects against a password-cracking attack on the root
  account, not any of the other multitude of possible ways for an
  attacker to escalate privileges.

you are perfectly right, but why do you say

  only protects against a password-cracking attack

? A strong password eliminates this very attack vector even if there might remain other attack vectors to escalate privileges. The other attack vectors need of course to be taken care of as well.


Why do hackers scan for open ports? So, whenever you hear of the mean little hackers who hack websites you hear of "port scanning". I understand what it is (looking for all open ports / services on a remote machine), however that begs the question:
Why would an attacker want to know what ports are open?
The only reason I see for this is looking for services that may or may not have the default username and password OR a vulnerability or something.
But seeing as the odds for this are quite low, why do hackers perform port scans? Is it purely for the reason above?

To run an exploit, an attacker needs a vulnerability.
To find a vulnerability, the attacker needs to fingerprint all services which run on the machine (find out which protocol they use, which programs implement them and preferably the versions of those programs).
To fingerprint a service, the attacker needs to know that there is one running on a publicly accessible port.
To find out which publicly accessible ports run services, the attacker needs to run a port scan.

As you see, a port scan is the first reconnaissance step an attacker performs before attacking a system.


Is asymmetric encryption ever recommended for long-term storage? Is asymmetric encryption ever recommended for long-term storage of data, is it advisable for example to store data in a database such that:

1) A user enters data on a website, it is encrypted using a public key and stored. Neither the webserver nor the database server stores the private key.

2) The data is downloaded by a worker who was the permission to access it.

3) The worker uses the private key stored on his/her local computer to decrypt the data.

Assuming that the worker's computer is free of malware, the seeming advantage would be that if the database server were to be compromised the data would not be accessible.

What would be the problems with doing this?

Yes, this is a good scheme for medium term storage, as long as it's implemented properly.

A few things to keep in mind:

Common asymmetric algorithms use semiprime factoring as their basis. As such, you can only encrypt data as long as the key, e.g. 4096 bits. This isn't very practical, so normally you would encrypt a symmetric key with your private (or, in this case, public) key and encrypt the data using a symmetric algorithm. So you'd use AES to encrypt the data, and RSA to encrypt the AES key.
Asymmetric key lengths have had to grow at a much faster rate than symmetric keys. It's generally considered that RSA 1024-bit is secure for now, but 2048-bit is more appropriate for anything you're going to need to remain secure for more than a couple of years. If you're looking at storing data for longer than 5 years or so, you're going to need 4096-bit or 8192-bit keys. That's not exactly performance-friendly, but it's a requirement. In contrast, with symmetric encryption, it's thought that a 256-bit key couldn't ever be cracked with conventional methods, even with every ounce of energy on the planet, before the heat death of the universe.
Quantum computers, whilst a long way off, might allow for semiprimes to be factored into their constituent primes in polynomial time, which would break such asymmetric schemes. If you're planning on storing the data for more than 20 years, keep this in consideration.

An alternative would be to have the client encrypt the data with AES-256, then upload it. They can keep their symmetric key on their machine, or derive it from a password using PBKDF2 or bcrypt.


Web Authentication Offline I've been working on a project and one of the requirements that came up is offline authentication. On the web what we would like to do is ask the user to login using their device authentication for example touch ID and face ID on iOS devices. I know webauthn exists, but the current spec requires the server to respond with a challenge. Can this challenge be cached with say a service worker? Will the spec still work like this? Can I use a service worker to cache the challenge then feed it back to the user when offline. If not are there any other options for offline authentication?

Caching of response - not good:
It depends on your authentication implementation. If the client authentication requests with the same password are different each time (because you use nonce, or because you encrypt password), then it is not easy to determine if two requests mean the same password. Thus it is not easy to decide if the cached response should be returned for particular request or not.
The cached response may contains some data that depend on time and that are expired. Thus you will have to implement some logic to deal with it.
Hashing of credentials - better:
I'd suggest other approach.
After successful online authentication you can hash the credentials using some key derivation function like Argon2 and store them locally. In case somebody breaks into your app and obtains the hash, it will not help to retrieve the password.
In the offline mode during authentication you can calculate the hash of credentials using the same hashing parameters (same salt, number of iterations, memory factor) and compare it to the cached one. If they match, credentials are correct.


Encapsulating DNSSec into Dot or DoH I read a few articles on how DNSSec works (here and here).

The DNSSec request are not encrypted, and I wanted to know if it's possible to encapsulate it into a DoH or a DoT request?

DNSSec requests are normal DNS requests with the DO (DNSSec OK) flag set. DNSSec responses are also normal DNS responses which also include records (RRSIG) related to DNSSec.

DoH and DoT both simply send the original binary DNS request and response inside a TLS connection (DoT) or as body or query string inside a HTTPS connection (DoH). DoH can additionally send the DNS messages as JSON  which essentially can do the same as the binary representation, only with more buzzwords triggered, more bandwidth needed and more overhead in processing.

There are no restrictions by DoT or DoH what kind of DNS messages can be sent. This means that DNSSec can also be done with DoT and DoH.


How can mini-computers (like Raspberry Pi) be applied to IT security? It's no secret that thousands of $35 Raspberry Pi (Model B) computers have just shipped to people around the world. With these, and other similar types of computers becoming cheaper and more available, what are the security implications?

So as to not leave this question too open-ended, I'll specify: I'd like to know what practical applications such mini-computers have in IT security, or what role they could play in cyber-defense, network analysis, etc.

And on the flip-side, what risks might they introduce to a local network environment that should be considered? Remember that they can hide in small places, operate without noise, and are powered by something as common as a cell phone charger.

Note that I'm not referring to portable USB utilities that need a host system on which to run or boot into, but I mean actual stand-alone hardware devices.

There was a presentation at BlackHat yesterday where they used a Arduino to open hotel rooms that are using a certain kind of lock: http://www.h-online.com/security/news/item/Arduino-used-as-master-key-for-hotel-rooms-1652281.html

As devices get smaller and more powerful, that are getting better suited to be used as pentesting drop boxes. Examples are:
MiniPwner, http://www.minipwner.com/index.php/what-is-the-minipwner or
PwnPlug, http://pwnieexpress.com/products/elite-plug
PwnPi, A pen test drop box distro for the raspberry pi, http://sourceforge.net/projects/pwnpi/


Work-at-home surveillance software: How do they install on Android devices? Surveillance software allows employers to monitor all activity on PC and Android devices including screen, voice and chat. All of them, like FlexiSPY and Neatspy (compared here), endlessly list all the things they can do, but never mention how they are installed.
How can an employer even access someone's PC or Android phone remotely and install such software, if installation even occurs? What interaction mechanism actually engages the installation: does it start by adding one another as phone contacts through a social media app, or starting a video chat, for example? Or is surveillance only possible by having the worker connect to the company network at all times (which of course doesn't happen with, and wouldn't cover the question about, Android devices)?

Background
This systems don't install themselves, nor do they install themselves in surreptitious ways.  The examples you gave would basically boil down to the applications installing themselves illegally via hacking.  That is incredibly difficult in practice, would put a legitimate software company out of business, and a workplace certainly wouldn't use illegal methods to get such software installed.
So how do they get it installed?
Most importantly, you will sign paperwork as part of your terms of employment stating that you agree to install the necessary security software/business software/whatever that is needed for you to do your job, with the company deciding what is necessary (of course).  Then one of two things will happen:

They will install whatever they need on your work machine before sending it to you
They will ask you to install a remote management system, which will then install/remove any additional software as they see fit.

Note that regardless of how it gets there, once the remote management system is installed the computer is, in essence, no longer yours.  Such things should really only be installed on work computers.  For any number of reasons, you really don't want to be using personal devices for work, whether phones, desktop computers, or laptops.
Hopefully your company isn't asking you to install this on your personal devices.  That would be a deal breaker for me, but depending on your industry and country, you may not have much of a choice.  In that case you can do yourself a favor and buy a cheap device to use exclusively for work (if possible).
Still, unless you have specifically installed something on a personal device, you don't have to worry about such "spy" software being on it.  There really isn't anyway that such software can automatically install itself on your personal devices, even if they share a network with work devices that have such software installed.


If a CVE lists two particular affected versions, and I use a version between those two, what's the next action for determining vulnerability? CVE-2015-5185 lists two particular versions, "1.3.4 and 1.3.18" as being vulnerable. If I use 1.3.11, what's the next action for determining vulnerability?

I think this question is partially about convention. Would a CVE author specify two particular versions like this to indicate an "if and only if" relationship, or a "if, and possibly others" relationship?

The researcher may only have been able to test those two versions, there isn't much point in speculating. Depending on which distro you use the patch may have been back ported without a change in version numbers.

The next step is to make sure you use the latest version supported by your distro and check their change logs for the package to see if it has been patched. If you want to verify the patch as effective you would have to attempt exploitation. As there is no readily public exploit you can use to test you would have to invest time to try to develop a poc or reverse engineer the patch.


Old OS memory space protection - was it really that bad? In his book Security Engineering, Anderson really focuses on how in the 90s and early 2000s programs would need to access memory that wasn't their own, and programmers programmed with the assumption the program would be run with administrative privileges:

  The latest Microsoft system, Vista, is trying to move away from
  running all code with administrator privilege, and these three modern
  techniques are each, independently, trying to achieve the same thing —
  to get us back where we'd be if all applications had to run with user
  privileges rather than as the administrator. That is more or less
  where computing was in the 1970s, when people ran their code as
  unprivileged processes on time-shared minicomputers and mainframes.
  Only time will tell whether we can recapture the lost Eden of order
  and control ...
  , and to escape the messy reality of today... but certainly the attempt is worth making.

In particular this quote

  PCs carry an unfortunate legacy, in that the old single-user operating
   systems such as DOS and Win95/98 let any process modify any data; as a result many applications won’t run unless they
  are run with administrator privileges and thus given access to the
  whole machine

Does this mean that ideas such as these, where you can assign any address to a pointer and have access to the memory would work on Windows 95/98? Why would they design it this way as what would be the benefit of reading some other programs memory (or writing to it!)?

int * firefoxmemory = (char*) 0x11111111 //this is just an example of address.
*firefoxmemory = 200;//screw firefox

Memory isolation

Your example wouldn't work on Windows 95, but it did work on DOS and Windows up to 3.11 (not Windows NT).

The PC architecture, and the Microsoft series of operating systems, started with the Intel 8086 processor and an operating system (DOS) designed to run a single program at a time. You would run a program, and when you were finished with it, you'd exit it, so the overwriting data of another process wasn't really a concern. (You could have programs that remained in memory after exiting; they were essentially part of the operating system.)

The Intel 80386 processor changed the deal by being the first of its lineage to have a memory management unit (MMU). An MMU is a hardware component that provides virtual memory by translating virtual addresses (pointers in a program) to physical addresses (actual locations in RAM¹). Windows 95 was the first in its lineage to take advantage of it: each Windows 95 application ran with its own MMU configuration, so that *firefoxmemory would either point into the program's own address space (in which case whatever bad thing it did could only affect that program) or not point anywhere at all (in which case the program — and not the whole system — would crash).

Windows 3.0–3.11 took advantage of some of the 386's novelties, but they ran all applications in the same address space. This was due to several factors:

a requirement to keep old Windows 1.x/2.x applications running (they were designed to run on single-address-space hardware, and many took advantage of that to poke into OS internals to achieve things that weren't possible through documented interfaces);
lack of development time to redesign the whole operating system based on a completely different architecture;
a requirement to run on computers that had little RAM: keeping applications isolated does cost more memory on a scale of 2 MB or 4 MB (because data has to be copied between programs, and because the operating system has to keep track of all program interactions to allow applications to communicate and to regulate the communication).

It wasn't so much that the operating system was explicitly designed to allow programs to access each other's memory, but that there was no way to prevent it. When ways to prevent it became affordable, it took a few OS versions to take advantage of them.

For example, let's consider a feature such as inter-program copy-paste (clipboard). If you don't have memory isolation, this can be implemented by having the source program keep a copy of the data in its own memory; when the data is pasted in another program, that other program copies the data directly from the source program. The only thing the operating system needs to track is who currently owns the clipboard. If applications' memory is isolated, the operating system needs to arrange for the data copying, and possibly to store a copy of the data independently of the source application. This requires more development work to write this code, and more resources to store this code in memory and run it.

I've simplified a number of things here; for more about how an operating system uses an MMU to isolate applications, you can read How the kernel can prevent a malicious program to operate?, How can two identical virtual addresses point to different physical addresses?, Is it possible to support multiple processes without support for Virtual memory? (they're Unix-oriented but the principles apply to Windows or any OS you're likely to encounter on a PC).

Privilege isolation

In this passage, Anderson isn't actually discussion memory isolation, but privilege isolation, where a running program is prevented from affecting certain parts of the system. Memory isolation is necessary, but not sufficient. The operating system must also control the ways processes interact, control what files they open, etc. Even with each application running in its own memory space, applications can interact. Memory isolation merely forces applications to use operating system services (via system calls to a kernel which can access all memory) to interact.

The Windows 1.x/3.x/9x/ME series of operating system was designed as a single-user operating system and did not isolate applications. Memory isolation was added in Windows 95, but only to improve stability, not to implement security restrictions. These operating systems have no security restrictions: if you ran a program on your machine, it is allowed to do everything. (This is of course helpful to virus writers.) The memory space is isolated, but not the file space.

The Windows NT/2000/XP/… series of operating systems, like operating systems in the Unix family, was designed as a multi-user operating system, which introduces a basic security goal: what a user does should not adversely affect what other users can do. So the operating system has to enforce, for example, that programs executed by Alice cannot interact with programs executed by Bob, cannot modify Bob's files, etc. Programs and data that are part of the operating system concern every user and so should be protected from all users. (Of course, some interactions are allowed by explicit permission, e.g. a network server does process requests that it receives from the network, Bob can change a file's permissions to be writable by others, some users are granted administrative privileges and so can modify the operating system, etc.)

A great many applications were written to target Windows 9x, which had no security restrictions. So they took liberties such as writing to the operating system directory (under Windows 95, copying the file to the Windows directory was the normal way to install a shared library). Much of what these applications do was considered somewhat messy even by the standards of that time, but it worked so people did it. Versions of Windows from the NT series (which includes all versions since XP) necessarily broke some of these applications, though Microsoft did add a number of workarounds (such as pretending that writing a file to a shared directory succeeded, but actually writing it to a user-specific directory).

Windows XP enforced user isolation, but most installations wouldn't take advantage of it: many installations just had the user be an administrator, so all the programs they ran had the privileges to do pretty much anything. There were two main reasons for that:

It allows badly-behaved legacy applications to run. While most such applications are only used by a small proportion of users, many users do run such applications and it takes a long time and a huge effort to renew them all.
Introducing privileges means that sometimes the user will be told that something can't be done because of a lack of privileges. Witness the complaints about Vista, that it would keep showing those privilege escalation prompts.

Application isolation

If you're young enough to have discovered computers through portable devices, you may be used to a model of isolation centered on applications, rather than users. In the Unix and Windows model, Alice's data is protected from Bob. Applications are neutral in the security model: they just execute under the identity of the logged-in user. This means that the application code has to be trusted not to misbehave.

Windows has traditionally coped with misbehaving applications by trying to detect and contain them through antivirus software. That doesn't work too well. Unix systems, especially Linux, tend to cope by distributing more software through traceable channels from which malware is eliminated.

Operating systems designed for mobile devices, in particular iOS and Android, don't trust application developers, so applications are isolated; for example each application has its own file space. This has a security benefit, but also a significant cost in that it reduces what applications can do. Applications require privileges to modify operating system behavior (e.g. to create shortcuts and more generally automation), you can't easily manipulate the same file in different applications, you can't easily allow multiple applications to display information at the same time, etc. Or, to take a more dramatic example, you can't write a debugger with restricted privileges, because the whole point of a debugger is to snoop on and perturb the execution of the application that's being debugged. This cost is why the mobile application isolation model can't just be grafted onto a PC environment.


Intrusions attempt monitoring (on MacOS X) I know utilities such as last exist - but not sure if it's applicable for my needs -
I'd like a system to notify me of any login attempts on any of my macs (home, work or remote). Attempts from a physically at the machine, or via ssh, Telnet, FTP, scp, sftp, vnc etc, etc.

I also know of a few commercial products but there seems to be no reviews for then so I'm not that trusting of them!

Can anyone recommend anything?

I have posted this in security as I feel it's a valid intrusion detection mechanism

I'd advise you to start searching for "log analysis" on this forum.
(Then refine your initial question to get better answers.)

Most of the discussions on this topic and on any different Unix will build
on top of Mac OS X.

You could start by this one which is focusing a larger target than your one: How do you handle log analysis?

I advise you to install logwatch, which you can do with either MacPorts, or the traditionnal way: tar, configure, make….

To be more on the active side, I advise you to install fail2ban,
which you can also do the same 2 ways and Brew.


How Forgot Password Works? For my website I need to add "forgot password" functionality. As I searched on the internet there are too much vulnerabilities you may encounter in case of wrong implementing this functionality. Like referer leakage, account enumeration etc.

How I Thought To Implement This
Step One

In login page there will be a link to "Forgot Password" page
In "Forgot Password" page there will be one input field for both email and username. User may input email or username.
Whether account exists or not, a message box will appear and says "We sent email if account exists." (I'm trying to be not explicit with my messages to avoid account enumeration)

Step Two

Generate a random uuid and expiration date. That will be used as token.
Store the hashed version of token in User model
Send email that contains not hashed version of uuid.
Compare if not hashed version of uuid matches user's hashed id(hashed id stored in database). And token not expired move to third step.

Step Three

Update the password (I implemented update password functionality before. So I'm not gonna be detailed about this. If you have any tips I'd love to see them.)
Notify User that password has changed. And remove hashed data from database.
Redirect user to login page.

If I'm wrong at some point or have logical errors please correct me. I'm open to all advice.

This is a pretty standard construction, and I see no significant issues with the design. For a low-to-moderate-sensitivity site, this should be fine, and the main thing I'd look for in a higher-security site would be multi-factor authentication being involved in the process.
A few considerations you might have missed:

IMPORTANT: GUIDs/UUIDs are not a great choice for security tokens. They are guaranteed (to extremely high probability) to be unique, but not necessarily to be unpredictable (which is the far more important consideration)! Type 4 UUIDs are generated using a secure PRNG, and those are the most likely type for any modern UUID library, but most libraries do not guarantee that this type will be generated. Even if your library does offer such a guarantee, it's still not the intended use of the tool.

Use the output of a CSPRNG directly, either hex- or base64-encoded (if the latter, make sure it's either a URL-friendly base64 variant or that the token is URL-encoded). 16 bytes (128 bits of entropy, actually slightly more than a type 4 UUID) should be plenty.

Depending on how the third step (entering and submitting the new password) works, and how you do session management in general, there might be a window for a CSRF attack to control the password the server sees. Make sure the process is not vulnerable to CSRF.
Since you're using access to the email address as equivalent to control over the password, you need to make sure that a user's email address can't be changed without the user being fully authenticated (including MFA if relevant).

Similarly, when a email change occurs, you should probably notify the old email address as well as verifying the new one, same as you notify the user when they reset (or, ideally, change) their password.

You probably want to limit how often a user can request a password reset email (perhaps only once every two hours or so). This is primarily to avoid a malicious actor spamming your legitimate users with reset emails they didn't request.
Relatedly to the previous point, you don't want to allow an attacker to constantly replace the user's password reset token in the database, or else the user will never be able to complete the process. You could avoid that specific risk by having multiple valid tokens for a user, but that adds complexity and has its own risks. Better to just not allow requesting a new token for some reasonable window.
You might consider adding a CAPTCHA or similar to the reset form, as further mitigation against the risk of a bad actor submitting an enormous number of requests. Possibly only require the CAPTCHA if the page is getting unusually high traffic.
You don't specify why you're hashing the token in the DB. It's a good idea, both to avoid leaking the tokens if somebody gets read access to the DB (before a token expires), and to avoid a timing attack on the tokens. Make sure to consider both risks if you change the scheme.
The best validity period for the tokens will depend on things like how often they can be requested and how sensitive the account is, but as a general rule I'd keep it under a day. It might occasionally be necessary for the period to be more than a few hours, though; I've seen (temporary) situations where email systems are overloaded, buggy, or poorly integrating with external components such as filters, and emails end up taking hours to arrive. On the other hand, if you consider the highest security more important, it's fine to say that users of such malfunctioning email can cope without password reset functionality for until their email is fixed.
When the user enters their new password (via reset, or change, or creating their first one), make sure that you apply all the usual password quality checks (not too short, not a common password, no part of the user's or site's name, etc.). I recommend checking the submitted password against a large list of passwords known to have been breached, such as from HaveIBeenPwned's "pwned passwords" list.

Multi-Factor Authentication (MFA)
The most common place I'd see a serious mistake in a system like what you've described is when MFA (also known as 2FA) is in use. Access to an email account is not really a second factor - it's just a (hopefully different) password - and the ability to demonstrate access to an email account should NOT allow bypassing MFA. Specifically, I recommend the following (for all accounts where MFA is enabled):

Do not allow logging in without one of the configured MFA approaches used successfully. In other words, if the user is logged in directly after resetting their password - which is a reasonable approach - don't allow the password reset to complete without supplying the other factor(s).
Although not strictly required if the process doesn't directly log the user in, I recommend requiring the MFA verification when resetting the password.
Don't allow removing MFA without proving the user has access to it.
Don't allow an emailed token as an alternative to MFA.


Detecting a Crypted executable that is supposed to bypass antivirus I've seen many Crypters being advertised to bypass antivirus and they work.

The malware crypted by the Crypter evades antivirus detection.

How would you programtically or using a tool reliably detect a Crypted executable?

I'm thinking of strings command and other such tools.

With proper encryption, it could be impossible to know that an encrypted file was originally an executable.  Of course, if it gets redistributed in that exact same binary state, antivirus makers could identify a signature to recognize it.

Such a distribution system would require a process to be already present on the client computer to decrypt and run the virus.  If that were the case, it would be feasible to cheat the encryption to use a variable key in a way that the client process knows how to handle, making its detection almost impossible.

Then again, the process that would handle this task would be the real source of the trouble and could potentially be identified by the antivirus.


Mutual Authentication using certifcates How are digital certificates used to enable mutual authentication between two users? Suppose, at a bank, the employees are required to authenticate each other before transmitting sensitive data. How can a digital certificate be helpful in this scenario?

When a party authenticates itself using certificates it essentially proves that it can make use of the private key associated with the public key in the certificate - since it assumed that the private key is secret and only known to the owner of certificate.

To prove access to the private key the authenticating party signs a challenge which is at least partly determined by the peer (to deter replay attacks). The peer then can verify the signature using the public key inside the public certificate.

Since a successful signature only proves access to the private key for a specific certificate the peer also has to verify that the certificate matches its expectations, i.e. typically that it is signed by a trusted certificate authority (CA), has a specific subject, is not expired or revoked and has the correct key usage extensions.

Within TLS typically only authentication of the server is done, the signature is part of the ServerKeyExchange message and is done over various data which also include the client-determined ClientHello.random. The client typically requires that the correct hostname matches the server certificates Subject Alternative Names (SAN) or (older and obsolete) matches the certificate subjects CN.

With mutual authentication the server also requests the client to authenticate itself. This is done using the CertificateRequest message. This message can also a list of CA the server is willing to accept as issuer of the client certificate so that the client application can choose the expected certificate. If a client received this CertificateRequest and has a matching client certificate it will send a Certificate message with this certificate. Additionally it will  send a CertificateVerify message which includes a signature created with the client certificates private key and covering all handshake messages send so far - which include the server-determined ServerHello.random.

How exactly the client certificate is validated and associated with a specific client is not defined but it is common that any certificate issued by a specific CA will be accepted and that the clients name or email will be extracted from the certificate subjects CN.


What buses carrying sensitive information on a running computer are vulnerable to sniffing? Has there been any research on what buses in a computer can be analyzed while they are live, without rebooting the system to insert a proxy device? For example, I imagine I2C would be very easy to sniff because the wires are exposed, and because the data transfer rate is very low, but as far as I know, I2C transmits no sensitive information. On the other end of the extreme, I imagine PCIe and RAM would be almost impossible to sniff, even though the pins are all exposed, simply because of the high data rate (thankfully, I hope, because they both contain highly confidential information). The question is similar to this one here, but not specific to EM emissions.
My question is, what buses that carry sensitive data on a live system can be sniffed without interrupting the operation of the running system, if any? Sensitive information meaning anything that can be used to uncover the internal state of the system, such as cached inodes, encryption keys, ASLR layouts, process list, open sockets, etc. Pretty much anything in memory.

Well, when talking about the internals of a computer, Any access point you can access physically without pulling hardware out, so basically anything you can attach a probe-lead to without causing a short.
So what can what is not accessible.

CPU, this is often only available for sniffing from when using specialized equipment in between the CPU and the main-Bord.
Memory, while individual memory are more or less accessible, often this is hard to actually do due to the small size of the legs and require a microscope to properly connect without short
PCI, Often only the external and diagnostics ports are available, rest has the same issues as Memory and CPU.

All other data carrying cables and diagnostic ports are available. its just a matter of connecting the leads and stripping the cables without causing shorts and without disrupting the running system. And all of these attacks require physical access to the machine and leave evidence on the machine after you're done.
Higher data rates require better recording equipment so, just because of the high rate does not mean you're safe. But the price of such equipment is such that when these become an issue you should also worry about man putting guns on your face to get the information you have. (e.a. big government threats)


Is an ADFS "proxy" required in a production, Internet-facing ADFS deployment? Is it acceptable to simply deploy ADFS, and expose 80/443 to the Internet, opposed to deploying redundant Front End and Back End servers?

I understand that I'm missing out on Token Replay Attack prevention, but I also notice that different endpoints are available on the internal vs external proxy.... namely kerberos and "trusttcp" are disabled externally.  Should I disable these when exposing the internal ADFS server to the Internet?

It's certainly not required, but it does change the attack surface significantly. It switches from having a domain-joined server publicly accessible to having a server a DMZ hop away from a domain-joined server.

The proxy explicitly disables Windows Integrated auth because the assumption is that 1) the client machine won't have access to AD to request a ticket, and 2) the proxy is in a DMZ that won't have access to AD to validate the ticket. If WIA was attempted it would fallback to something far less secure.

It is definitely wise to disable those endpoints since they probably wont work from the internet.


Can VPN hardware provide adequate isolation on a home network? If you were to configure a Work PC at home to exclusively connect to your work network via a small VPN box, would this adequately isolate it from your home network and related threats?

What alternatives would you recommend?

Work PC <=cable=> VPN Hardware <=cable/wifi=> Home Router <=> Work VPN Endpoint

A properly configured VPN hardware box can provide in this setup appropriate protection for the Work PC from attacks originating in the local LAN. It will also protect against attacks against the VPN tunnel from the internet. It will also protect your LAN against attacks starting from the Work PC.

It will not protect against attacks which start after the VPN endpoint, i.e. from inside the work or from the internet which is able to reach the VPN endpoint. Specifically the VPN alone will not magically protect against malicious websites you visit on the Work PC or malicious mails. These threats are commonly handled by some security product located between the VPN endpoint and the internet but these products will not provide perfect protection.

Your VPN setup will also not protect against physical access of the Work PC by others.


Cannot understand supposed ProtonMail vulnerability from wired.com article Currently I'm reading an article about ProtonMail here and I don't understand it.

  Now let’s address ProtonMail’s weaknesses. One of the big issues is
  that it isn’t easy to know whether a message sent to another
  ProtonMail user is being encrypted to the recipient’s correct public
  key, which is stored on ProtonMail’s keyserver. For example, if Alice
  sends Bob a message encrypted to his public key, it’s harder for
  anyone else to read the message. But since ProtonMail distributes the
  encryption keys to users, it has the technical ability to give Alice
  its own keys in addition to Bob’s, thus encrypting the messages in a
  way that would allow it to eavesdrop.

What is meant under 'its own keys'? You encrypt messages using public keys only and they are, well, public. So where is the problem in fact that someone knows someone elses public key?

UPDATE
After comments and answer I realized that confusion goes away if you reword the highlighted sentence like this:

  But since ProtonMail distributes the encryption keys to users, it has the technical ability to give Alice freshly generated malicious keys instead of Bob’s, thus encrypting the messages in a way that would allow it to decrypt them on the server (using private key from freshly generated keys) even without knowing Bob's private key.

This is mostly a guess on what they mean:

Well, Public key schemes need the trusted third party. In this case ProtonMail is assumed to be the third party, who - the first time Alice and Bob communicate - give Alice a public key owned by themselves. When Alice then send mails to Bob ProtonMail decrypts the mail and encrypts it with Bob's key, but keeps the unencrypted mail for themselves.
So as the article states:

  ProtonMail does allow you to export your public key and send it to another person, but you can’t easily confirm whether your ProtonMail messages are being sent to the same key. It would take serious tech chops to verify the key.

You could send the public key to the recipient beforehand, but they then must trust that it is you sending it.


can I trust Boxcryptor closed source software? Encryption of files for cloud hoster Boxcryptor https://www.boxcryptor.com is not Open Source. Can I trust this? Is it secure? No government backdoor?

Because there is no alternative for OS X and iOS.

That's a judgment call you'll have to make for yourself, but their technical overview has what I consider a huge red flag:

  Which data is stored on the Boxcryptor Key Server

    Private RSA key (encrypted with the user's password)

The fact that your private key is stored on their server, even if it's encrypted with your password, greatly weakens security.  It means that, at best, the security is as strong as your password, rather than being as strong as the underlying encryption.


How secure is an encrypted text? There are apps like CTI Text Encryption that encrypt texts with one or multiple passwords and render them into meaningless words and digits.

  e.x

  Original Text (before encryption):

  The quick brown fox jump over the lazy dog.

  Encrypted Text (after encryption):
  ga8Ba3jH55sI4eFT0nRBesHoLGLbriXeWomE7vpxbFszJFnSXJRYy1MJoKy+y+krLmdmYxGBhRg3oRDA9OjqemJSZdryFI2b5BjseUnhsC8=

  Decryption Result of the Encrypted Text:

  The quick brown fox jump over the lazy dog.

So I have few questions

How secure are these encrypted texts?
Are they reversible and can one find the original text by using techniques used for hashes, encrypted files, truecrypt etc?
If possible then how long approx does it take to find the original text encrypted with 4 passwords and what hardware possibly needed?

A peek at the source code, especially the AES256BitExpress.cs file, reveals the following excerpt:

    public static byte[] AES_Encrypt(byte[] bytesToBeEncrypted, byte[] passwordBytes)
    {
        byte[] encryptedBytes = null;
        byte[] saltBytes = passwordBytes;

        using (MemoryStream ms = new MemoryStream())
        {
            using (RijndaelManaged AES = new RijndaelManaged())
            {
                AES.KeySize = 256;
                AES.BlockSize = 128;

                var key = new Rfc2898DeriveBytes(passwordBytes, saltBytes, 1000);
                AES.Key = key.GetBytes(AES.KeySize / 8);
                AES.IV = key.GetBytes(AES.BlockSize / 8);

It uses AES (with a 256-bit key), which is good. It derives the key and IV from the password using PBKDF2 (that's what Rfc2898DeriveBytes implements), which is kinda OK (though 1000 iterations are a bit too low for comfort with modern machines). It uses the password itself as salt for PBKDF2, which can be described only as "atrociously weak". This totally ignores the point of the salt and allows parallel attacks, including time-wise parallelism (also known as "precomputed tables").

This is a nice illustration of how sane, secure algorithms can be assembled into something which offers only very little security. I can only advise against using that software for any security-related purpose.