How do I verify that in-app social login dialogs are secure? If I have a mobile app that supports some kind of social login feature, say, to login to the app from my Facebook account, and if the app opens the Facebook login page inside the app in a mobile, is there any way to verify that I am indeed connected to the Facebook site?

This is from an app that lets me sync Instagram profile photo with my phone contacts. I trust this app, and once I log in, I have to accept the app permissions.

The problem is that the links do not open in a standard browser, and I cannot check the URL. If someone were to create an app, add such login button, and opened a fake site to collect my password, it looks quite possible to me because I cannot see any HTTPS EV certificate information or let alone the URL of the login page.

as a consumer, how can I make sure that such embedded login pages are legit?

You can't, at least not until mobile OS developers stop prioritizing UX over security.

For now the best you can do is to make sure the app you're using is from a legitimate and trusted developer, and the credentials it's asking for are related to the function of the app (a photo app asking for Instagram credentials to post on it seems alright, but the same photo app asking for Spotify credentials would be more suspicious). Also you should consider that particular account compromised by the app's developer so you should't use that account for information you don't want them to see. On some sites that don't revoke OAuth tokens on password changes, a solution to prevent future unauthorized (outside of the legitimate OAuth flow) access would be to change your password. As the OAuth token would still be valid, the legitimate functionality of the app should still work but sneaky attempts to login using the harvested password would no longer be successful. Of course, this isn't bulletproof as a truly malicious app would probably have a bot running on their servers that changes your account's email and password the second you enter it, preventing you from ever accessing your account.

In the long run, the solution would be to put pressure on mobile OS developers to either stop the nonsense described in my first link or at least provide a secure, OS-controlled WebView alternative that apps can use to request credentials. That WebView should prove to the user it's indeed OS-controlled (by doing something that normal apps can't, like intercepting a home button press) and clearly display the URL that's been requested by the app so it can't attempt to display a phishing site.


Is this approach of securing cookie secure? I could not find writeups about secure cookies so I have done some thinking. (I already have a "secure" password database with bcrypt and salt)

Steps:

User logs in
Save user IP + randomstring in memcache example (key = IP value + randomstring + username)
Create a new string username + ip
Cipher this string with blowfish , the cipher key will be the randomstring stored in the memcache
The user receives a ciphered cookie
If the user comes again to my site and has a cookie -> I check if his IP is in the memcache, if yes take the value which is randomstring & username
Try to decipher the cookie value with the randomstring
Check if the request-IP and IP stored in the cookie are equal, and usernames are equal. (username from cookie vs username from memcache)
If success, log in

What do you think?

Now there are two thing that I worry about:

Can IP requests be faked ?
Is my memcache secure?

Why on earth you want to store any credentials (even ciphered) on the client-side? The much better idea is to keep everything in sessions.

Moreover, if you want to think about cookies security, you cannot forget about flags like: Secure and HttpOnly.

HttpOnly - this one protects us from any kind of XSS vulnerabilities. This means, that cookie with this flag cannot be accessed through client side script (of course it works only for browsers which support this flag - nowadays, almost all of them).

Secure - this flag "forces" browser to use cookies only when secure/encrypted connection is set.


Insufficient serial number entropy in GoDaddy certificate I came across this article last night regarding SSL certificates and issues with the serial number not being long enough.  Here is a status report from GoDaddy.

According to their csv file, our sites are not affected, but I did find that our serial number for one of our sites is 63 bits instead of 64 like it should be. The other two are 64 bits.

According to the research I’ve done, the impact this would have is that GoDaddy might revoke the certificates, but until they do that, there’s very low security risk with this issue.

How can I verify if this will be an actual issue for us?

Here is some information on our certificates. I didn't post specific details of my site, so if you need additional information, please let me know and I'll update the question.

Version V3
Signature algorithm sha256RSA
Signature hash algorithm    sha256
Issuer
  CN = Go Daddy Secure Certificate Authority - G2
  OU = http://certs.godaddy.com/repository/
  O = GoDaddy.com, Inc.
  L = Scottsdale
  S = Arizona
  C = US
valid from  Wednesday, April 25, 2018 8:25:31 AM
valid to    Monday, May 25, 2020 8:53:55 AM
subject
  CN = www.example.com
  OU = Domain Control Validated

I apologize in advance for my lack of knowledge of this. I am a developer who has also been tasked with managing our web server as well.

It's perfectly valid for a serial number to be shorter than 64 bits; this can happen because the certificates use a variable length encoding (DER). The issue in this incident is whether the serial numbers contain at least 64 bits of entropy, i.e. whether they were generated from at least 64 bits of randomness. This can legitimately result in numbers where the highest bits are zero. For some certificates however, GoDaddy (and others) apparently used a method that caused the highest bit to be predicatable, thus effectively destroying one bit of entropy.

The CSV you linked is called "Final Serial Number List" in the bug report, which indicates that you're unaffected if your certificate is not included. However, the discussion about this group of incidents is still ongoing, and as far as I understand, there is still disagreement about the correct interpretation of the relevant standard (the Baseline Requirements). You can follow the debate here: https://groups.google.com/d/msg/mozilla.dev.security.policy/S2KNbJSJ-hs/F8AS4MNVCAAJ


Potential exploitation of gmail account name policies I know there have been at least two other questions related to this issue (I will link them if able) but I believe this is a potential scam, based on a recent escalation of events.

Earlier in the year I started getting registration emails for homework help sites, and when I looked at the header details I could see they were being sent to janedoe@gmail.com (or jane.doe@googlemail.com) instead of the email address I always use, jane.doe@gmail.com.  I know that gmail accounts ignore dots/periods (explained here) and therefore the accounts are the same so many potential email formats still come to me, and thought maybe some kid was just getting an email address wrong (omitting a number/letter/special character).  It was annoying but didn't concern me too much.  Each time I notified the site of the mistake, declining to click any verification links where applicable, and changed my password just to be safe.

Then I got an AppleID verification email with the same janedoe@gmail.com format.  Again I ignored.  Then, I guess because this person registering the ID never got their verification email, the kept requesting new verification emails over and over, for several hours.  I finally called Apple to request they deactivate this account (because it would never get verified anyway) and their call-center genius bar did not know about the gmail format and dot omissions and would not believe me.  They confirmed the account creation/request but the only resolution they offered was to call Google (ha) and have them forward the email to the correct recipient.  Apple just did not understand the issue.

Within the last few weeks, activity has further accelerated.  Instagram accounts and now dating website accounts are being created with this janedoe@gmail.com ID, and I am getting all the emails.  The first sites were mostly Canadian companies (I am based in the U.S.), but this latest dating site is finding romantic matches for "me" in Kenya.  I know that these emails can't be going anywhere other than my mailbox, so what is the the possible benefit of this scam?  I can no longer believe this to be a mistake.

Other than abandoning the email account, are there any steps I can take to mitigate this issue?  Has anyone else observed this kind of high activity/exploitation?

I suspect that this is a random email address brute forcing. Your mistake is probably in responding to those registration emails, which is quite likely a fake site run by the scammers. By notifying the site that you've received the email, you've set a precedent to the attacker than the mailbox is alive and attended, and is ok for further spams.

You can create a filter so that if the "To" email address is janedoe@gmail.com, then move to Spam directly.


Should a Mobile app able to check what password is locally saved via a user facing feature? I'm working at a company who is currently working to secure their mobile app (iOS native) by adding check points to security sensitive screens on the device (data is stored in the iOS keychain). User will be prompted to re-enter their password upon viewing these screens that present this data. One our requirements from Product team is asking for a usability feature that I think is a potential vulnerability.

They are basically asking for when the user leaves the field that they are typing their password to verify that it immediately turns to red or green, if the password locally is verified as invalid or valid. This seems it would make it too easy for an attacker to pick up someone's iPhone and repeatedly guess the password stored locally on the device. I would think we should check and validate with the server.

I'm asking for someone who may know more about the best practices to answer this question.

In addition, what a lot of people do is, if the user types in a wrong password x times in a timespan of x minutes, it gets denied for x seconds/minutes.

For example:

John enters a wrong password 5 times in one minute, thus he cannot log in for another 2 minutes.

Or even better, if the app NEEDS an internet connection with user accounts and such, you can even lock it after 5 times in 2 minutes (for example!), and let it be unlocked via email (companies use email a lot, if this app is for business-type users, most of them would have their mail on the same device as the application).


XSS via unsanitized window.location.search.split? I'm trying to protect my code from XSS. I used a tool to identify risks and it alerted the following code part as a possible injection case.
var urlParams = new URLSearchParams(window.location.search);
var param = urlParams.get('param');
var newUrl = "/" + param + "/goto";
document.write("Link");

I played a little bit around with some payloads but I was not able to break out and inject any code which is executed*. I wonder if this was a false positive or did I just missed a payload which executes code?
Also, in the course of this I have changed my code a little to
var param = window.location.search.split('param=')[1];

I noticed that in the latter case the parameter is url-encoded, whereas this is not the case in the first example.
Does this happen with the split() method? I want to understand the differences.

Example with ?param="; alert(1);
First case: console.log(param) prints "; alert(1);
Second case: console.log(param) prints %22;%20alert(1);

*Update: I was able to find two payloads that work:
\\"<svg/onload=alert(1)>
</script>

But why doesn't they work for window.location.search.split('param=')[1]? It is save to just use this approach instead of the first one or are there possible payloads to bypass, too?

As Steffen pointed out in his comment already, you do not specify how you use the variable newUrl. An actual XSS vulnerability would trigger when using this variable in an insecure fashion in the HTML output.

You must also be careful when using the new code you are experimenting with:

var param = window.location.search.split('param=')[1];

This will return everything after param=. If there as another variable in the URL behind param, the full string will be returned, as you can see below:

URL:     http://example.com/?x=1&param=2&z=3
Command: window.location.search.split("param=")[1]
Result:  "2&z=3"

Depending on the actual usage of the variable, this might open up further exploit potential (e.g. circumventing filters). If an XSS attack is actually possible, must be evaluated based on the usage scenario.


How to list missing security updates for Windows servers? I have a list of applied security patches and updates, exported from Windows server 2003.

The exported list is in CSV format, but converting it is not a problem for me.

Is there any tool/site/script that will check this list and will return me the list of missing updates?

I would recommend Iszi's answers above, but since you do not have access anymore these may not be feasible. I am not aware of any complete list out there listing all patches for a given platform, since the missing patches would also depend upon some other things installed that are not necessarily required (drivers, .NET, etc.). If you do not have access you are not the one who could implement the changes anyway. However, that said... you could install another fresh windows install, apply all patches, export the list, then diff them.

I just found this list of patches released for 2003: http://support.microsoft.com/kb/914962 . It might be a good start for you.


Can pen-testing be done on a person's regular machine, or should it be done on a separate machine? I am a developer and I have been looking more into security / pen-testing to make sure my application is secure.  A lot of the resources I have looked at mention having a "pen-testing machine/lab/box," which sounds to me like people are using a completely isolated machine for their testing.  However I am wondering if it is okay to pen-test on my personal machine where I develop?

I am not sure if the separate machine is used for anonymity, or if it's more the issue of the tools people try out which could possibly infect/corrupt their machine and that people should keep these unknown/questionable applications/tools in an isolated environment as to not harm personal data?   I would think most of the stuff out there meant for ethical pen-testing would be safe to work with though?

Personally I just was looking at a few testing applications like Burp Suite and I was looking into trying out some CTFs and such to expand my knowledge while just looking to protect my code and protect my personal data where I can. I figure I should be safe using Burp Suite and trying out some reputable CTFs and challenges.

I was thinking of just splitting up my development/normal-stuff on one VM instance, while having something like Kali on another instance.  I also thought about having 2 drives that I would boot from (or swapping drives out when needed) where pen-testing would be done on one drive, and development would be on another drive. I am wondering how much more secure either of these options would be compared to just running everything together on the same drive, but separate VM instances?  I believe I have heard of malware being able to infect hardware like a motherboard. If that is true, would it be possible that malware could transfer into another drive that has been plugged in to the infected motherboard, after the infected drive has been removed?  If that is possible how likely could that happen?  I do believe that if I had both drives plugged in at the same time, and the pen-testing drive gets infected, that there is a higher chance of the other drive being infected.  As for everything on the same drive, but different VMs, I have read that malware could pass through the VMs, but depending on settings seemed not as easy to pass through the VM environment. I'm curious if it's easier for Malware to exit out of a VM and infect the host machine, compared to malware passing from one drive to another(I would assume that since VM instances would be running on both of my drives that it would have to pass through the VM, to the main os to then pass to the other drive, unless one drive was accessible to other drive's VM instances)?  I would assume swapping drives out would be the safest option, but I would love to hear people's suggestions as well.

Thank you for any help in clearing this up for me.

There is no reason to overthink your penetration testing setup. As long as you are working with established tools from renowned companies - you mentioned burp as a good example - you can trust them as much as any other third party software you install on your system. There is also no reason to protect your anonymity, as you are doing nothing illegal.

Having worked as a penetration tester for many years, I always liked to separate my penetration testing system using virtualization (VMWare or Virtualbox) for several reasons:

You have a standard image with everything you need. Having a clean image with all the tools pre-configured helps a lot to start new engagements fast. That's especially important, if you work for different clients and do not want to mix up results. This is less important in your scenario, but having a standard image to fall back to, in case anything breaks, is still an asset.
You are flexible concerning the OS. I like Windows as my host operating system, but many of the penetration testing tools I am using, require Linux as OS. While I prefer assembling my favorite tools on Ubuntu manually, others prefer a swiss army knife like Kali Linux, where many tools are already pre-installed and ready to go. Whatever route you want to go, being flexible when it comes to the OS choice can make life a lot easier for you. You can even use multiple OS in different virtual machines if your tool set requires it.
You do not clutter your host OS. Penetration tests tend to require a lot of different tools and installing all of them on your main OS will load it with a lot of baggage in the long run. Managing all those tools and keeping them up to date can become a nuisance. Having them separated in a penetration testing VM deals with this problem, especially if you reset it regularly to get rid of tools you only used once.
Added security when using less trustworthy exploits. In some scenarios you want to verify that an identified vulnerability is actually exploitable, but there is no exploit code available that you feel comfortable trusting. Having a throw-away virtual image makes it easy to experiment with the exploit and clean everything afterwards by resetting to a previous state. Sure, there might be a residual risk of a super advanced hidden malware that exploits a vulnerability to break out of the Hypervisor and infects your host system... but, while that's a cool story, stuff like this happens in real life only very rarely. That's a risk I would be willing to take.

So there are no reasons that makes it mandatory to have a separate VM, and I have several tools on my host OS, just do be able to check some things quickly. Burp again, is a good example that I like to have readily available without powering up a virtual machine.

But, as I mentioned above, it pays off in the long run to have a separate environment, but there is no reason to overthink it.


Open source WhatsApp client As a follow up to Whatsapp encryption keys discussion and from WhatsApp security whitepaper, it seems that most of the components to a fully secure end-to-end encryption are already there but what seems to be lacking is a fully trusted open-source client that does not secretly transmit private keys to the server.

Not claiming WhatsApp client does it, but we would never know unless the client is open source.

I'm wondering if it's possible, with the current information that's available from WhatsApp or are there still any proprietary missing piece that is stopping us from building that?

The last position that I heard from WhatsApp is that they won't be offering a public API.

http://www.programmableweb.com/news/whatsapp-will-not-release-public-api/2015/03/30

Until they do, that's a huge sticking point. Unless of course they open sourced their own client...


Can Android phone running without SIM card be tracked (localized) by police? I am running an Android phone without a SIM card. I am using it for web surfing.
Can the police localize my phone using the cell towers (BTS)?

In other words, I know Android phones emit radiations even if there is no SIM inserted. Can the service provider use these radiations to detecte where my phone is?

A SIM identifies you with your network operator; it is necessary to be able to receive calls and to bill you for calls you make. Without a SIM, a phone is mostly useless as a phone, but it can still make emergency calls (in most countries). Without a SIM, your cell phone will not normally transmit data to local base stations, but if you make an emergency call, it will identify itself with the cell tower by sending its IMEI. So there is some information identifying your phone that can travel on the cell phone network, but only at your own behest. I don't know how easily the police can access this information.

If you've turned off GSM altogether and are only connected through wifi, it's a different matter. The wifi access point knows your phone's MAC address. Whether (or how easily) the police has access to that depends on who owns the access point.

Beyond that, your internet traffic does not inherently contain information that identifies your phone, but there is a lot of indirect information. Your IP address will pinpoint at least the access point's ISP and your general location, and with the cooperation of the access point owner your access can be tracked back to the access point by someone who is trying to trace your traffic. The content of your traffic may or may not identify you or your phone, for example through browser fingerprinting, or simply because you logged in to some online account.

If someone is in the vicinity of the access point, they can physically locate your phone by measuring its radio signal.


What role does a PC play when transferring from one attached usb-drive to another? I recently attached two usb-sticks of colleagues to my laptop and transferred a file from one to the other. The file was sensitive and was not supposed to be copied to my PC.

Never mind the background that led to this situation - suffice to say, my laptop was available for the transfer.

Question: did the act of transferring the file from one USB port to the other via my laptop leave any local "residue"? Or can my Laptop in such a case be considered the same as a network cable?

Here some related questions:

Can a file transfer to a USB pen drive be tracked in windows 7?
How to find Windows 7 File Transfer History?

USB devices talk to the computer, not to each other. During the file copy, all the data went through the RAM of the laptop -- and, precisely, through both the OS kernel and the RAM of the file explorer application. The file explorer should not have written a copy of that data anywhere on the laptop disk. However, a copy of the data has been kept in RAM by the kernel as part of the generic disk caching mechanism, and some of it may have been written to disk if the laptop was put in hibernation mode afterwards.

Of course, if the laptop was already compromised (with some malware) at the time of the copy, then your data is toast.


Updating computers over unsafe connections If an attacker manages to get control of one of the devices managing or routing internet traffic along or on my network, e.g, a compromised router or femtocell/IMSI-catcher for mobile internet, how do I go about safely and securely updating my computers (e.g, apt-get update apt-get upgrade)?

I realize doing this over tor might be a good idea, but I need to install tor in the first place and so need to connect to the internet.

Any good software updating process will be using digital signatures to ensure integrity. Every digital signature works by performing a mathematical operation on a hash of the files using a secret key known only to the operators of the software update infrastructure. The result of this operation is the creation of a digital signature. It's easy to verify that the signature came from a given secret key, but it is designed to be extremely difficult (impossible with current technology) to forge it.

The apt updater used in Debian-based systems automatically verifies digital signatures. If an attacker on the network modifies the update files, they will not be able to forge a matching signature. This will be detected and the malicious updates will not be installed. The worst an attacker can do is prevent you from updating. They cannot replace your updates with malicious ones without being detected.


moving from MD5 to SHA-512 This question is more of a security policy than a technical security question.

Many years ago I developed an asp.net site, implemented Forms Authentication, and stored the user passwords as MD5 hashs. From following basic security news it's pretty obvious that MD5 is no longer useful. I see two possible plans for handling my current users.

Copy old users table into new design and hash the current MD5 into SHA-512. Then when users login I'll hash their input first as MD5 and then as SHA-512. Kinda Rube Goldberg but it doesn't bother my users at all
Force all users to reset their password, checking the old password using MD5, but storing the new password as SHA-512.

Any thoughts? A third option I am missing?

One note: I love OpenID but it's not an option on this site

I've had to solve this same issue twice before:

My first web app, I actually knew enough to MD5 hash users' passwords; I did not, however, know about salt, and worked that in later.
Actually the same web app, a few years later, when I decided to "upgrade" to SHA-512 from the existing MD5.

In both cases, I used neither of your options, but rather option 3: Upon a user's next login, use the password to generate the new hash and replace the old one (after verifying against the old one).

In the case of adding a salt, this was pretty trivial: All I did was default everyone to a salt of "" (empty string), which could be concatenated and then hashed without having any effect whatsoever on the resultant hash; once authenticated, I generated a new salt for the user and then re-hashed the password, saving that new result.

Upgrading from MD5 to SHA-512 was a tad trickier, but by simply looking at the string length of the has in the table (I didn't use a new column for the new hash, merely expanded the existing one to accommodate the longer hash) I could tell which algorithm to use and then authenticate the user appropriately; once authenticated, if they were still on the old hash I would compute a new one (also taking the opportunity to generate a brand new salt) and store that.

In both cases I of course did eventually run into the situation where further down the road "old style" passwords still existed. After waiting an appropriate amount of time (e.g. 6 months), simply decide that those that haven't logged in since the new style was adopted are "inactive": Generate and store a new, completely random password for them (using the new style of storing it, of course), and if they ever did come back they would have to use your password reset mechanism to regain access. (Alternatively, leave as-is, but effectively invalidate it by simply dropping the code for the old style.) You could (if applicable) also send an e-mail to these users, asking them to log in to complete a security upgrade on their account, before invalidating their current password.

This approach does involve additional code in the authentication routine, of course, but it's only temporary -- once everyone has upgraded (whether by logging in or by being "forced" in as in the previous paragraph), you can remove all code responsible for performing the upgrade. Security upgrade complete, with the majority of your users (and all of your regular users) having never noticed a thing!


Secure erase partition only on SSD, not the whole thing I have a 512 SSD which is partitioned into essentially two 256 areas. One for Windows, the other for Linux (Ubuntu). Neither is encrypted. I want to clean my system up, but am only concerned about the linux partition. I understand you can not securely delete files from ssd due to the firmware deciding where to put data.

My question is if the linux partition is wiped/formatted then encrypted with a reinstall, will that sufffice or will the old data be spread across partitions (wear-leveling)?

This may seem like a silly question, but my knowledge of this sort of thing is limited.

Wear leveling is independent of partitions. All of your data is spread out over all of the flash chips in the SSD.


Is this code vulnerable to DOM based attacks? We are developing code for a Banking web application. We want to make sure that the code is secure and since we are using a lot of javascript code, we are kind of worried if any chance of a web based attack can surface. Can someone please look into the code below and comment if any attack could be possible by an attacker? The below code is within a jsp page.

  window.location.href = document.getElementById("st_val").value

st_val

is a hidden field on the form which contains either of 3 values, that is used by the Java code on the backend to decide on a logic.

This won't be problem as long as st_val is NOT under the client control. As you know, if you are setting value of the window.location.href variable it will redirect current page to the new value. If attacker set javascript:alert(1) value to the st_val this will be end up with DOM XSS.

For example;

<html>
<meta charset="utf-8"/>
Hello
<script>
function onSubmit(){
        window.location.href = document.getElementById("st_val").value;
}
</script>
        <input type="hidden" id="st_val" value="<?php echo (isset($_GET['pay']) ? $_GET['pay'] : '')?>">
        <input type="submit" value="Submit" onclick="return onSubmit();">
</html>

Attacker sends following request. http://domain.com/xss/href.php?pay=javascript:alert(1)

alert(1) function will be called immiadetly when you clicked on submit button.

In conclusion, it's safe to use window.location.href as long as values comes from your backend, without client decision!


Is it possible to fabricate x.509 certificate with varying issuer and subject fields? I'm testing a service that might not do a proper checks for the certificate chain but instead it checks issuer and subject fields only. I would need to create a (self signed?) certificate with different issuer and subject. Is this possible with OpenSSL

For example:

openssl req -new -sha256 -key mydomain.com.key -subj "/C=US/ST=CA/O=MyOrg, Inc./CN=mydomain.com" -out mydomain.com.csr

Sets both issuer and subject with the same C/O/CN fields. I cannot find a params for openssl to force different fields. Any suggestions for alternative tool?

You put self signed with a question mark without making clear if you understand what it means, namely a cert signed by the same key it contains (not just one you signed or caused to be signed). Or to be more exact, a cert signed by the private half of the keypair whose public half is contained in the cert, so that it verifies with its own key, although that verification is meaningless for security. If you do want that:

Create a keypair and a root-CA cert for that key. Any root-CA certs must, by definition, have subject=issuer and be self-signed i.e. signed by the same key it contains.
Create a child cert for that same keypair with a different subject name and other data as desired, issued/signed by the root-CA. It will thus be signed by the same keypair it contains, but have different names.
Use the child cert and if you don't need the root cert just discard it.

If not self-signed that's the normal case. Just create a CA keypair and cert, and then issue a child cert (or several) under that CA with a different name(s) and different keypair(s) and other data as desired. All certs, except root-CA and dummy/trivial self-signed EE certs, should always have subject not equal to issuer -- in fact using the same name for subject and issuer of a cert that isn't root or self-signed will usually confuse reliers and cause validation error or reject.

The one thing you can't do with OpenSSL is create cert(s) under -- that is, correctly signed by -- a 'real' CA like Verisign/Symantec/Digicert, GoDaddy, or LetsEncrypt. Thus any cert you create should not validate for any properly implemented relier by default, only if you or someone adds your 'local' CA to its truststore.


Using a single number instead of an IP address or a DNS name, which are concrete uses? My question:

I have read that using the single number equivalent (called the "binary equivalent" by the author) of the IP address instead of the actual IP address or the domain name can be used "to bypass basic ACLs".

I wonder if such an "esoteric" practice is really used and, if yes, in which scenarios?

My understanding is that the filtering may occur at two layers:

At the application layer. Here proxies will check the domain name against a blacklist. To bypass this using an IP seems by far a more practical method,
At the network layer. Here firewalls will check the destination IP against a black list: as per my understanding no matter how one entered an IP address, whether he used DNS, IP, binary, or whatever, he will still get blocked.

The only theoretical scenario I can imagine is a dumb sysadmin using a badly configured proxy instead of a firewall to fake an IP-based filtering.

Is there any more real scenario? Unless my theoretical situation actually reflects real-life security issues?

The so-called "binary equivalent" stuff:

For those who don't know what I'm referring too, I think it's quite little known that a host (let's take www.google.com for example sake) can be reached through three means:

The most obvious: its domain name: www.google.com,
A more techie way: its IP address: 216.58.210.228,
A definitively more techie way: using the decimal representation of the IP address: 3627733732.

It is the latter which interests me here. To calculate it, you need to start from the the host's IP address:

$ host www.google.com
www.google.com has address 216.58.210.228

The book I read advised to convert each of the IP address components into binary numbers, concatenate them to get a single large binary number, and convert it back to decimal. Everyone has its own taste, personally I prefer to simply cyclically multiply by 256 and add each components as in the example below:

$ bc
((( 216 * 256) + 58) * 256 + 210) * 256 + 228
3627733732

This produces a number, you can use it to access Google's server using an opaque URL like http://3627733732 or ensure that the right IP address is contacted by pinging it for instance:

$ ping 3627733732
PING 3627733732 (216.58.210.228) 56(84) bytes of data.
64 bytes from 216.58.210.228: icmp_seq=1 ttl=53 time=26.5 ms

This is quite a cool thing, cyber sorcerer, amaze your friends with this w0nderful 1337 trickz, great! But apart from that, I wonder if there is any real-life use for this?

Depends on the filter implementation and maybe the OS on the client machine.

As you said - the IP address will end up in the TCP packets in its binary representation, regardless of how it was originally passed to the socket software layer. Firewalls will filter for this binary address and thus catch anything - there is no way around that.

However, if the "firewall" or "proxy" is run on the machine subject to the blocking (e.g. on an employees machine instead of the company firewall), i see a way this would work:

If the "IP-Filter" is implemented as a sort of delegation-replacement for the OSes networking library (e.g. Windows Firewall / Windows Defender). When software asks for a new socket to Host XY it will check XY against a blacklist. If not blacklisted, it will pass the API-call on to the OS.
If that filter software does not take the single-number representation into account, it will allow connections to blacklisted hosts.

P.S.: I think this scenario is rather obscure. I cannot imagine that a serious sysadmin would rely on Windows Firewall or sth. similar. Also, think Windows Firewall uses a whitelists (remember these "Allow Software ABC to access the network XYZ?" dialouges?)


Google Chrome on Android constantly being redirected I have an Android (5.0.1 with December 2015 patches). My problem is with Chrome (latest version as per Google Play Store). Which has malicious redirect going on to hidcptqmerifcusymaqddcomolsujibeptsmycmqsrwgrcmywshgnfpjhcc.com

I have scanned the phone with both McAfee and Kaspersky security and no malware is detected. However The redirect is going on.

I suspect a JS file in the browser cache which after cleaning stops redirect for sometime (a day at best).

Any ideas how i can collect a sample before i reset my phone?

Firstly, go into Chrome -> Settings -> Search Engine and check the search engine. There is a malicious search engine bug that google is yet to fix involving JS execution via the Default Search Engines feature.

Then, grab everything from /data/data/com.android.chrome/. The chrome cache is in a directory named cache under this directory.

Next, wipe the entire directory from your phone manually and do a full factory reset.


Can FBI or government agencies get hold of my Google Docs files just by confiscating my laptop? Assume the following:

I am doing all my work, including the one with sensitive information on Google Docs. No documents are stored on local hard drive.
I am not using the Google Drive App, just doing everything via web interface
I am using incognito mode all the time.
There is no one "looking over my shoulder", or manages to install any keylogger kind of software

So, my question is, can FBI or government agencies still be able to get hold of my files stored on Google Docs by confiscating my laptop?

What I am asking is can my laptop still give me away if I use online cloud storage? We all know that even if I delete a Microsoft Word file even from Recycle Bin, there are chances that the file can still be retrieved as long as the investigators have the hard disk.

Note that this question is very different from this one here, because we are not talking about accessing the deleted data from HDD per se, but rather, accessing the data that is stored purely on the cloud and only exists temporarily on web browser

When you store data on Google Docs, as you may already know, it is not encrypted at all.  I read that everything you upload to Google Docs and similar services are not only yours anymore because you agree Google to own them too. This means, at first glance, Google has already access to your files since Google confesses that by itself:

When you upload, submit, store, send or receive content to or through
our Services, you give Google (and those we work with) a worldwide
license to use, host, store, reproduce, modify, create derivative
works (such as those resulting from translations, adaptations or other
changes we make so that your content works better with our Services),
communicate, publish, publicly perform, publicly display and
distribute such content.

Also, I am not American but from my understanding of the NSL, the FBI can access your data on Google Docs without even warning you.
In your case, I'd rather prefer to encrypt the data before storing it on Google Docs after choosing a strong algorithm and you found a secure way to protect your private key.

Update:
More than 24 hours after the question was asked, a user modified the title of the question giving it an other meaning than the original one:

First time I answered your question, you were online around fourty minutes while my answer was the only one available. You answered only to two comments of @schroeder but nothing else even after you received different answers dealing with different aspects of your question. Even one of your 2 comments was too confusing because you said a thing and its opposite:
if the government agency subpoena Google, then my data wouldn't be safe, am I right? No, I don't worry that the government agency will do that –
You did not react to accept it or comment it to ask something. After few users said that your question's title is not the same as its content, I asked you clarification via a comment I deleted (because it is too chatty already) but you did not react either. Following your silence to different answers and comments and your refusal to clear the ambiguity of your question, I need to update my answer by focusing on an other side you may wanted to ask, for further readers as the posts here are intended to last.
I had to focus on your question's title because good answers to so many questions as yours  already exist here:

Is it possible to recover securely deleted data from a hard drive using forensics?
How to recover securely deleted data
How does forensic software detect deleted files
Is data-remanence a concern in RAM?
How can I reliably erase all information on a hard drive?
Prove that you deleted the file
Ensure data doesn't linger after being deleted
I'm leaving my job and want to erase as many personal details etc. as possible; any tips?
Overwriting hard drive to securely delete a file?
Secure file deletion vs wiping free space

And the list of similar questions with good answers is still so long on this website. This is just a short list I picked myself. And we all know that when you delete a file from Windows' Recycle bin (trash), it becomes invisible to your operating system only because the file allocation table does not point to it anymore, otherwise the file exist somewhere in your hard drives and you can get it back (if the OS did not override it especially if it has been a long age since you deleted it)
There is also a point I want to add to those answers about the possibility to FBI to recover your data. It is the easiest way but the answers I read elsewhere here forget it frequently:

The easiest way for them is to use the Restore System feature of Windows. That way they could, by chance, get back your browsing history, cookies and even your secret files that you uploaded to Google Docs. By chance, I mean all depends -for the files, for instance- on the restore point you set. This is the easiest way.

Also, other answers to your question mentioned that your coockies, browsing history and browser's cache are a way for the FBI to get your data. That is true even in the case you cleared these elements from your browser because all what the FBI needs is to find where your browser stores its cache:
P.S.
If the FBI is interested to check your browsing history (supposed you hid some of your data on your secret Wordpress blog, for example), they can find where you surfed (your blog) by checking your DNS because your computer uses DNS servers to resolve hostnames to IP addresses, such queries are temporarily stored in your DNS cache.  When you clear your browser history, your DNS cache is not touched. You can try this command yourself: ipconfig /displaydns   to display the contents of the DNS resolver cache. Do not forget also that the FBI can check your router logs (even if in most routers this functionality is deactivated by default). This can be useful for them in case you downloaded some data you are not allowed to access, or in case you stored your secret data elsewhere before you upload it to Google Docs, or simply they can find a proof you used Google Docs. One thing to mention also: your browsing history still can be detected in case your ISP, the government, or whoever else decides to cache your list of browsed sites. Finally, some files of your operating system such as  Index.dat (hidden file) contain all of the Web sites that you have ever visited. Every URL and every Web page is listed there.


What does the EC Private key version field mean? I have read the question Converting ECC Private key to PKCS#1 format. And I understood that the value of the version field of the traditional EC private key is 01.

We can use the command openssl pkcs8 -topk8 -nocrypt to convert the traditional key to unencrypted) PKCS#8 format. Once the key is converted the version field of the converted key is 00.

What is the meaning of these version field? If I see a version field value as 01, Does that confirm the key is not in PKCS#8 format?

You might be misinterpreting the message you link to.

The private key is represented as a structure that comes from SEC and includes a "version field" which always has value "1".

When the private key is encoded in PKCS#8, then the previous structure is "wrapped": PKCS#8 includes some identifier of the used algorithm ("this is an EC key") and an OCTET STRING that contains the whole of the private key structure as specified above, including the version field with the value "1".

The PKCS#8 wrapper also has a "version" field, normally with value "0". So, in PKCS#8, you get both.

When there is a "version" field, this is a mechanism to potentially support other layouts -- when such things are defined. Right now, no other layout is defined, so all you can do with another value is to make the object undecodable by some software.


Security issues with using JWT + cookies for session authentication? Trying to get my head around not using traditional $_SESSIONS to keep user logged-in across pages. Are there security issues with storing JWT in cookies to authenticate a user session?

Here's a bare example of what I'm trying to do:

config.php

$key = "secret123";

login.php

use Firebase\JWT\JWT; // A simple library to encode/decode JWT

require 'config.php';

// ... assumed valid user/pass, set cookie session

$token = ['uid' => 123];
$jwt = JWT::encode($token, $key);
setcookie('jwt', $jwt);

// redirect to private page

private_page.php

require 'config.php';

if (isset($_COOKIE['jwt'])) {

    // check if JWT is tampered
    try {
        $decoded = JWT::decode($_COOKIE['jwt'], $key, ['HS256']);
    } catch (Exception $ex) {
        echo 'Invalid authentication';
    }

    echo 'You are logged in as uid '.$decoded['uid'];
}
else {
    echo 'You are NOT logged in';
}

Is this implementation secure enough, what other things should I consider?

There are several issues when using JWT instead of session cookies:

The client can view the data stored in the JWT token. With sessions, this data remains on the server.
Logging out is complicated. When the user logs out of the application it is hard to stop the JWT token from being valid.
The data in the JWT can be out of date. If a user changes his username, he still has a valid JWT token containing his previous username, while that doesn't exist in the database anymore.
There have been some bugs in JWT libraries (and maybe even the specification?) that have reduced trust in the JWT system. Particularly the decision to let the client provide the JWT type (HS256 or RS256) is considered risky.
It relies on a key you need to keep secure. If someone compromises your key they can forge valid tokens.

Valid uses of JWT tokens involve single-sign on implementations, especially OpenID connect, where multiple systems are involved. They are not a good alternative for traditional sessions.

Some links:

Stop using JWT for sessions
Why JWTs Suck as Session Tokens
Attacking JWT authentication


Is address information sensitive for companies or individuals during registration? I am designing a web site that contains external suppliers to register and keep their information with the company up to date. We already have a db with EIN, SSN numbers and their addresses.

One of the enhancements users wanted is to display a list of addresses when a known ein/ssn is entered during registration.

This avoids creating a duplicate address in the back end for the same address. It also gives them a more fluid registration process. Architect is objecting to this on the grounds of security.

I can implement a lock feature if you enter more than 3 unsuccessful attempts at guessing ein/ssn, your account is locked for an hour/day.

Is this good enough? Any alternative ways you can think of without letting somebody try ssns and display addresses. Are there any established standards?

Locking someone out after wrongfully entering their info for x amount of times for x hours/days is a good idea, but annoying to users, this helps preventing Bruteforcing.

What could be an alternative, is that instead of getting a list when you enter a SSN number, that you have to manually enter the address yourself, and a script checking if that address is used yet (if in use, it should tell you so, with a button to recover your login details, send to the email address assosciated, ofcourse not mentioning it in the warning).

That means the script should convert the address to a string that is always the same! (no capital letters or symbols. i.e.), for easy processing, or even if possible, a API/script that checks if the address is the right format/is valid.

its a small step that takes an extra 10 seconds of your life, but adds to security, atleast, thats how i would do it!


Simple methods of preventing infection from external drives What are some simple methods of preventing my computer from being infected by USB drives and other storage devices? I'm not asking for any bullet-proof methods, just something that can prevent infection in the majority of cases.

For example, one thing I do is to create a folder named Autorun.inf on all my partitions and all of my USB drives. This is to prevent an Autorun.inf file from being created, or at the very least have a quick way of knowing I've been infected — if the folder is missing, something is wrong.

To avoid infection from storage devices, don't execute any files from them, and configure your operating system to not do so automatically. But storage devices aren't the only threat in form of USB. For example, take a look at this USB keyboard:

"But that's not a keyboard! That's a USB thumb drive!" Are you sure? "Of course! I can tell a keyboard apart from a thumb drive when I see them!" Really? It might look like a thumb drive to you, but when you connect it to a PC, it says it's a keyboard, and the PC has no reason to believe that it is anything else.

As soon as this device is recognized as a keyboard by the operating system, it will automatically start typing. What's it typing? That's up to the one who programmed it. Common payloads are the keyboard shortcut to open a text editor, type a malicious script, save it, perform the shortcut to open a command shell and execute what it just wrote. Others are to open a web browser, enter the URL of an executable on a FTP server, download it and execute it.

The only software-method to protect you from this is to disable plug&play of USB devices. You will then have to enable any new USB device manually. When you plug in a thumb drive and it appears as a HID device, you have reason to be suspicious and can choose to not enable it.

But there are also hardware-solutions. There are USB adapter plugs which only allow certain types of USB devices to pass through. Unfortunately I have never used such a device, so I don't feel comfortable to give any specific product recommendations.


How to implement canaries to prevent buffer overflows? This is probably a very basic question. I've read about canaries, and how they work in theory. You have a global variable that you set to a random number in the prolog of a function, do your function, and then verify its authenticity in the epilog.

void foobar(int a, int b)
{
   prolog();
   int c = a;
   int d = b;
   char *buffer[40];
   strcpy(stupidcopy);
   epilog();
}

What I don't understand is, how do I place something on the stack in prolog? Like, if I call prolog, and tell it to save a local variable, it'll be on stack, but when we get out of prolog(), won't it be popped? How can I save the canary on stack? Do I need to modify esp using assembly code to do this?

Usually it's the compiler who generates canaries. Prologue and epilogue aren't function calls, they're the instructions the compiler places at the beginning and end of a function.

Consider a naive compiler which puts variables on the stack in the same order they appear in the code and doesn't use registers. Then your function might become:

// variables on stack
int c;
int d;
char *buffer[40];
int canary;

// prologue
canary = secret;

// normal code
c=a;
d=b;
strcpy(stupidcopy);

// epilogue
if(canary != secret)
    OhNoesABufferOverflow();
return;

You can't write this code yourself since compilers can and do optimize storage on the stack. They can reorder variables, keep them in registers and it could even optimize out canary entirely since no well-behaved code will ever trigger the condition.


TLS 1.0 JavaScript injection vulnerability (BEAST): what to do client-side? With the alleged SSL/TLS vulnerabilities used by the BEAST exploit, there seems to be a security gap between TLS versions; TLS 1.0 being the problematic one but still the only option for many sites.

If indeed there is a problem with older TLS versions, what measures should we take, at the user end, in order to prevent possible attacks? I would think that a browser plugin to report the TLS version and allow connections only when safer versions are used would be very useful, but haven't been able to find one yet.

Any other suggestions, practical tips etc.?

Until the security hole is closed both ends (web server and browser software) it will be hard to prevent. Unfortunately because the current exploit targets cookies you have minimal control over it client-side. The only exception is to change your encryption ciphers and block or reorder CBC ciphers to the least preferable so it has the least likelihood of being used for SSL/TLS communication.

See http://support.microsoft.com/kb/245030 and http://blogs.technet.com/b/steriley/archive/2007/11/06/changing-the-ssl-cipher-order-in-internet-explorer-7-on-windows-vista.aspx for how to do this on Windows.

I would suggest that the best thing you can do before a client-side fix is available is education and awareness. Including:

Log out of websites when not in use, instead of just closing the browser.
Don’t save login credentials.
Find out what your trading partners are doing to implement tighter security controls on their web sites.

I guess it also important to note that not all websites using legacy SSL/TLS versions are affected. While the transport security part (SSL/TLS) is, there may be other anti-spoofing techniques in place to reduce the impact of information disclosure.

Stay tuned, be ready to deploy newer browser versions, and no doubt there will be more news soon but hopefully some fixes.


Enhanced Key Usage vs. Extended Key Usage I've seen both the terms Enhanced Key Usage and Extended Key Usage, and both were abbreviated as EKU. Do both refer to the same extension or property?

The correct name for the standard extension is Extended Key Usage; see section 4.2.1.12 of RFC 5280. Its OID is 2.5.29.37.

Confusion comes from Microsoft documentation and software:

They use "extended key usage" and "enhanced key usage" interchangeably.
They defined a Microsoft-specific extension called "Application Policies" (OID 1.3.6.1.4.1.311.21.10) which contains the same information as Extended Key Usage, but with the ASN.1 syntax of "Certificate Policies" (another unrelated extension).
Documentation repeatedly talks of storing extended/enhanced key usageS into the Application Policies extension. That is, they use the two expressions "extended key usage" and "enhanced key usage" to designate both the extension and the OID they can put in that extension, or in its clone extension "Application Policies".

Since Microsoft-specific extensions are Microsoft-specific, Microsoft's CA ("Certificate Services") usually includes both extensions (the standard one and the Microsoft one) in issued certificates.


Flask debug=True exploitation It's a well known fact that Flask's debug=True option can lead to remote code execution via werkzeug debugger capabilities and even several resources were hacked. I decided to look into it and it turned out that the technique doesn't work if the app is being run by a forking application server like uwsgi or gunicorn. So the questions are:

Is there an opportunity to exploit Flask application with debug=True enabled even if it's being run by a forking application server (gunicorn, uwsgi)? I can't believe that all this hacked resources used built-in Flask's web server in production.
Did all that hacked sites run Flask app directly without using "standard" approach like nginx + gunicorn/uwsgi + Flask?

If we enable the debugger with this code:

app = flask.Flask(__name__)
app.debug = True

That only enables the debugger with the built-in dev server. To use the Werkzeug debugger with another WSGI server, we have to explicitly include the middleware:

from werkzeug.debug import DebuggedApplication
from waitress import serve
app = DebuggedApplication(app, evalex=True, pin_security=False)
serve(app, listen='*:8080')

When you do this, with evalex and pin_security options as above, the app is trivially vulnerable to remote compromise.


How to prove that some action was taken by client in the presence of a malicious server? Suppose a client places an order on an eCommerce platform. And then claims that they did not place the order.

How can we prove that the order was in fact placed by the customer assuming that we cannot trust the platform?

One example would be to see the server logs but that wouldn't work if we assume the platform is malicious.

In other words, what are the traces someone leaves when dealing with a website besides the logs on the platform itself? Equivalently, what prevents a website from placing an order on their servers on the client's behalf without the client's permission?

Assuming the platform knows the user's details, this is almost certainly not possible without massively inconveniencing your users.

The easiest solution would be to just not store any user details. If the user can't place an order without entering their payment card, shipping address, and so on, then anybody can be reasonably sure that, if you have those details, the user was placing an order. However, that doesn't cover things like "what was ordered in what quantity" or prevent a malicious server from logging those details after all and using them to place another order later.

For non-repudation protection like that, you typically need some sort of attestation (on every client action) that only the client can provide. A simple example would be a digital signature (of the order details) using a private key that the client has but the server does not; the signature could be verified by anybody with the public key but couldn't be faked. This is basically the digital equivalent of requiring a customer to sign a receipt or enter their PIN, proving that they approved the transaction.

However, any kind of cryptographic scheme runs into key management problems (where does the client store the private key? Does it move between client systems following the user, and if so how? Remember that the server needs to never be allowed to use it). Additionally, for a web site, the signing would have to be done in JS, which means the server could just serve modified JS that takes the user's key and signs the order anyhow. You could tell the user that their order won't be accepted unless they use an external openpgp app to sign it (echo "I am purchasing 43 widgets" | gpg -sa) and copy-paste the signature, but it's a rare set of users who'd stand for that.

On the server side, there's no "traces" you could find that couldn't have been planted. Logs, file or database accesses, tickets in an ordering system... you control all of it, so you can fake whatever you want so long as it doesn't require knowing something that the client knows and you don't (like a private key).

The entire connection to the client is encrypted (at least, it had better be!) so even if there's a trusted third party (such as an ISP) between you and the client, they wouldn't be able to tell what was said. They could tell if there'd been no communication at all... along a particular path.

Client-side, the client could plant (or delete) any trace you might look for, and that's assuming there's anything to trace in the first place. Browser history might say what pages the user viewed, but the browser doesn't store the details of what requests it sent (unless you sit there with the dev tools open and recording) and order pages are usually dynamic anyhow. Besides, your site could contain script that quickly navigates through those pages, and then they'd be in the user's history even though no order was actually placed.


How vulnerable are rolling codes used in car keyfobs to simple replay attacks? I've read this question - Vehicle remote key security, and I have a few simpler questions that are not addressed in that one.

I just received a whatsapp viral forward raising a few claims regarding security of car keyfobs. I feel that one or more of these claims are bogus, and wanted to check with the community. It is hardly the work of sophisticated security professional, so the likelihood of claims being bogus is high.

Here is the video: https://www.youtube.com/watch?v=fjmEdYQo9K0. It's in Hindi, but I'll outline the claims here.

It claims that when you lock the vehicle, there is a universal remote that an attacker can use to capture the secret code, which it can replay to unlock the car at will.
It seems that the secret code is being captured from a single LOCK command.
The best way to guard this security code is to lock the car manually, so that potential attackers can't sniff out the security code.

We're talking about $10,000 cars here using OEM security systems, nothing fancy or high-end.

From the previous question linked here, I know that OEMs frequently use roll-your-own crypto, and the systems, especially in commodity vehicles, are hardly unbeatable. The simplicity of the supposed attack raises a lot of questions for me, though.

A simple replay attack should not be possible because most modern cars use some form of rolling codes.
While there is some body of work that talks about private keys being reconstructed from a set of 10-20 rolling codes, it hardly seems possible from just one rolling code.
There isn't a very good reason for a LOCK command to emit a rolling code. A malicious attacker spoofing a LOCK command would hardly be able to cause significant nuisance/denial of service. I'm not sure how the protocols work in practice.
Advising owners to manually lock the vehicle sounds like malicious advice. While a manual lock may mechanically secure the vehicle doors, it won't actually engage the car's immobilizer/electronic security system, leaving it actually more vulnerable.

Thoughts on these four points would be appreciated.

They should, but it is not necessarily true they do. There were smart locks that did not use rolling codes and could be cracked with one captured command.
Depends on how they implement rolling codes. I don't have a problem believing someone was clueless enough to use predictable algorithm, such as increase the previous hash value by one and hash, that would provide no security. These guys are usually hardly security experts. Or they may not use rolling codes as I noted in 1.
It is likely all commands use the same system of authentication.
Yes, it does seem dodgy. But it depends on the car. Some cars have central locking that would engage all the security regardless of how the vehicle was locked.


What happens if my signing subkeys are compromised? Let's say my subkeys are compromised, but my master keypair is safe and secure, so I revoke the old subkeys and issue new ones.

With encryption keys, the results are pretty clear: I can still decrypt both old and new messages encrypted with the key, but so can the key thief.

But what about my signing keys?

Will all things I have signed in the past with those subkeys be considered "invalid"?

Will the person who stole my keys be able to sign whatever he wants, assuming the person doing the validating hasn't updated their keyring in a while and doesn't know that the old signing keypair has been revoked?

Are there other dangers resulting from compromised signing keys that I need to be aware of?

Lets assume that we're talking about PGP/GPG keys, and you've uploaded your public key for signing to one of the main PGP/GPG key servers.

If you're curious how to revoke a certificate, here's a Guide to Revoking PGP/GPG Certificates.

With those assumptions in mind:

  Will all things I have signed in the past with those subkeys be
  considered "invalid"?

Yes.  As long as the software is checking certificates for revocation anything signed in the past will be considered signed with a revoked certificate.  It does not stop anyone from viewing a document, or reading an email.  It's now at the user's discretion to trust the information or not.

  Will the person who stole my keys be able to sign whatever he wants,
  assuming the person doing the validating hasn't updated their keyring
  in a while and doesn't know that the old signing keypair has been
  revoked?

If the attacker has your private key then they can sign data as if it were from you.   Once the certificate is marked as revoked in the keyserver anything the attacker signs will also come up as signed by a revoked certificate.  Again, it's up to the user to verify the data, and decide to trust it or not.

  Are there other dangers resulting from compromised signing keys that I
  need to be aware of?

Signing keys can be used for user identification/verification.  Let's say your company uses your signing keys to identify you on their network, and provide you with privileged access.  Compromised certificates that aren't revoked can now get into your company's network, and gain access as you.

All of this is contingent on the software used for verification actually checking if a certificate is revoked, and using a keyserver.  There are various opinions of this one way or the other.

Adam Langley has written an interesting article on revocation checking.


Encrypt folder on Linux that can only be decrypted on that specific OS and device Suppose I want to give a computer to someone that runs an application. I want to avoid that the program can be copied to another computer or be tampered with. For that, I want to encrypt the folder that contains the program and would like to make it so that only the host OS (Linux) on that device can decrypt it (ie. also avoid moving the disk between computers). There is no TPM in the computer. Secure boot is already running, but is seems that this gets reset when resetting the CMOS. The application requires network, so that is already available.

Is this possible? I don't really see how this can be done, if possible. And it not, how far can I get to make it as difficult as possible?

No matter what you do, you will need to store an encryption key somewhere, which will then be recoverable. If you require a license server, this could be worked around by hooking or patching the application. You can do things like this to slow down an adversary, but it won't be complete protection. If you really don't want to give out your software, use a client-server architecture with the bulk of the logic on the server side and require authentication from a paid/authorized user (although then you can't prevent the client software from being copied or modified either, but that's usually an accepted risk).


BOF - How to determine adress of system() using a leak memory? I am training myself for BOF and ASLR in 32Bits. I wrote a program that seems like this :

int main(int argc, char **argv)
{
    char buffer[32];
    printf(argv[1]);
    gets(buffer);
    return 0;
}

With a format string I can get main's return address which is: 0xf7e19637 <=> __libc_start_main+247.

But now I don't know what I can do with this address to find the address of the system function to do a Ret2LibC!

EDIT:
After researchs I found this How to leak libc base address using format string exploit which is the same program, and he wants to exploit it as the same way as I want (he is in x86_64). But I do not understand how he does its script.

You have to grab your libc binary and compute the offset in bytes from __libc_start_main+247 to the function you want to call. ASLR randomizes the base address from where the module is loaded, but it cannot randomize internal offsets between elements inside the module itself. You can find this offset in gdb by executing

print system - __libc_start_main+247

... while running the program. Hence, to find system given __libc_start_main+247, just add the value you got by running that command. Keep in mind that this offset does depend on the version of the module and the way it was built, so it may be different between systems. You can roughly guess, "if it runs Ubuntu xxxx, offset should be this", or you can make sure by means of arbitrary read primitives.


Is storing authorization tokens on Android 's AccountManager secure? How secure it is (not) to store a JWT token (for instance) in Android's AccountManager?
I know a good alternative would be to use the android KeyStore, specially with the new Jetpack Security libs, but I'd like some folks input about the risks of doing the other way.
Ref: Android AccountManager

To answer from the security standpoint, and according to the linked answer from SO, the real risk is that a root user can actually exfiltrate the JWT.
Android is hardened enough to that processes do not interfere each other. But if the user running the device has root capabilities, and given that your application can't detect root for sure, there is the possibility that any app running as root, voluntarily by the device owner, or maliciously, can exfitrate the token

This database can be found at /data/system/users/0/accounts.db, where 0 is user's ID.

And is not encrypted.


Does salt increase security if there is only a single hashed password? Say there is only a single hashed password in the passwords file.

If it was salted, would that make it more secure?

My logic is:

Yes because SALT helps protect against rainbow tables and dictionary attacks. Which would make it more secure?

Absolutely.  If no salt is used, then a precalculated set of tables, called rainbow table, can be used to determine the plaintext of the password.  With salt, a brute force process of calculating every possible value till the hash is matched is the only way to find the password.


Is there a reason why Android blocks emulating a RFID tag? So, I have this public transportation card, as well as a card that grants access to my school and lastly one that grants access to my work's office building.

My android device doesn't allow me to create a "Wallet" containing all the information stored on each of those cards and broadcast it.

Is there a valid security concern, or what is the reason it doesn't allow us to do so?

There are two different kinds of RFID tags.

Cheap ones which just broadcast their serial number in clear text as soon as they get into a magnetic field
Expensive ones which use a cryptographically secure protocol to authenticate

Cloning the first variant is trivial: You just record their number and broadcast the same one.

The second variant, however, is not that easy to clone. They have a secret key which never leaves the chip. You would need that secret key to clone them. So it's not like your Android device doesn't want to clone these tags, it can't.

Public transportation passes and access control cards are use-cases where cloning the card of someone else would break the system. Cloning the cheap variant is quite easy to do without the owner of the card noticing it. You just need to get a reading device close enough to their card. It is very likely that the makers opted for the more expensive variant to prevent people from cloning them.


Can I buy a signing-valid certificate for internal use? So now that I have to implement "secure transport" as defined by The Direct Project (not to mention reinventing a bunch of wheels, but that's another story for SO), I find myself staring down the barrel at having to create several dozen internal users' S/MIME certificates since (for obvious reasons, I think), I'd very much like to avoid putting the process into their hands as much as possible. An "organization level" cert is out, because "internal reasons."

So basically my question is whether it's available to buy some sort of "organizational CA" cert from an established, that will let me generate and sign S/MIME certificates, so that I can implement to Direct Project specifications without the recipients' clients worrying about untrusted certifications, or having to keep going back to the CA whenever a user joins/leaves the organization? I've tried checking some of the CAs I know of, but they seem mostly targeted at the "end user with a website" SSL certificate, so I may be missing something. Suggestions welcomed and apprciated

Add'l info: For those fortunate souls unfamiliar with it, The Direct Project standard is basically mandated every user's certificate available via either A DNS CERT RR and an externally-accessible anonymous LDAP query, and an S/MIME-capable MTA that can retrieve said cert from either location.

Some established CA will agree to sell you an intermediate CA certificate, but at a rather steep cost. There are several forces at hand here:

An "established CA" is "established" by virtue of having its root key included in the usual browsers and OS. The CA operator could achieve that by signing a heavy contract with Microsoft, in which he promised to apply very strict rules when verifying the identity of certificate owners. When a CA issues an intermediate CA certificate, it delegates its power. Bluntly stated, if you buy an intermediate CA certificate from an established CA, nothing technically prevents you from then issuing a fake certificate for, e.g., "gmail.com", that all Web browsers on Earth will accept as genuine.

Therefore, established CA have promised (with penalties in the millions of dollars) that if they ever give away an intermediate CA certificate to a third party, then they will do so only within a heavy contractual framework which would allow powerful legal retaliation, should that third party begin to issue certificates without all due care with regards to user authentication.
Established CA make money by selling certificates. They want to keep it that way. When you buy an intermediate CA certificate, it is to issue the end user certificates yourself, and therefore to cease to buy such certificates from the established CA. From their point of view, this is lost business. So they will recoup it by pricing the intermediate CA certificate heftily.

Also, it is too easy to underestimate the costs of operating a CA. A CA is 5% cryptography, 95% procedures. Procedures mean people, and paper, and time. That's expensive. Maintaining your own CA, be it an intermediate CA from some external established CA, or a full-blown root CA of your own, is hardly worth the effort for less than, say, a thousand certificates to issue per year. People often believe that a home-made CA is just a matter of writing a couple of scripts around OpenSSL; and they are wrong.


How to exchange RSA public keys safely between two parties? How to exchange RSA public keys safely between two parties via internet?

Get yourself a trusted key. Two easiest options are an SSL certificate ($50..$100) and a GPG key (free).

Encrypt or sign the data you send with that key. With SSL, you can just serve your data via https, but can also just sign it. With GPG, you have to build enough trust for your key, so that the receiving end is sure it's you and not an impostor.

Another option is to create a  public key to your SSH server, publish it and let people just SCP your data from there. Send them fingerprints of your SSH key via snail mail or tell verbally by Skype / phone. An impostor would have to fake your key, your server on a known domain name, and your phone / Skype / SIP contact; this should be sufficiently hard to thwart such attempts.


I'm not using SSL, what could I do to increase security on my website? I'm not using SSL encryption on my website. Which (correct if I'm wrong) means the data transmitted between users and the server can be sniffed as text, including passwords.

That is a big security threat, and I really can't install SSL for various other reasons. What can I do to increase security on my website? I though of only enabling social login, could you give me any other tips?

Setup an SSL certificate!
That's really the only answer here, especially if you are having people login.  An attacker on the same network as your users can sniff everything, and an attacker who gets themselves in the middle can modify your response to remove any client-side protections you try to enable.  I'd say that trying to secure a non-HTTPS connection is like trying to build a house without a foundation, but it's more like trying to build a sandcastle on a sandbar that is only exposed at low tide and covered in 10 feet of water at high tide.  It's literally impossible.
These days you can easily get free certificates from let's encrypt.  If your hosting company can't support SSL then it is time to move to a new one.  Moving to a new company will be easier than trying to build privacy without HTTPS.
As a software provider though
If you are providing software and so are not responsible for deployment, and thus cannot provide certificates, then attempting to secure an HTTP connection is an even more dangerous approach. The problem is that if you say "We provide X safe guards so HTTPS is unnecessary!" your customers will believe you, and when your safeguards are inevitably breached you will be held liable. Don't do it. I have had to deploy a lot of 3rd party software systems so here are the sorts of things you want to do:

Give suggestions for ways that they can add SSL via infrastructure, by doing things like putting a load balancer on top and using it for SSL termination. Most cloud providers can automatically provide SSL for their own load balancers.
Provide a way for the end user to provide an SSL certificate which your software will use (do them a favor and make sure there is an option to automatically configure your software for automatic deployments)
Provide some pre-baked options for automatic certificate management via Let's Encrypt/certbot.


Generating a PIN from cryptographic bytes One of our applications uses SQL Server for the back end, and that application requires a 4 digit numerical PIN for employees to be created that works with a key (more or less). The system itself defaults all PINs to 0000 because that's the magic value for "don't require a PIN" if the device you're using doesn't have a keypad.

We had an issue with employees not updating their PIN (and grew tired of waiting for the vendor to correct the issue) so we generate our own PINs with SQL Server using a scheduled job to update any PINs of 0000.

The PINs don't need to be secure (how secure is a 4-digit PIN, after all) they just need to not be trivial. However, there's no reason not to think about the problem with security in mind, and I like to take the time to understand what I'm doing at least semi competently:

The current solution (not by me!) was:

replace(str(round(rand(checksum(newid()))*10000,0),4), ' ','0')

There's a couple problems with this. Of course, neither rand() nor newid() are cryptographic functions, but the issue that actually requires the change is that this will occasionally generate a pin of **** because of quirks with the str() function.

Now, SQL Server does have the crypt_gen_random() function, which returns a fixed number of bytes of secure cryptographically generated numbers. That makes me think something like this should work:

format(cast(crypt_gen_random(2) as int) % 10000,'0000')

The problem that I see is that crypt_gen_random(2) is basically, "Pick a number between 0 and 65535." In that space, however, there's a bias for modulo 10000. There's 7 instances of every result between 0 and 5535, but only 6 instances of every result between 5536 and 9999. That's a 16% difference.

Now, I can think of a possible easy fix, but I'm not sure if there's a preferred method. I'm not a security programmer. Can simply increase the number of bytes generated?

format(cast(crypt_gen_random(7) as bigint) % 10000,'0000')

[Note: I'm using bigint instead of int because it supports numbers of up to 8 bytes long. I'm only generating 7 bytes instead of 8 to prevent negative numbers.]

If I generate 7 bytes instead of 2, I'm generating a number between 0 and 72057594037927935 (16^14). The problem is still there -- there's 7205759403793 values between 0 and 7935, but only 7205759403792 between 7936 and 9999 -- but that's so much dilution that it doesn't really matter.  We're at like 10^-12.

Like I said, though, I'm not a security programmer. I'm a DBA, analyst, and administrator, and all I know about security programming is that I'm not qualified to know when I'm making a security mistake.

Is there a better way of doing this?

My solution for T-SQL essentially ends up looking something like this:

declare @candidate_pin int = cast(crypt_gen_random(2) as int)
while @candidate_pin not between 1 and 9999
    set @candidate_pin = cast(crypt_gen_random(2) as int)

select format(@candidate_pin, '0000') as [pin]

I was hoping to avoid using procedural logic instead of a simpler declarative statement, but I'm not going to try to force it into a recursive CTE or other declarative solution.

I'm not particularly concerned with performance here; if we need 100 new PINs in a quarter something strange is going on.

Yes, you need at least 14 bits to generate a number between 0 and 9999.

In order to avoid bias, you can generate 14 bits of random data using a good source of randomness. If the result is <= 9999, then you can use it as your PIN. If the result is bigger, throw it away and try again.

  How much does this waste?

In the best possible case, your bits would align perfectly with your answer space, and you would not waste anything. You could generate a random value between 0 and 255 and all you had to do was to generate 8 random bits. Any result would be valid, assuming your random generator is good.

In the worst possible case, you would require a random number between 0 and 256, which means you need 9 bits, and thus have 512 possible values. In approximately 50% of these cases you would have to throw the result away.

In our example, our lower bound with 13 bits would only give us 8196 possible values, and our next possible target is 16384 possible values. Given that you want 10000 possible values, your possible space is more than one and a half times bigger than your target space.

But fear not, you are working with relatively small amounts of data. If you query 7 random bytes, you get 56 random bits, which means 4 "tries" to get a "good" value. Even if we would assume that you had a 50% chance (the worst case) to get a good value, in 4 tries you have a 93.75% chance of generating a good PIN. If you would be unlucky, you would have to query another 7 bytes, which would boost your chance to 99.6% to pick a good PIN.

  Cool! Can I have a demo?

function GeneratePIN()
{
    // The chance to fail after 1000 rounds is 7.5 * 10^-1203
    for(int round = 0; round < 1000; round++)
    {
        // We generate 7 random bytes, which would give us 4 "tries"
        ulong randomness = SecureRandom.GenerateBytes(7);

        // We can iterate this 4 times before our 7 bytes are exhausted
        for (int try = 0; try < 4; try++)
        {
            ushort possiblePIN = randomness & 0x3FFF; //0x3fff is 0011 1111 1111 1111 in binary, so 14 bits set to 1

            // If we succeed, we return the PIN. Else we try again
            if (possiblePIN < 10000)
            {
                return possiblePIN;
            }
            else
            {
                // =>> is the right shift, assign operator
                // This will shift randomness 14 bits to the right
                randomness =>> 14;
            }
        }

        // If we reached this part, we were unlucky and need to try again.
    }

    // If we reach this part, we flipped a coin 1000 times and always got heads.
    // Maybe buy a lottery ticket
    throw new Exception("Buy a lottery ticket!");
}


Risk of web admin portal without extra authentication steps more of a philosophical question, suppose there is one behavior which allows an attacker to do something with high impact but by itself cannot be used to cause that impact. For example, internet accessible admin portal which even though still requires authentication, it doesn't have IP whitelist nor 2FA.

Suppose that using the admin portal, an attacker can upload a shell and compromise the whole server.

Would you classify just having relaxed controls on the admin portal authentication as vulnerability?

If yes, what would you say just would you say is the CVSS score?

The risk? I guess here, the impact is high but the likelihood would be in relation to how easy is for someone to acquire valid credentials, which in most cases should be very low)

I would say it's not vulnerability since one needs valid credentials to actually be able to use the portal. But i hear people having a lot of different opinions so i would like to see some other people's thoughts.

It's similar to having a gun (admin portal) without bullets (credentials). It's only dangerous if you somehow manage to get bullets.

It's an interesting question, and I'm not sure I can answer correctly. But here are my thoughts anyway.

It can't be a vulnerability. A vulnerability is something that can be exploited, and if it can't be exploited it can't be a vulnerability. The lack of an IP whitelist isn't something that can be exploited, if authentication requires a strong password.

It is probably a weakness. A weakness is something that is technically wrong or imperfect, and that in some cases might lead to a vulnerability (but not necessarily). So why should you let random IPs connect to the admin panel, if you are sure that only a few specific IPs will ever need to access it? The best, perfect, ideal thing to do would be to use an IP whitelist. So the lack of an IP whitelist would be a kind of weakness. It won't necessarily lead to a vulnerability, but it might. Example: imagine that an attacker steals the admin's password by shoulder-surfing. The attacker goes back to his basement and tries to connect... and if you have an IP whitelist the attacker will fail. But if you don't have the IP whitelist, what was only a weakness then becomes a vulnerability.

Note that CWE (Common Weakness Enumeration) actually includes "use of single-factor authentication" in the list of weaknesses: CWE-308.

So in my opinion, implementing an IP whitelist in this case can be defined as defense in depth, because you are actually protecting from weaknesses, and preventing them from becoming vulnerabilities if something were to go wrong.


Does the Web Cryptography API prevent a bad server from slurping cleartext? Consider a cryptographic web application that relies on hosted JavaScript. This JavaScript could be manipulated server-side by a bad actor, defeating any cryptographic tasks. Namely:

private keys could be sent back to the server
cleartext could be sent back to the server

The Web Cryptography API addresses some of these concerns by providing cryptographic primitives without exposing keys, addressing item 1.

It looks to me like bad JavaScript could still transmit cleartext back to the server. Am I missing something, or is this issue not addressed by Web Crypto?

It doesn't. That's excusable, because it cannot.

The server sends the code. If the server is hostile or compromised, then the code sent by the server may be malicious. It doesn't matter what the API does: the code sent by the server can avoid using it, or otherwise send all the data in cleartext to the server.

The reason to have cryptographic primitives that don't expose keys is mostly to protect against a server that's trustworthy, but that delivers code that can be partially exploited. If the attacker can arrange to run arbitrary Javascript code in your browser, you've lost. If the attacker is restricted in certain ways, e.g. if can only extract certain information or can only infect certain pages, then adding protections such as non-exposed keys makes it harder for the attacker to obtain the data they want.


Is there a great cheap or free site for the CISSP exam? CCCure is not free and many others that are recommended on the site are not free....any suggestions?

Check out Eric Conrad's 500 questions and podcasts.  Thanks to Eric and to Syngress/Elsevier for making these available!  http://www.ericconrad.com/2014/04/my-500-cissp-questions.html

My experience with practice questions is that they're really going to exercise what you learned from a particular book; in this case, the free questions test you on information you can get from CISSP Study Guide. It was my primary reference for the exam.  Caveat: if you're not using that book as a reference then the questions may scare you, but ... they're free, and they're great.


Can a hacker determine what version of WordPress and PHP a site is using? Can a hacker determine what version of WordPress and PHP a site is using?
Assume this info is not available by View Source.

Most PHP-enabled web servers will display the PHP version in the Server response header.  For example, my development machine currently shows this with all of its requests:

Server: Apache/2.4.38 (Win64) PHP/7.3.2

There are configuration settings to turn off displaying the PHP version, and it really is quite trivial to lie about anything and everything in HTTP response headers.

Additionally, there are several ways to get the version of Wordpress installed, the easiest way being to to go to /readme.html on the site.

The RSS/ATOM feeds will also often include the Wordpress version number.

Though you said we should assume that the information isn't available by viewing the page's source, it is often available in a meta tag, depending on the theme.

Links to some resources will have cache busting parameters attached to them, with the cache busting string sometimes being the version of Wordpress that is installed.

And, if you have the time and determination, you can fingerprint the common files that are found in most Wordpress distributions. If a file changes in a specific version, you can look for those changes.

A clever developer can cause each of these to lie, of course, and can mutate the static files in a way that makes fingerprinting them a futile endeavor, but most people follow the default behavior of their PHP version and Wordpress software, making it trivial to identify versions.

All of this underscores the importance of keeping your software up to date to prevent known vulnerabilities from being exploited.

As far as whether or not a hacker can identify the version of PHP and Wordpress...  Well, anyone can, so I suppose a hacker can, as well.


Diffie Hellman Group Matching to IPSec Encryption Algorithm I'm looking for help determining acceptable Diffie Hellman (DH) Groups for specific IPSec IKE and ESP Encryption Algorithms. The goal is to choose DH groups that provide adequate protection for the keys to be used by selected Encryption Algorithms while avoiding unnecessary overhead from DH groups that are poorly-matched (slower DH groups without added security benefits?).

The specific Encryption Algorithms I can choose from include AES-CBC and AES-GCM with various key lengths (128, 256, etc).

The Diffie Hellman Groups I can select from include

14 = 2048-bit MODP group
19 = 256-bit random ECP group
20 = 384-bit random ECP group
21 = 521-bit random ECP group
24 = 2048-bit MODP Group with 256-bit Prime Order Subgroup

Some of the information I'm reading from Network Security vendor documents suggest the use of DH Elliptic Curve (EC) groups like 19, 20, and 21 over the other groups.

Cisco "When possible, use ... the ... ECDH groups"
Check Point

"elliptic curve Diffie-Hellman groups ... provide better performance"
"groups described in RFC 5114 (Group 24 ...) are NOT RECOMMENDED for use"

IBM "Guideline: If you are using encryption or authentication algorithms with a 128-bit key, use Diffie-Hellman groups 5,14,19,20, or 24. If you are using encryption or authentication algorithms with a key length of 256 bits or greater, use Diffie-Hellman group 21."

I am particularly confused about when to use Groups 14 and 24. Is 24 stronger than 21? I'm thinking 21 is stronger even though the DH group number 24 is higher (just a group identifier number). I also am thinking that group 19 is stronger than 14 - not because of the higher number, but because of the stronger EC algorithm? Based on some of my reading, it appears that the groups ordered by strength from low to high would be something like 14, 24, 19, 20, 21 - meaning that if available, the ECP groups 19,20,21 should be preferred over both 14 and 24?

These crypto discussions can easily lead to advanced math and I'm hoping to avoid that as much as possible - please use the most basic explanations or simplest math possible.

Update 21 Oct 2017. I found some useful info in RFC 5114 under Section 4 "Security Considerations". Based on this recommendation, we can consider DH Groups 14 and 24 as too weak to protect AES 128 Symmetric Keys - this leaves DH Groups 19 through 21 ECP as the minimum acceptable Diffie Hellman groups for generating AES symmetric keys (128 bit and higher).

  When secret keys of an appropriate size are used, an approximation of
     the strength of each of the Diffie-Hellman groups is provided in the
     table below.  For each group, the table contains an RSA key size and
     symmetric key size that provide roughly equivalent levels of
     security.  This data is based on the recommendations in [NIST80057].

GROUP                                      |  SYMMETRIC |   RSA
-------------------------------------------+------------+-------
1024-bit MODP with 160-bit Prime Subgroup  |        80  |   1024
2048-bit MODP with 224-bit Prime Subgroup  |       112  |   2048
2048-bit MODP with 256-bit Prime Subgroup  |       112  |   2048
192-bit Random ECP Group                   |        80  |   1024
224-bit Random ECP Group                   |       112  |   2048
256-bit Random ECP Group                   |       128  |   3072
384-bit Random ECP Group                   |       192  |   7680
521-bit Random ECP Group                   |       256  |  15360

Group Numbers mapped to DH algorithm names from RFC 5114 "IKE" Section.

NAME                                                    | NUMBER
--------------------------------------------------------+---------
1024-bit MODP Group with 160-bit Prime Order Subgroup   |   22
2048-bit MODP Group with 224-bit Prime Order Subgroup   |   23
2048-bit MODP Group with 256-bit Prime Order Subgroup   |   24
192-bit Random ECP Group                                |   25
224-bit Random ECP Group                                |   26
256-bit Random ECP Group                                |   19
384-bit Random ECP Group                                |   20
521-bit Random ECP Group                                |   21

I was able to find some pairing suggestions in the strongSwan Security Recommendations document under the "Cipher Selection" heading.

"aes128-sha256-modp3072 (AES-CBC-128, SHA-256 as HMAC and DH key exchange with 3072 bit key length)" DH-Group-15 (not available on my device)
"aes128gcm16-prfsha256-ecp256 (AES-GCM-128 AEAD, SHA-256 as PRF and ECDH key exchange with 256 bit key length)" DH-Group-19
"aes256gcm16-prfsha384-ecp384 (AES-GCM-256 AEAD, SHA-384 as PRF and ECDH key exchange with 384 bit key length)" DH-Group-20

It seems that the pairing recommendations may be loosely based on algorithm strength analysis listed on the Belgian BlueKrypt keylength.com site.

This is the closest I could get to a diffie-hellman algorithm pairing recommendation. Please post if you find other reputable sources for selecting well-matched diffie-hellman groups for use with IPSec encryption.


windows firewall turns OFF automatically It seems pretty weird but for some reason, the Windows 7 firewall turns off. After I turn the firewall on in the control panel, it seems that it turns itself off when I go back to the control after I reboot. Note that I'm using AVG Internet Security 2012 and Windows 7 x64 Pro.

Is this normal behavior? Is AVG turning the Windows Firewall off automatically?

Thanks for your suggestions.

AVG Internet Security 2012 includes its own firewall function, and so yes, it shuts down the Windows Firewall when it runs. Running multiple host firewalls on Windows is unpredictable and not recommended.


The need for created timestamp in tokens In different token, for example SAML, I have encountered I have seen that it includes the timestamp for when it was created. I understand the reason for a expiration timestamp, but before the token is created it doesnt exist so I dont understand the reason for it.

Ideas.
It gives possibility for the receiver to specify expiration time
It takes unsynchronized machine time into account

Often I've used the created timestamp as a way of proving uniqueness.  The general assumption is that the granularity of the timestamp will be unique enough that a given receiver can assume that only one request with the timestamp or with a unique value that includes the timestamp will be received.

That would prevent some forms of replay attack, where an attacker gets a copy of an authenticated request and replays it at a later time to get updated information without having the necessary credentials.