How are hackers able to plant Phishing URLs in existing websites? As the question says, How are hackers able to plant Phishing URLs in existing websites? And can it be detected?

You honestly could have a wide array of possibilities and answers depending on how something would be 'compromised.' When you think about it, if StackExchange wasn't monitoring for active hyperlinks and tracing it to things like reputation sources at virustotal, proofpoint, etc. Then you could easily just comment/post phishing URL's in any public forums for comment. If you're referring to more of a compromise sort of things there's a few things to think about:

If the site has input capabilities; then vulnerable injection vectors such as persistent XSS can have layered scripts inserted that have phishing links or other click fraud and related malicious objects
There's also direct compromise-- manipulating the content displayed on the webpage. Common vulnerabilities and exploits exist in CMS's like wordpress.
There's also possibilities where an advertising network or CDN is compromised and attackers can have phishing related clickable links or ads served (even exploits).

As far as detection, you need active content scraping and analysis possibly including the following protection mechanisms:

Static pages -- integrity checking
Have a crawler or bot continuously check the ads or dynamic content served for malicious scripts or URL's
Have your reverse proxy or WAF detect returned content to the user for possible injected or unauthorized content
Ensure that whatever combination of LAYERED detection and protection mechanisms you have can deobfuscate basic encodings like Base64, HTML, etc.


Certified Ethical Hacking courses I want to take a CEH exam, I'd like to know what tutorials and books are recomended for this kind of study.

I also would like to know if there are certifications that are better-recognized, so that I can focus on them.

Materials for CEH

The at-home learning options from EC-Council itself were very good when I took it for v6.

Various study guides are available, but don't cover the full extent of the CEH material, so I won't even link to them here.

Other Certifications

CEH (I hold this cert) is an entry-level ethical hacking certification. It shows that you know what various hacking tools are and what they can do. It basically shows that you have 'heard of' ways to break into networks and servers [i.e. "What's Ettercap?"].

Security+ is a more general security certification and covers more ground, but not ethical hacking.

But if you are looking for the 'cream' of ethical hacking certifications (in my opinion), look at the OSCP. It is not as well-known as the CEH, but it requires you to actually hack servers, write exploits, and produce a penetration testing report. Plus it is aimed for those who may not know much before the class (if so, get the 90 day lab option and try everything out).

Practical experience is the best 'certification'. Being able to explain in a single sentence how you HAVE accomplished a task is worth more than papers. Fortunately, there are tons of materials to help you get that kind of experience. So, not matter which certification you go for, make sure you are spending time each week trying out a new tool or technique.

Certifications in General

I know that lots of people look down on certifications, but they are a valuable tool to get an employed position in the area you want to work in so that you can gain on-the-job experience while working with pros who do have the experience. You just have to be honest about what the certification is. It doesn't prove you can do anything, it simply shows you have a minimum body of knowledge. And that has some worth.


Setting up a fake AP - problem with iptables and DNS server Im trying to set up a fake AP using aircrack-ng suite, DHCP server & iptables.

After creating the fake AP:

airmon-ng start wlan1
airbase-ng -c 11 -e "freewifi" wlan1mon

running iptables configuration and at0 routing rules(bash file):

#!/bin/sh
ifconfig at0 up
ifconfig at0 10.0.0.1 netmask 255.255.255.0
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables --flush
iptables --table nat --flush
iptables --delete-chain
iptables --table nat --delete-chain
iptables -P FORWARD ACCEPT
iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to- port 10000
iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE

running DHCP server : /etc/init.d/isc-dhcp-server start

/etc/dhcp/dhpd.conf file:

authoritative;
default-lease-time 600;
max-lease-time 7200;
subnet 10.0.0.0 netmask 255.255.255.0
{
    option subnet-mask 255.255.255.0;
    option domain-name "freewifi";
    option routers 10.0.0.1;
    option domain-name-servers 194.90.0.1;
    range 10.0.0.10 10.0.0.20;
}

/etc/default/isc-dhcp-server file:

Running sslstrip and ettercap :

sslstrip -f -p -k
ettercap -p -u -T -q -i at0

First, no internet connection is given, I can connect to my "freewifi" AP and im even given an IP address, but internet connection cant be made:

then, I've noticed that it has Https on the address, sslstrip should strip down the s from https, so that was odd also.

I suspect that maybe I have a problem with my bridging (iptables), any help?

Kali Linux.

You have different problems here. I think access point and dhcp are ok. Let's talk about iptables and sslstrip.

on sslstrip, you are using arguments -f -p -k 10000 but it makes no sense... port 10000 is default. And to set port you must use -l  so you can avoid its use. Should be sslstrip -f -p -k and that's all or you can put sslstrip -f -p -k -l 10000 which is the same.

Talking about iptables and forwarding. echo 1 > /proc/sys/net/ipv4/ip_forward is ok. The route add makes no sense. You already have internet access on eth0 (I guess), so you don't need a route for the fake ap network. Of course at0 ip must be a different network range than eth0. Put a different ip range, something like 172.16.0.0/24 for example or any other.

But the order of the rules in iptables is important. Masquerading must be done at the end. And you have a typo on ssl port. You put 1000 instead of 10000!!!! <- OP edited his question and corrected it.

The flushes are ok:

iptables --flush
iptables --table nat --flush
iptables --delete-chain
iptables --table nat --delete-chain

And then, if you have the general policy FORWARD with ACCEPT, it doesn't make sense to do FORWARD rules with -j ACCEPT like this iptables --append FORWARD --in-interface at0 -j ACCEPT. Forget rules about udp... web navigation is tcp, so this is not important: iptables -t nat -A PREROUTING -p udp -j DNAT --to 192.168.1.1. The only point of doing this is to redirect dns traffic to your own dns server... But I can't see you have a dns server on this example so makes no sense.

This should be:

iptables -P FORWARD ACCEPT
iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 10000
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

And that's all.

So the final compilation is:

#!/bin/sh
ifconfig at0 up
ifconfig at0 192.168.1.129 netmask 255.255.255.128
ifconfig at0 mtu 1400
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables --flush
iptables --table nat --flush
iptables --delete-chain
iptables --table nat --delete-chain
iptables -P FORWARD ACCEPT
iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 10000
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Anyway, I can recommend to you a script on which I'm collaborating which automatize all of this stuff and is very handy!. It has a lot of FakeAP/Evil Twin features: airgeddon. Give it a try! is a good script already included in BlackArch, Wifislax and ArchStrike repositories.

Good luck! and remember to test sslstrip you must use urls without explicitely putting https. And facebook is a bad starting point because of HSTS. Try with outlook.com it works! To avoid HSTS is more advanced, you'll need sslstrip2 (is called too sslstrip+) and you'll need a proxy+dns (another incoming feature of airgeddon which is already developed and is under testing phase, is in a development branch and maybe this week could be in master).


Connecting to VPN send login credentials encrypted or unencrypted? I searched for a specific answer to this question and although there are many answers about VPN encryption, I did not find this specific question answered. Setup as follows:

MyPC -> VPN -> RestaurantISP -> Internet

When I first connect to my VPN service using either the OpenVPN protocol or the app supplied by my VPN provider, does it send the username and password unencrypted or are the credentials sent encrypted?

More specifically, if the RestaurantISP installs a packet sniffer, could they see my login details, like username and password?

Technically, the answer to your question depends on the VPN software used and possibly on how it's configured - there are many different network authentication protocols out there, and many VPN programs support more than one - but in practice you can reasonably assume that your credentials are not sent in clear text. No VPN client worth the bytes used to store it would send plain-text credentials by default, and most aren't even configurable to do so.

Of course, not all non-plain-text authentication methods are equivalently secure. MS-CHAPv2, for example, is pretty easy to break. It'd still take more than just looking at the network traffic in a packet capture to extract the credentials, though.


Securing opensource web application I have an open source website. I need to add an admin section to the website which is accessible to only one person. To make it secure, I was thinking about providing a login page which checks if the password matches to a predefined password and sets a session indicating the login was successful. This password will be stored as an environment variable in the server.

Do you think this approach is secure? This website does not have a database. So I don't want to add dependency to a database just for keeping user accounts and passwords.

Website is written using nodejs and ExpressJS.

Your webserver can disallow access to files and folders.  You could make this configuration in a .htaccess file which contains your password hash.  Storing plaintext passwords should be avoided at all costs.

Make sure that authentication is performed over HTTPS and HTTPS is used for the life of the session. If you don't follow this guideline then you will be in violation of OWASP a9.


MD5 before PBKDF2 on legacy software I am mantaining a legacy software that uses MD5 in the following way:

The client asks for a 16 byte salt when authenticating an account.
The server generates a 16 byte salt, links it to the account and sends it back to the client.
The client appends the 16 byte salt on a password, does MD5(pass + salt) and sends the MD5 hash through the network.
As the server stores the plaintext password in the database, it only retrieves the password and compares MD5(database_pass + salt) with the received MD5(pass + salt) from the client.

As I can't change the workings of the client, I was thinking about what I could do to stop storing the plaintext password on the database. The idea I came with was to, instead of storing the plaintext password on the database, to store the 16 byte salt used by the client and, at the registration, generate the MD5(pass + salt) and use this MD5 as the input to PBKDF2 with a 64 bytes salt and HMAC-SHA512, 10000 iterations. Then, to authenticate, I would receive the MD5(pass + salt) from the client and PBKDF2 it to check with the stored PBKDF2 hash.

My doubt is, will this make my server more secure? As the password and the MD5(pass + salt) won't be stored on the database, the password won't be accessible anymore if my database leaks, but is there a problem with using MD5 before?

Are there any possible problems with this approach? Is there a better approach to it?

The only drawback I can think of is that I won't have access to the client's password after a successful authentication, so changing the authentication system later will be difficult. I will have the MD5(pass + salt), but then changing the salt would be impossible.

I want to do this right because I won't be able to change the system later. Any help is appreciated.

I think there is a serious flaw in your suggestion: unless I miss my mark, your "salt" isn't a salt at all: it's a challenge and, as such, it should be randomly generated each time a client attempts to authenticate.

If this is the case, then you cannot use it as input for the pbkdf2 function. It will just not work. If it is not the case, then unless you're already using a secure connection between the client and server, your auth scheme is seriously flawed: it is vulnerable to a replay attack and sniffing just as much as a plaintext password.

Overall, it's always better not to try to implement these kind of scheme: use a secure connection (TLS) between the client and server to protect data in motion and use PBKDF2 (or any standard key-derivation function that matches your requirement: BCRYPT, SCRYPT, etc.) to protect data at rest. If you really need challenge-response, then use SCRAM.

In your case, unfortunately, implementing SCRAM would require a change in the way the client works.

The best alternative would be for you to store the password in (reversibly) encrypted form. However, protecting the keys properly a very complex task: difficult to get right and easy to get wrong. It's hard to make suggestion for this type of implementation since it depends much on the value of the assets you're protecting (I would suggest, however, that you consider moving the authentication to a completely different system that only interact with the main one through a strict interface)


Securely Storing Access Tokens for Azure Key Vault I am using Azure's KEY vault to store encryption keys and handle encryption and decryption as we have a specification that requires encryption keys to be kept offsite, however this has left me with the problem of what to do with the access_token I have received from azures Oauth process.

Common sense tells me I should encrypt this token when stored in the database however I cant do that as the encryption function on azure requires the token to perform encryption and decryption therefore cannot be used to encrypt itself.

It seems all I have done is move the goalpost, I no longer have the encryption key stored in a database, instead I have an access token that can be used to decrypt the data anyway. I have to store client_id and client_secret un_encrypted for the same reason.

Am I missing something here?

I am not sure whether the access_token that you have received from Azure Authentication has permanent lifetime. I am assuming it is not. Either way, you still need to have client_id and client_secret to get the access_token, and that means you should instead focus on securing the client_secret or finding the alternatives.

Instead of using client_secret to authenticate, you can use client certificate authentication as explained in this documentation: Authenticate with a Certificate instead of a Client Secret.

In the picture above, the developer does not need to know the private key value of the certificate in order for their app to be successfully authenticated to Azure Active Directory. Instead, they only need to know the location of the imported pfx in the Certificate Store.

At least on Windows, you as secret administrator can convert the private key and the certificate into pfx format which is password protected, and then deploy it into the Windows Certificate store. This way no one could know the private key unless they know the password of the pfx file.

The other approach specifics for Azure Compute, is to use Azure Managed Service Identity. Using Azure MSI, Azure will automatically assign your resources such as VM with an identity / Service Principal, and you can fire requests at a specific endpoint that are only accessible by your resource to get the access_token. But be wary that Azure MSI are still under public preview, so please review the known issues before using it.

The picture above explain how Azure Resource Manager assign a Service Principal identity to your VM.

When you enable MSI in a VM, Azure will create a service principal in your AAD.
Azure will then deploy a new MSI VM extension to your VM. This provides an endpoint at http://localhost:50432/oauth2/token to be used to get the access_token for the service principal.
You can then use the access_token to access the resources such as Key Vault which authorize the service principal access.


Is there value in storing passwords in their own table with encrypted or hashed keys? The usual method for simple sites is to store a hash of a user's password right in their user record.

What if the password field is removed from the user table, and a password table is created? The password table would have the same password hash, but instead of the user id, the key to the table is another hash - a hash of the userid and some secret key.

The idea being that if you get a copy of the user table, you don't get the password hashes. If you get the user and the password table, you cannot connect a password to any particular user account.

I suppose if you could crack the password hash, you'd have a handful of passwords you know are in use on the system. You could try each password on each account until it works. So perhaps I answered my own question. Nevertheless is there something I'm missing? This feels like a good idea, but I couldn't find any thing about it.

I suppose that it might be easy to detect an attack that is using a list of passwords that do exist for users in the system and block or otherwise shutdown  the attack.

If you use an appropriate cryptographic password hashing function (e.g., bcrypt, scrypt, or PBKDF2), the value added by this approach is negligible. So, really, the solution is simply to responsibly hash your passwords in the first place.


Is SSH2 still vulnerable to man-in-middle attacks? With SSH using RSA public key authentication, can an attacker spoof the server IP address and connect with client to obtain client password?

There's always going to be a chicken-and-egg problem -- how do you trust the ssh key of the server you're connecting to if you've never connected to it before. Some sites publish lists of all their SSH keys, some go further and PGP-sign these lists, but it all ultimately comes back to the age-old problem of distributing trust.

The latest and most promising approach is to publish SSH fingerprints for the servers in the DNS records that are then signed using DNSSec. E.g.:

$ dig +short -t sshfp fedorapeople.org
2 1 9EB13E6BEE80F5D56B4E9A029DC53CF00EF14045
1 1 5829B0460C2E9296BDBD835416C2615DCF80D22A

You can then add the following to your ~/.ssh/config

VerifyHostKeyDNS yes

You have to also configure DNSSec on your resolver for it to make any difference.


API's Security for API which are opened to Non-Logged in Users We have a website and for which we have backend APIs.
Now the issue is majority of our APIs are opened for non-logged in user(Functional Requirement).
Now what we want is to secure those APIs in terms that no one you should start crawling and get all the data.
One obvious way is definitely bot detector. What are the other standard ways of doing this.

You could use:

IP denylist/allowlist (by country for example or block all IP from common cloud providers such as GCP, AWS etc).
Rate limiting based on IP


What is the recommended length for a phone PIN? I recently read that you're supposed to have a phone pin consisting of at least six digits. Why?

I'd get it if the pin was stored as a hash in a database, even though six digits would easily be brute-forceable in that case. That database would of course be in the phones storage, which you don't get access to without the pin. Realistically that part of the phone's storage wouldn't be user-accessible.

Also, Android disables the phone for a while, after entering the wrong pin five times. This gives a potential attacker a 0.05% chance of guessing the pin, when assuming a four-digit pin.

So what are the benefits of a longer PIN for your phone? And what length should you really use?

I would say the article you read is incorrect. I don't think it is a common opinion of security experts that phone PIN should consist of at least six digits.

At first glance it would seem that six digits is 100 times more secure than four digits. While this may be the case, the aggressive brute-force protection on a phone makes it infeasible to guess a large fraction of the key space. I would say four digits provides adequate security.

If you read it in the lifehacker article, there is a big inconsistency that should be pointed out. The Homeland Security agent testified that the PIN was not relevant:

  The agent was brought to testify that it was trivial enough to extract the data with an IP Box, and thus that it was of no consequence whether or not that passcode was obtained

This seems to indicate that some attackers can bypass the brute-force protection, so a longer PIN will only take a little longer to crack. I don't understand how LifeHacker could use this as a base for an article to increase the PIN size. A better solution would be to upgrade to a better phone or phone OS.

Edit: the IP Box does a brute-force attack, so PIN size does influence the time it would take. This only seems to work on older iOS versions (<= 8.1.1).


Does a username/password + emailed PIN count as strong 2FA? To log in to a enterprise web app, our security team is insisting on 2FA as it is hosted on our internal network.

The proposed solution is to have a standard username (email address) and password login, which will then trigger a four digit PIN emailed to the user which they will have to enter to log in.

To my mind that is two sides of the same coin (something the users knows) - using the email address, rather than sending the PIN to a phone number or a physical token.

Is this strictly 2FA? Is it significantly more secure, or is it just an additional inconvenience to the user in return for little gain?

From a pure security standpoint I wouldn't regard this as 2FA (which is traditionally defined as "two of something you know, something you have, something you are).

From a practical standpoint I can see some potential issues with this in an enterprise setting. In many companies login to applications is tied to Active Directory sign-in which is also used for access to the e-mail system, so an attacker with access to the users account username/password would likely also be able to get access to the token.

Even if they're not formally linked a lot of corporate users in my experience will practice a kind of informal single sign-on where they manually sync up their passwords for all corporate systems, so again an attacker with access to one will get access to the others, bypassing your 2FA.

If you consider another likely attack scenario (malware on the users PC) again it would bypass this requirement as it would be possible to access the users passwords for the application and e-mail service using a keylogger.

So in summary, I'd say that of your two options this is more an additional inconvenience in return for little gain.  If the risk profile of the application justifies 2FA, I'd look at full 2FA style solutions (e.g physical tokens or biometrics)


How does a website owner decrypt ASP.NET's Viewstate, and cookies I'd like to audit my viewstate for information I don't want to be sent down to the client.  What are the steps needed to decrypt this information into human readable form?

How would I decrypt the cookies?

Are there any tools (akin to Firesheep) that will help with the process?

As @blowdart mentioned, the default is to not encrypt the view state (again, I think that was changed in the latest versions).

If you just want to do an audit - set the view state to NOT encrypt (either the default, or manually shut it off), and then you don't need to decrypt it. Then when you're done, you can put view state encryption back on.

Though if you're ensuring there is no sensitive info anyway, you probably don't need the encryption, just set it to signing...

As for tools, try any of these (if its not encrypted):

http://sourceforge.net/projects/viewstate/
http://www.fiddler2.com/fiddler2/
http://ashishware.com/ViewStatePeeker.shtml (ala Firesheep, I assume you meant an easy plugin for Firefox)

I also found this question on Stack Overflow.


Is there an original information source linking output of Qualys SSL report to settings in nginx and Apache configurations? The online tool at Qualys for testing webserver SSL configurations, https://www.ssllabs.com/ssltest/index.html, produces a list of codeslike TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_CAMELLIA_256_CBC_SHA etc.

There are a lot of howtos on the net, but none of them show how to relate the actual string codes to those in the webservers. It is easy enough to use them but there is no knowning how they arrive at those settings in particular.

Is there some kind of table relating the codes with the actual lines in nginx or apache configurations?

I think you're asking how to map the openssl ciphers list configuration that you can supply to Apache and to Nginx to the IANA TLS cipher suite list.

openssl have a list that translates cipher suite names between their standard names used in RFCs (and by Qualys tool) and the names used by openssl.

You should take advantage of openssl's ability to generate longer list of cipher suites from shorter names, and specify a succinct configuration like EECDH+aRSA+AESGCM:EDH+aRSA+AESGCM:EECDH+aRSA+AES:EDH+aRSA+AES that makes openssl generate this:

> openssl ciphers -v 'EECDH+aRSA+AESGCM:EDH+aRSA+AESGCM:EECDH+aRSA+AES:EDH+aRSA+AES'
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES256-GCM-SHA384   TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES128-GCM-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES256-SHA384     TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(256)    Mac=SHA384
ECDHE-RSA-AES256-SHA        SSLv3   Kx=ECDH     Au=RSA  Enc=AES(256)    Mac=SHA1
ECDHE-RSA-AES128-SHA256     TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(128)    Mac=SHA256
ECDHE-RSA-AES128-SHA        SSLv3   Kx=ECDH     Au=RSA  Enc=AES(128)    Mac=SHA1
DHE-RSA-AES256-SHA256       TLSv1.2 Kx=DH       Au=RSA  Enc=AES(256)    Mac=SHA256
DHE-RSA-AES256-SHA          SSLv3   Kx=DH       Au=RSA  Enc=AES(256)    Mac=SHA1
DHE-RSA-AES128-SHA256       TLSv1.2 Kx=DH       Au=RSA  Enc=AES(128)    Mac=SHA256
DHE-RSA-AES128-SHA          SSLv3   Kx=DH       Au=RSA  Enc=AES(128)    Mac=SHA1

which is basically what you want (as long as you don't use ECDSA certificates and made sure your DHE uses a good 2048 bit group).


Is there antivirus software for iphone model 6s? I suspect malware (aka a virus) on my iPhone model 6s.  I could be totally wrong.
But, I hit a wall when I asked Apple, they said

There is no such software
The manager said he refused to research that topic
there is no escalation procedure for my request

I felt like I was having a conversation decades ago.  Could it be that the Apple malware is rare or non-existent (which I doubt otherwise every government agency would use the iPhone)?  Or more likely, that the NSA has spyware on the iPhone, and it is a violation of law to reveal such information?

I don't want to erase my old, to-be-replace iPhone 6s which would also erase (possibly) the malware, if any.

The first question may be "Why do you think your phone has malware?" Bear in mind that this diagram, while not universally correct, is a good default assumption.

Assuming your phone is not jailbroken, an antivirus app would not have the necessary permissions to perform most of the tasks you would expect of such software (such as scanning installed apps, detecting malicious software in real-time, or repairing modified system files). Similarly, unless malware contained something similar to a jailbreak hack itself, it is unlikely that it could significantly interfere with the phone's operation.

The most likely impacts of malware (for non-jailbroken phones) are things like racking up high phone bills through premium calls or SMS (a common problem on Android; not sure about iOS), tracking your location, or possibly injecting browser ads or spying on browser activity. These are all things that a malicious app could potentially do (although the risk of such apps is relatively low, it is not zero). Simply uninstalling the relevant application should fix the problem.

If your phone is jailbroken, both the likelihood of malware and its potential impacts increase significantly. Detecting and removing it is likely to be more difficult as well. The best fix in that case may well be to hard reset (completely wipe) the phone.

Resetting the phone is also probably the best approach to fixing an unexplained issue that isn't caused by malware. Make sure your data is backed up first!


What are the benefits to adding a bitcoin blockhash UID notation to one's OpenPGP key? Example:

  Notation data: blockhash@bitcoin.org 000000000000000011d9f6931e65f814c6f3b221736b0c45f25e0365a3d156fa

As seen here: https://sks-keyservers.net/pks/lookup?op=vindex&search=0x7FAB114267E4FA04

In case you are not familiar with bitcoin, the "blockhash" above refers to a particular block of transactions which was mined on the same day the PGP key was created: 2013-10-19 07:11:32

Does this establish a minimum age of the UID?  Or some other benefit?

This is a great question, I'm not 100% sure, but my guess is that it's a proof of age that the PGP key is newer than 2013-10-19. My reasoning is as follows:

What makes blockchain mining computationally hard is fiddling with the nonce until the hash of that block has a specific number of leading zeros (16 hex zeros, or 64 binary zeros in this case). Once you find such a nonce for that block of transactions, you can publish the block and claim the bitcoin mining reward.

That hash is 64 hex digits = 32 bytes, or 256 bits. Currently there are 410086 block in the blockchain. That means the chances of guessing a random 192 bit hex value (256 - 64 bits of leading zeros) and having it match the hash of an existing block is about 1 / 10^52. So the fact that he embedded in his key the hash of a block from 2013-10-19 means that this block had already been published by the time he published his key; but there's nothing to stop him from having inserted that retro-actively.

In summary: this proves that the key was published sometime between 2013-10-19 and now.

I also notice that the key was first self-signed on 2012-04-25, but the blockhash wasn't added until 2013-10-19 and then the same blockhash has been carried forward ever since. I'm a little stumped to as to what that's proving. Why would you want to prove that you key is newer than a certain time?

If you want a definitive answer, then email him! I'm sure a bitcoin / PGP nerd would be happy to explain!


What are the TCP/UDP ports used by torrent applications? I want to block torrent traffic on my network because it is utilizing too much bandwidth and disrupted my network traffic. What port range should I use and what protocol TCP or UDP?

Blocking Bittorrent is challenging, and can't really be done effectively with port blocks. The standard ports are 6881-6889 TCP, but the protocol can be run on any port, and the peer-to-peer nature of the protocol means that discovering peers that use unblocked ports is simple.

Blocking Bittorrent traffic could be done with a deep-packet-inspection or application firewall, but many Bittorrent clients support encryption that makes DPI less effective.

If you own the network and bandwidth is your big issue, then you would be best served by a bandwidth monitoring solution. Quality-of-service (QOS) control and bandwidth caps for endpoints could limit the impact the Bittorrent users are having on your overall bandwidth, without the cat-and-mouse game of trying to block a particular protocol.

Another approach would be to block the types of connections that Bittorrent requires. As a peer-to-peer protocol, peers outside your network need to connect in. A firewall could prohibit incoming connections to your user subnet, while permitting them to your intended outward-facing services. An IPS could put a threshold on the number of incoming and outgoing connections, since Bittorrent clients need to connect to multiple peers (and have multiple peers connect to them) in order to function.

If your concern is the legality of the shared content (or if you plan on taking any action against your users), then your best defense is a well-written acceptable-use policy outlining the users' responsibility for their actions and forbidding the use of file-sharing software.


Hosting multiple websites securely I have multiple websites running on the same server, built with various CMS's and frameworks. I need to completely isolate them. I need this because in the future I want to allow some of my clients to host websites on these server, even some potentially vulnerable code (sites full of outdated wp plugins, et cetera). Since I don't want to take responsibility for clients' code, I have to make sure that the environment is safe and if one of them gets hacked, others run fine and the server itself is not compromised.
What I have now is a very experimental environment with chroot jailed sftp access. The problem is, (and there might be other risk factors too), that all websites are run by the same webserver user, let's say www-data. So in theory an attack involving uploading malware and executing it from the browser can harm all the websites with code owned by www-data. Similar ideas come to mind for the system database user (not the user I give to the client, but the user running the mysql process).
What's the best practice to handle this issue? Also, if you have anything, checklists, whatever, don't hesitate to share.

Install a VM hypervisor on your server(s) and create a separate virtual machine for each user which runs an own webserver and database instance.
When you don't have a unique public IP address for each user, then you can point all the DNS entries to the same public IP where you run a reverse proxy which routes each request to the LAN-IP of the correct VM (side-effect: from the perspective of the users, all requests will appear to originate from the reverse proxy).
This allows the user to do whatever they want with their VM and when they totally mess it up, you just need to reset the VM. Setting CPU and RAM quotas for the VMs also prevents your users from DOSing each other through resource consumption.
Another advantage is that you can allow the users to modify their webserver configuration without any conflicts with other users. This can be useful when users have conflicting requirements regarding certain settings or software versions.


Encryption for intranet site? I am developing a web application which will be downloaded, installed and used by my customers on their intranet. The data in the application is confidential, so all requests and responses need to be encrypted. What is the best way to accomplish this?
I have two goals: (1) privacy of data and (2) ease-of-use.
I am familiar with self-signed certificates. But browsers are not friendly to self-signed certificates. They display scary warnings. Of late self-signed certificates have become harder to use. Chrome requires the user to type "this is unsafe" to go to the site.
You can't use a real certificate either, because real certificates are only granted to real domains. You could edit the hosts file of the PC to point a real domain to an intranet server, then you could use a real certificate. But this is hard for customers. (And impossible if they have ChromeBooks and no DNS servers.)
SSL was invented in 1994, and now it is 2021. Surely this is a solved problem?

SSL was invented in 1994, and now it is 2021. Surely this is a solved problem?

Surely SSL/TLS had evolved into something much more secure, with stakeholders such as IETF TLS working group, CA/B forum, browser vendors, etc. being more sophiscated at securing the connections for ordinary users.
There is one possible solution for your customers. With this solution, you don't have to mass-install certificates on all machines, but you do have to periodically pay for some ISP service.

Get a public domain name, and a certificate for it,

Resolve the domain name to your private intranet server address.

That's obviously less painful to configure individual computers, but nonetheless require a technical staff to setup the server.
Additionally, per advice from my CA provider, setting up OCSP stapling on the server can improve performance when browsers verifies the validity of the certificate.


Isn't it less secure to use something you are for authentication? I have to think of this everyday when I close the doors of the shop I work in:

A year ago we used to close the shop and arm the alarm using a key fob. This means the worst case scenario was that I get robbed.

A few months ago my boss decided that we need a password to set the alarm. This means thugs will kidnap me and beat me till I tell them my password.

Yesterday he was thinking about investing in locking with a fingerprint sensor. Great, this means I'll lose my fingers if I ever get kidnapped.

How can we make our system more secure than using only single-factor authentication?

Whether something is "more" or "less" secure depends on a lot of things including the perspective of the person designing the mechanism.

In this example from the perspective of your boss, using fingerprint scans could be more secure for two reasons.  One the percentage of thieves who will cut peoples appendages off is likely lower than the percentage who would steal something from your pocket.  Two, with a fingerprint system if there is a risk of insider collaboration with thieves a fingerprint scanner means that it can be proven (assuming they haven't had that finger removed) which employee was present at the time of the theft.

None of that means that this is better from your perspective of course in fact as you say, losing an appendage is way worse than being pick-pocketed or beaten up for a password.

Also in all this I'm assuming that there's no way to bypass the fingerprint sensor. If I was you, you could point out to your boss that most fingerprint sensors are bypassable by people lifting prints from things like a glass in a bar and once you've lost control of the print, these systems can be worse than useless (e.g. if a criminal has all 10 prints, they can always get access past the system and there's nothing you can do to change your prints)


What's the benefit of hybrid cryptosystem vs asymmetric for small data blocks? It's a common belief hybrid cryptosystems are better than asymmetric only. Is that allways like that?

What's the benefit of using symmetric and asymmetric encryption for small data blocks (< 100 bytes)?

If you have messages to send, and you use an asymmetric encryption algorithm, and that algorithm happens to be able to process each message wholesale because the messages are small enough, then indeed you can design the protocol without any recourse to extra symmetric encryption.

However this may lose some flexibility, and have a non-trivial performance cost. The flexibility is about the possibility to replace, in an ulterior version of the protocol, the asymmetric encryption algorithm (e.g. RSA) with another algorithm that can only do key-exchange (e.g. Diffie-Hellman); in the latter case, you absolutely need to couple it with symmetric encryption.

For the performance, a critical point is whether you envision two parties to send to each other several messages in a short time. With "pure RSA" and a 4096-bit RSA key, each encrypted message will need 512 bytes. With an hybrid system, successive messages may reuse an already negotiated session key, and thus need only 120 bytes or so (if the plaintext messages are about 100-byte long). Of course there is also the issue of CPU cost (RSA-4096 decryption are not exactly free), but network bandwidth issues are often more important.

Take note that if several messages are sent and each of them is encrypted separately, then it is your responsibility to include in the messages something which allows the recipient to detect whether some messages were dropped, or duplicated, or arrived out-of-order. You may also want to add some specific countermeasures to detect alterations of messages, and completely phony messages.

More generally, with RSA encryption, the public key is public, hence everybody can use the key to encrypt messages. If you have a notion of a "stream of messages" then you will need some more crypto to avoid external insertion of extra messages. This is linked with notions of authentication. There again, systems that rely on hybrid encryption can reuse an initial handshake procedure, and thus guarantee that all messages protected (through symmetric encryption and MAC) with a given session key all come from the same source.

To sum up: you should use TLS or DTLS. Designing your own protocol is a path fraught with perils.


Send credit card info by email from HTTPS and SMTP on SSL A client asked me to receive credit card info of his costumers by email.
I know that is a very very not secure way ...
But if the page with the input form is on HTTPS, and then i use a smtp (like mandrill) that use a SSL/TLS ... the email can be sniffed from someone?

Edit:

Using an encryption system like http://www.sendinc.com/ ( with their api ) could be a solution?

I would not trust credit card details to be sent out over email unencrypted, and while I am not an expert in PCI, I believe this violates PCI's requirements to protect cardholder data.  HTTPS merely encrypts data transfer between the web browser and the web server over the network.  If your email client is set up to use SMTP with SSL, that only encrypts data transfer between your email client and your email domain (e.g., if your address is gmail.com its encrypted while being sent to gmail's servers, but then gmail can fully read your data).  Your mail server may route your plaintext email to many other servers (who would be able to read that information), even going over unencrypted networks if necessary.

Also again, I wouldn't trust PCI data with a company like http://www.sendinc.com/.  They say they randomly generate a decryption key, which they will send to you, and also say they will not keep their own copy of that key.  That last part relies on you trusting them not to keep a copy of your key or plaintext message, and I simply would not trust them to do so without an explicit business agreement that holds them liable to any flaws in their implementation setup that allows any malicious admin (or hacker) at their end to steal your data.  If you need to send sensitive data over email, I would save it into a file and encrypt that file somehow locally (on the same computer) and then  send the encrypted file to the client, and on a separate secure channel give the client the passphrase/key to decrypt it.

If this needs to be done infrequently, maybe something simple like install GPG in a linux/unix environment (like Mac OS X) and use gpg -c sensitive_file.txt, which will prompt you for a passphrase, and create an encrypted file sensitive_file.txt.gpg which you can then send for the other party to decrypt (gpg -d sensitive_file.txt.gpg) with a passphrase you've shared in person or through a non-eavesdroppable channel.  Otherwise, you both should set up a public/private keys that you each trust, and then can set up encrypted email clients with PGP or S/MIME.  This is a little bit more work, but most modern email clients support some form of email encryption.

PS: This request seems very strange.  Are you sure you aren't being socially engineered by someone trying to steal credit card information?  Make sure this is really your client, not someone posing as the client (say after getting their login credentials/email account password in any of a variety of ways) who is now trying to get you to give away credit card information in a phishing attempt.


Unique human view count system without captcha on Pay Per click system, using cryptographic proof of work I have a system that will be paying users per unique view on a page. I need to prevent 80% of fraudulent automated traffic from being counted. I need to avoid captcha.I would like to implement a client side proof of work system wherein I would send the page a small hash, the page would decrypt it, send it back with AJAX after a second or two, and then I count the view.

If I had a proof of work system, possible combined with IP monitoring and blacklisting, would this be suitable for preventing most of the fraudulent traffic?

My question is: would this work, cryptographically? What cryptographic work would be just as fast in the browser as it would be implemented in assembly or C/C++? (so that spammers would not just write a faster software to do that work in a fraction of the time) What cryptographic work would take only a second or two in the browser of a mobile phone?

Anything what the browser can do without human intervention can be automated. This might be done from outside by looking at the code or one might simply control the normal browser with Selenium or similar tools.

Since you will pay users for visiting the page the chances are high that somebody likes to earn easy money and will automate the visits.


C# Encrypting string in DES 3 CBC mode Is it normal that when I use Double DES secret key to encrypt a string in DES3 CBC mode then I always get the same cipher text? For testing I'm using IVC=0.

If you encrypt the same thing it is normal, if you encrypt something different it is not normal. In that case you have probably an error in your implementation.

A common error is to translate the encrypted result to string for transport, all non-readable bytes are then changed to "?" by .net.


Bitdefender Antivirus SSL Cert substitution I am using Bitdefender AV 2013 ed and I have noticed that when the Scan SSL is enabled in the configuration BD will use a local certificate, as mentioned here. This modifies the cert chain with BD as the trusted root on secured sites, or at least that's what you see. My questions are:

1) What is this kind of technology called?

2) What is actually taking place behind the scenes with cert validation?

3) Is BD masking the actual cert chain or does it actually substitute its own root for the site based on doing its own checks then tells the browser its "trusted"?

4) Is the presenting server involved in this process in any way or is it oblivious to what the client is doing?

Bitdefender is doing here a Man-in-the-Middle attack, except that it is not really an "attack" since you actually consent to it. Bitdefender impersonates you when it talks to the server, and impersonates the server when it talks to your browser. This requires Bitdefender to create on-the-fly a fake certificate for the target server; your browser is fooled by it because Bitdefender added its own CA certificate to the set of roots trusted by your browser. That CA is, really, operated by Bitdefender itself.

All of this occurs locally on your own computer. There are two SSL connections, one between your browser and the local Bitdefender process, and one between Bitdefender and the remove server. Bitdefender forwards data back and forth, and can see it all plainly, which is the point of the exercise.

The remote server is blissfully unaware of these shenanigans.


Yovo screenshot blocker vulnerability I was studying Yovo's screenshot blocker and I noticed that when watching their demo, I was easily able to pause the video when the screenshot blocker was taking effect and get a fairly clear view of the image that was supposed to be blured.

I know that the program works using the looking through a moving fan phenomena. I'm just wondering if it has a vulnerability of recording it at a lower frame rate and taking frames from the video or do you think this is just an issue with how they made this particular video?

Here's a link to the DEMO. I also attached an image with the screenshot.

It's supposed to have hexagonal pattern (blured) covering the circular region on the photo, but instead if I pause it while the effect is going on, I get this:

I believe this is due to frame blending, but I'm not sure. Please let me know your input.

P.S.: I don't have the app since my phone is too old, so let me know if you had any experience messing with the app since I haven't had a chance to.

It doesn't really prevent you from getting the image. It just makes it take more work. You could take several screenshots or a video and get all the clear pieces from the separate frames/pictures and stitch them back together.


Can a client prove to a third party that they sent a message to another client in a P2P network? Let's say Alice sends a message to Bob in their P2P chat app asking him to complete some work. Bob is lazy, so he deletes the message off his machine, does not complete the work, and just claims that he never received the message in the first place. Their boss needs to fire someone, but is unsure who is telling the truth.
Is there a way they could improve the chat app so that Alice could prove to her boss that she sent a message, assuming that Bob is completely uncooperative?

An interesting question, related to the topic of non-repudiation. In this case, the thing Bob wants to do is repudiate having ever received the message. Here's one way to build a system which is secure against that:
All members of the P2P network have a public/private key pair (this is useful for lots of other things too, like end-to-end encryption). For the purposes of this question, we'll assume that the public keys of Alice and Bob are known both to each other and to the boss.
To ensure non-repudiation of messages both sent and received, the P2P software/protocol is such that:

When a message is sent, the sender uses their private key to create a signature of the message, the timestamp, and a sequence number (unique identifier). These values and the resulting signature are transmitted along with the message itself. Now, the recipient can always prove that the sender sent the message and can't fake when it was sent.
When a message is received, the recipient signs the message (including the sender's signature, timestamp, sequence number, etc.) with their receipt timestamp, using their (recipient's) private key, and sends that signature back to the sender. Until the sender receives (and verifies) this countersignature from the recipient, the message is considered undelivered; the sender can see an indication of message state. Thus, if the sender ever sees that the message is delivered, they can prove that it showed up on the recipient's chat client, and when.
Both signatures and all their metadata, on every message, are stored in both clients.

Now, given these properties, let's look at how we might try to attack the system:

Alice uses a modified client that will sign a message and display it as being sent with the desired timestamp, even if no such message was sent. There's no way to prove that it wasn't sent at that time, either. However, because the message doesn't have a valid recipient signature, it'll be clear that the message wasn't ever received, and if Alice wasn't lying, she should have noticed that the message wasn't received and done something about that.
Bob uses a modified client that will let him see incoming messages without acknowledging receipt of them yet. Bob uses this to have messages that he wants to pretend he never saw just "silently fail" without ever sending the countersignature. However, in this case Alice will see that Bob's client "never received" the message, and will try to reach him some other way.
Bob uses a modified client that will make it look like the message arrived too late for him to act on it, by altering the timestamp. However, Alice has the original message receipt (countersignature), which has the timestamp of when the message was received. She (or her client) should notice if the receipt date is in the future. If it's not - that is, if Bob's copy is modified after the receipt is sent - then Alice still has a copy of the original receipt, with the original timestamp, signed with Bob's private key.
Alice, trying to make Bob look bad, crafts a fake message (that looks like it was sent but wasn't actually), and uses a modified client that displays the message as having been received. However, Alice doesn't have Bob's private key, so Alice's client can't produce a valid countersignature from Bob. When the boss looks at the messages that Alice supposedly sent, and tries to verify the supposed countersignature on Alice's message using Bob's public key, it will be revealed to be invalid.

Obviously, part of this system depends on people making sure that their messages are received. It's impossible to prove, for a message for which you have no countersignature, whether or not the recipient ever got it. So long as you get a countersignature, though, and the timestamp makes sense, either party can now prove that the message was exchanged, and when. Neither side can delete all proof of the exchange, or modify any detail, unilaterally; they would need to cooperate to fake anything.


Secure and private connection to GnuPG keyservers I wish to privately submit my public key (without it being sniffed on the internet). I found that I have 3 ways to connect to the keyserver securely:

https://<keyserver-url>
hkps://<keyserver-url> (HKP over TLS)
hkp://<keyserver-onion> [Using TOR]

Which one of the 3 is most secure? I'm surprised to find that the Tor keyservers only use  hkp and not hkps.
https keyservers are working with ipv4 to search and submit keys but it's hard to find hkps server working with ipv4.

Options 1 and 2 seem very similar, since both rely on the TLS protocol, so which is more secure will depend on the nature of the certificates (key size, supported algorithms) and the configuration of the servers (version support).
Tor on the other hand tries to protect the origin of the communication, so it adds an extra layer of protection to hide the address where the request comes from.
There was some paper explaining why TOR may be vulnerable if an observer has control of several routing AS, but in that case, the observer must have huge control of the network.
If you are the only one using TOR in your context, and your are trying to protect from some sniffer, TOR traffic may at least reveal some of your activity.


Any risks connecting to a Chinese printer? Ok, I fully admit this might be in the realm of paranoia, but hey, isn't that sort of the name of this game? :)
I'm staying in a hotel room and needed to buy a small, cheap laser printer for some printouts I need to do. After shopping far and wide, I decided the Pantum P2502W fit the bill perfectly- tiny footprint and more. But then the <paranoid|reasonably cautious> side of me started thinking- this is a Chinese company through and through. Sure, HP, Canon, and the like probably manufacture in China, but they're not Chinese companies at their core.
Anyway, perhaps this is all nuts. Perhaps a lowly printer literally can't do anything. But maybe it can (installing stuff- oh man, the drivers I just realized, or maybe saving info I'm sending to print, etc.) I'm no expert in this so wanted to check here.
There were also several (progressively less secure) layers of using it I wasn't sure about:

Simplest was going to be straight USB connection.
They also allow you to connect to it as a wireless hotspot to print (as opposed to it connecting to a local network for all devices to print). I guess at that point it has no internet connection so no worries?
There is some mobile app you can get to allow you to print from a mobile device. I assumed this was the least secure.

Well, I appreciate everyone's help. Perhaps this is nothing; perhaps I'm correct and I should return for a more established non-Chinese brand.

There are all sorts of possibilities. Yes, your printer can have a call-back mechanism, with a 5G GSM SIM. Yes, your drivers can send a copy of everything you print to the Chinese authorities via the Internet.
Is this likely? No. I would say: the cheaper the printer, the less likely.
Anyway, if  you want to be absolutely sure that nothing like this is even possible, you will want a printer of a different category. One that is evaluated  under the Common Criteria (https://www.commoncriteriaportal.org/products/ for a list). Be sure to read the evaluation criteria too.
Most cheap printers will be compatible with some standard and may not even need propriety printer drivers.
And is your data really such that your prints may not ever be seen by anybody? Do you really carry a P-7 shredder with you too?


Is there additional security value in using passwords with words or phrases in non-English languages? I was thinking about correct horse battery staple. I am not a native English speaker. In my language, the above could be written as:

vqrno kon bateriq telbod OR

вярно кон батерия телбод.

Keep in mind that the Latin variant can have several variations, depending on how I choose to represent the sounds from my language with English letters. This is, however, very easy for me to remember, as I do it consistently.

Roughly what would be the security value of the above two pass-phrases*?

*ignoring the fact that they are now published

It entirely depends on your attack model. A 16-character word is likely to resist brute-force, but might fail immediately against dictionary attacks. How do you define the strength of that password? There's no single answer.

With the scheme you mentioned, a brute-force attack would be largely infeasible assuming your password is long enough. Even then, it's entirely reliant on whether the attacker is targeting your particular Unicode range, or if they're just going for ASCII.

In general, attackers in the "low hanging fruit" model are likely to guess passwords only in the ASCII range, because they're the most common. When 30%+ of passwords are in the top 10k list, why bother doing anything fancy?

However, if you're worried about attackers who know your language and are actively attacking passwords using the same model as you used to create your password, then you might run into trouble. Even so, if your words are sufficiently randomly chosen, and one of them isn't strictly a dictionary word (e.g. a word like "pwned") then you may well be safe. It's quite difficult to judge the strength of passphrases, since their security is largely reliant on unknowns such as the dictionary in use and the potential for mutations.

The truth is that we don't really know if they're secure against in-the-wild attackers in general, because we don't have any solid statistics to back up our intuition. The best advice I can give you regarding non-English passwords is to assume that they were English, and ask yourself whether you'd still trust them.

For further reading, we have a few related questions on the site:

Password complexity policy for non-English passwords
Non-English password dictionaries


How much should I change my 64 character TrueCrypt password? I got a TrueCrypt container which is using a 64 character password. This password contains all the different kind of characters available to me (upper case, lower case, digits, special).  It's taken me a long while to remember this password, so I would not want to change it to a completely new password.

What I am protecting is nothing too important, at least for any agency such as NSA. It contains my own private information that I don't want anyone to read. I am more worried about family/friends getting into this container as well as identity thefts.

Now it's time to change password. I been thinking about changing a few characters in this password. I wonder, what's the minimum amount of characters I should change to make it secure enough? Changing it to a completely new password is not an option for me.

Why is now the time to change your password?

If your password has been compromised, then you really should create an entirely new one. Both character-level and semantic correlations between your old password and new password can reduce the attack space for a brute-force attack substantially. As others have pointed out, susceptibility to a brute force attack is really the only technical criteria you need to worry about when choosing passwords (of course, memorizability is another practical consideration).

If only part of your password has been compromised, and you're not storing any mission-critical information, then perhaps you can tolerate changing only a few characters, but you certainly are still more susceptible to a brute force attack.

If you're just performing some "spring cleaning" and want to refresh your password, think about whether the change is really necessary. If you think you're susceptible to a brute force attack, then you should change your password, but you'll probably need to change it pretty substantially to fix the flaw. Most brute force attack work by first targeting common passwords, and then modifying those common words with alterations (adding "!" to the end, substituting "@" for "a", etc...). Otherwise, if your password is otherwise secure and you've invested the time to memorize it, I don't see any reason to change it. That said, randomly changing a few characters of an otherwise-secure password shouldn't hurt you much, either.


Outlook Client and DKIM We have our domain email setup with SPF and DKIM - both which seem to be operating normally. When sending emails from webmail, DKIM (and SPF) are working correctly. We have some users using Outlook as an email client. When sending emails via Outlook it seems there is no DKIM or SPF "signature" in the emails. We've confirmed that all of the settings are correct for the server information in the account in Outlook.

Thank you

When the SPF is not validating, its clear that the mail are not going through your servers. Propably the end user has configured their client to mail through a ISP-owned "smarthost" that the ISP enforces.

Double check the client configuration and firewall settings, and ensure the mails are really reaching your relay SMTP.


SSL/TLS CipherSuite TLS_NULL_WITH_NULL_NULL CipherSuite TLS_NULL_WITH_NULL_NULL means no encryption no mac
Then why it is standardized?What for?
And popular browser and Server support it?

TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a TLS
  connection during the first handshake on that channel, but must not be
  negotiated, as it provides no more protection than an unsecured
  connection.

TLS_NULL_WITH_NULL_NULL (TLS 1.1) is used to check if TLS connections are possible, and to simulate a handshake. It can also be used to switch cipher suites, and indicates the start of a new TLS connection. IIRC it is not used much and will been removed later by TLS 1.3 draft.


What exactly is a key in cryptography? After researching and reading I am not sure if I completely understand it. To my knowledge, a key is a password used to decrypt a message. However, the confusion comes in when it comes to the public key, is the recipient putting in the password to receive the message?

Passwords are concerned with system access. They are used to verify that you are who you say you are (example: logging into email), or at least that you are someone that is allowed to access the resource you are trying to access (example: a code to open a door).

The important thing about passwords is that they are fed into a system, so extra measures like lockout (too many wrong attempts) or 2-factor verification (texting a code to your phone) can be implemented.

Keys, in the context of cryptography, are not passwords, they are used to change a message (plaintext) into an unreadable form (ciphertext). Think about it like this: you have an encryption machine. You feed your plaintext and your key into the machine and get scrambled letters and numbers out (the ciphertext). You secretly share your key with your friend, then you can send him your ciphertext, and it doesn't matter who sees it. Since your friend had the key, he gets your ciphertext and feeds it into his decryption machine along with his copy of your key, and the machine prints the original ciphertext.

This is a little more difficult to secure: there is a principal in cryptography that says you must assume that an enemy has intercepted the ciphertext and has a copy of the encryption and decryption machines. So he can try as many times as he's like to guess the key and there's nothing you can do to stop him.

The above describes a symmetric cryptosystem, where you kept the encryption key secret because the same key is used to both encrypt and decrypt the message (like locking a deadbolt on a door). This is different form asymmetric cryptosystems, in which the encryption key (the key used to lock the door) is different from the decryption key (the key used to unlock the door). This has the advantage that 2 parties don't need to secretly share the key before communicating. For example, I post to an online forum

"Bill, what's your address? - Please encrypt the answer using the encryption key 103234".

Now, Bill can encode his answer and post it for all to see, but because only the encryption key has been shared and I kept the private key to myself, so only I can decrypt it (not even Bill can decrypt it, even though he already knows the plaintext). Furthermore, now anyone can send me messages that only I can decrypt.

Note on terminology: an encryption-only key is usually called a "public key" since everyone can see it; a decryption-only  key is usually called a "private key" since you don't share it with anyone.

Technical note: while asymmetric cryptography seems superior, it is a LOT more computationally intensive (bad for, say, encrypting terabytes of info) compared to symmetric cryptography


Why do phones have SIM cards? I presume that the main reason phone operators require a SIM card to get access to the network is due to security and/or authentication purposes.

Just wondering why this is? What does a SIM card do that a phone can't? I imagine a SIM card is just data storage right for either some data or some algorithm that generates some data. And at the end of the day, you're just sending the network the right data to authenticate to them you are the owner of the account. Why can't this data just be generated and sent from an app on the phone?

Wouldn't it make more sense? Phone makers won't need to put in a SIM card slot, and phone networks suddenly become much more accessible because users don't need to organize to have a physical thing sent to them for every device they want connected to the network.

The SIM card, initially, is the root for the legal value. The operator wants to bill the user, and does not want users refusing to pay and claiming that they did not made these three-hours calls to Tanzania. Within the legal context of European countries, where GSM was designed, the SIM card was convenient: it could serve as a basis for legal proofs, under the idea that the SIM card cannot be cloned, and thus if the secret key contained in the SIM card was used then the actual card was used, and the owner could then be formally held responsible for the calls, and pay for it (and three hours to Tanzania imply a non-negligible amount of money).

It is plausible that the SIM card concept was pushed by some French lobbying, the "smart card" being a French speciality (and, at that time, was still patented by some French companies).

Another facet of the issue is that in Europe, you can unlock your phone. Operators are legally mandated to send phone owners an "unlock" code, no more than six months after buying the phone, so that users may then reuse the same hardware phone with another operator. There again, the SIM card is convenient. Compare with SIM-less phones in North America: there is no SIM, but the phone is hardwired (through its firmware) to a specific operator, and you cannot easily (or at all) repurpose the phone to another operator.

The SIM card thus incarnates the separation between the phone hardware and the contract with the operator.

So the "why ?" is, as usual, mostly a matter of History; GSM phones need a SIM card because GSM phones have always needed a SIM card. Yet there are at least semi-rational reasons why GSM phones have SIM cards, and SIM-less phones are not necessarily "better" than phones with SIM.


Any idea to prevent on this case of security breach on Windows 7 I'm using a Windows 7 64 PC in my company.

Today I found a strange username on the login screen. I checked and found some users' folders inside my Windows directory. Only my account from company domain and local admin can log in on this PC. The IT team and I discovered that someone from the weekend shift team cracked the local admin user (we think they use the infamous Hiren's boot tool). He also added a user group with all users from my company. So anyone can log in to the PC. And anyone is given admin permission so they can access all my files.

Some other guys took advantage and used my PC without permission. They're all gonna face the consequence later but the security hole is still there.

How can I prevent this case to happen? Or I have to deal with the fact Windows sucks and anyone can overwrite the admin's password.

First of all, lock the workstations down with a BIOS/UEFI password. This is common practice for enterprise networks. If the device is yours, then do it yourself. This prevents systems other than Windows from booting. Also make sure you disable the XPE network OS loader.

At this stage, you cannot be certain the computer is 'OK' from now on since it was easy to install remote services from a bootable USB/Hiren's/Linux based memory OS. Reinstall Windows would be your next action. Wipe the drive on installation.
If you do not own the device, then tell the same thing to your IT team since they should have been aware of these actions.

Before reinstalling Windows, you can take a look at the local event logs. This should give you some more info on when the accounts were created.

In addition to the above and comments below, you might also want to question the knowledge of the people who are responsible for security (or IT). Every system administrator should be fully aware of the danger that comes with unprotected access to configuration.


Is my JWT refresh plan secure? I plan on using JWT for my login system for mobile devices. There is no real standard workflow for refreshing JWT tokens I could find so I created this one below. The reason I want to use JWT is for performance reasons. Instead of checking if a user is valid with a database call for every single request I trust the JWT.

I have the proposed workflow which I want to implement into my app. Is this acceptablly secure? Efficient? Are there any obvious problems I am overseeing? What reasonable improvments can be made?

User logs in

If no HMAC signed token exists inside of localstorage, the user gives a name to the device.
DeviceName gets sent to the server where it is inserted into database.
JWT token + HMAC signed token of the DeviceName are sent back to user. The HMAC signed token is put in place to make sure the jwt token (containing DeviceName) is sent from the same device that called it originally.
JWT token is valid for X hours so a user can make any calls for X hours.
After X hours, the JWT is expired. When a request is made the server can see the JWT is expired. Server will now attempt to refresh the JWT token. Server checks the database to see if the DeviceName specified in the HMAC signed token is the same as a valid device name in the database for that user.
If so, create new JWT valid for another X hours, if no, send back message to require login.

If an account is compromised:

User can log into my password service. Once logged in, I would retrieve all the devices for that user, the user can then revoke their compromised device. Once this is done, a request to refresh the JWT will not work with the stolen token.

All of this of course happens over SSL.

My concerns which I have no solutions for:

If a JWT token is stolen the attacker has X hours to make calls based on the victim. I think this is the nature of tokens though and an accepted risk?
If the JWT is stolen, that means there is a good chance the HMAC token containing the device name is also hijacked so the user could refresh tokens until the victim realizes their account is compromised and revokes access. Is this accepted practice?

Acceptably secure within the realm of what?

You have described the basic flow for all bearer tokens. They who bear the token have the power. You do have a condition where you check if the token has been revoked, but that will mean the token is valid until they expire or are revoked. This is fundamentally the same as checking if the user is valid in the database, but you're replacing user with device + JWT. That's fine, but it's not much of a performance gain.

Other systems use two JWT's (or a JWT and an opaque token). The first JWT is your access token used mostly like you describe, but you don't check for revocation. This token is very short-lived -- maybe 20 min -> 1h, and then you have your refresh token which lives considerably longer. When your access token expires you send the refresh token and if the refresh token is still valid you issue a new access token. If the refresh token is expired you can force authentication again, or just issue a new access and refresh token.

The value here is that you only need to validate the refresh token against the database, and you only need to do that when the access token expires. When the user marks the refresh token as revoked then the refresh token doesn't get the attacker a new access token.

The trade off is that you don't query into the database as often, but the attacker can do whatever they want as long as the access token is valid. This is mitigated with using a very short lived token (its a game of odds). Whether this is an accepted risk is totally up to you. We don't dictate whether you should accept the risk. :)


Sql injection is not working on my site? I have set up a page and database so I can practice SQL injection. Ive tried some examples and it doesn't seem to work. It seems to add the username and password to that database, even though I input an Injection in the username field. Here is my code:

include "Connection.php";

<form method="post" action="sqltest.php">
<fieldset>
    Username:
    <input type="text" name="username"/>
    Password:
    <input type="password" name="passwd"/>

    <input type="submit" value="Submit" />
    <input type="reset" value="Clear" />
</fieldset>
</form>

$username = $_POST["username"];
$password = $_POST["passwd"];

if (!empty($_POST)){
if (empty($username) || !isset($username)) {
echo "Please enter a valid username";
   } else if (empty($password) || !isset($password)) {
echo "Please enter a valid password";
} else {
if (strlen($password) >= 6 && strlen($password) <= 8)
    {
        if (is_numeric($password))
        {
            echo "Password cannot be a number
";
        }
        else{
                $encrypted_mypassword=md5($password);
                $query =  "INSERT INTO sqltest (name,password) VALUES ('$username', '$password')";
                $result = mysqli_query($connection,$query);

                echo "You have successfully registered";
        }
    }
    else {
        echo "Password must be between 6 and 8 characters in length
";
    }

 }
}

Can anyone tell me some examples that would drop the table, or insert a user?
I just realized that its automatically escaping characters. Surely this doesn't prevent all SQL injection.
Is there anything i can inject that will overcome this?
Thanks!

In this particular example there's very little you could do, even if you hadn't magic_quotes.

That's because a SQL injection normally can only add to the query string. Since the string is an INSERT command, you can only INSERT something.

In theory, if the SQL server behind supported "chained commands", you could transform a command in two:

INSERT INTO ... VALUES ('...','...'); DROP TABLE Students; -- ');
                               |<--- injected code --------->|

But to do this, the original code must use mysqli_multi_query, not mysqli_query.

One thing you can do is to modify your script to show the query instead of executing it. So you can more easily check what's going on.

And one thing you could try with mysqli (which is why one should use prepared statements and bound parameters) is to play with encoding. Magic quotes will defang single quote marks, but can be thwarted by incorrect (and sometimes correct) UTF8 sequences, or double escapes.

Also, magic quotes is not perfect.

For example, if you tried with

username:      hello\
password:      ,XXX); --

and the query became

INSERT INTO sqltest (name,password) VALUES ('hello\', ',XXX);--')

that would really try and insert

username:      "hello', "
password:      XXX

Now XXX may not contain quotes nor ; . But it could contain a function, such as SLEEP(), which still allows some measure of "attack" against a site (it blocks a SQL connection).

In some circumstances you can build a string by using CONCAT and CHR: instead of 'foo' (contains quotes), you can use CONCAT(CHAR(102),CHAR(111),CHAR(111)) that does not.

It is also possible (but you need to be able to execute arbitrary statements, such as PREPARE and EXECUTE, not just hijacking an INSERT) to build a quoted query and execute it without using quotes:

PREPARE bobby FROM CONCAT(CHAR(68),CHAR(82),CHAR(79),CHAR(80),CHAR(32)...)
EXECUTE bobby; -- D,R,O,P, ,T,A,B,L,E, ,S,t,u,d,e,n,t,s,...


Does a Content Delivery Network (CDN) interrupt end-to-end security? Webserver -> CDN -> Users

From user perspective they reach the website via HTTPS.

Question:  How does this work?

Is the connection from Webserver to the users end-to-end encrypted?
Or the 3rd party CDN starts the encryption? Then could the CDN sniff the traffic?

A content delivery network must have access to the content, so it can optimize delivery through caching, compression etc. With true end-to-end encryption between the browser and the web server it is not possible that the CDN in between gets access to the content. Therefore the CDN itself must be that endpoint of the encryption, i.e. the connection is only secured between browser and CDN and the CDN has access to the unencrypted data from client and server. If the connection between CDN and server is then encrypted again or if is unencrypted depends on the setup and you will find both cases in practice.

Note that a load balancer is different from a CDN because it does not need access to the content. Therefore it can simply pass through the TLS connection to the server, so you get end-to-end security. But in practice load balancers are often combined with SSL offloading so that you don't have end-to-end security again. But since load balancers are (contrary to CDN) usually in the same local network as the servers this is not that much of a problem.


Can secret GET requests be brute forced? Say, I have on my server a page or folder which I want to be secret.

example.com/fdsafdsafdsfdsfdsafdrewrew.html

or

 example.com/fdsafdsafdsfdsfdsafdrewrewaa34532543432/admin/index.html

If the secret part of the path is quite long, can I assume that it's safe to have such a secret page or area, and it'll be hard to guess or brute force it?

What are the issues with this approach in general?

Note that I'm not asking how to do this right, but what could the issues with this approach be, if any.

You are essentially asking if it is safe to pass secret parameters in a GET request. This is actually classified as a vulnerability. It is not feasible to brute force a sufficiently long pseudorandom string, assuming the server simply returns a static 404 response whenever an invalid path is specified, but there are numerous other security issues in practice that make this a dangerous technique:

Logging software often logs GET requests in plaintext, but not POST.
Using GET makes CSRF trivial* when processing active content.
Referer headers may leak secret values to other websites.
Browser history will retain secrets passed in GET requests.

Your second example has /admin/ in it. This implies to me that knowledge of this path alone would be sufficient to authenticate to the server in an administrator context. This is very insecure and should not be done anymore than /?password=hunter2, a major web security faux pas.

Instead, secrets should be sent in a POST request. If this is not possible to do or if your threat model is exclusively to prevent brute force of the URL (for example, password reset links which are promptly invalidated after they are used), then it should be safe if done carefully. I am not aware of any side-channel attacks that would provide a method to obtain the string faster than brute force.

* Avoiding parameterized GET requests does not prevent CSRF attacks, which is a common misconception as there are various ways to similarly abuse POST (fake forms, etc), but passing secrets in GET does make CSRF easier.


Hashed password storage with random salt Ever since I've been making sites that require a user to log in with a username and password I've always kept the passwords somewhat secure by storing them in my database hashed with a salt phrase. Well just recently I read it is bad practice to use a single static salt word. Instead you should use a random salt for each user.

I under stand generating a random salt word for each user. But my question is, if you have to store the random salt also in your database so you can use it to cross reference it later to check the users inputted password when they log in. Doesn't that make it just as easy if usernames and passwords are stolen from your database then wouldn't they have just as much access to the random salt values as well? Seems like that extra layer of security doesn't really add much to the equation.

Or am I going about this all wrong?

It does add one significant thing.  If they steal the database, they have the username, per-user random salt, and hashed password.  But they still don't have the original password.  To reverse the hash, they will generally have to do a significant amount of separate work for each user.

Without any salt (a very bad idea, as LinkedIn learned), attackers can use pre-existing rainbow tables and have no per-user work for hashes that benefit from the tables.  Even if no part of the hash is in the table, they can pool work (e.g. if a user has two accounts with the same obscure password).

With a per-site salt, they can generate a rainbow table for the site, and still share work between users.

Remember that if they do crack a user's password, besides being able to log in to your site, they can probably also log in to other sites the user uses.


ASP.NET SqlDataSource injection risk I have an internal website (going on the intranet) that is going to go through vigorous testing to make sure that it is secure, so I am battening down the hatches so to speak and I coded a .NET repeater to Bind to a .NET SqlDatasource in the aspx page, not in the code behind. I use the SelectParameters tags to insert the string that is needed from a text box in order to run the query.

I am wondering just how safe this is from SQL Injection and other vulnerabilities.

 <asp:SqlDataSource ID="DataGetAppServer" runat="server" ConnectionString="<%$ ConnectionStrings:testConn %>"
     SelectCommand="SELECT [Server] FROM [ServerTracking] WHERE ([UserName] = @UserName)">
     <SelectParameters>
         <asp:ControlParameter ControlID="txtUser" Name="UserName" PropertyName="Text" Type="String" />
     </SelectParameters>
 </asp:SqlDataSource>

Do I need to do more for this?

It is safe.  You have used SqlParameters so you don't need to worry about SQLi in this case.

There are situations where using parameters might not protect you from SQLi, like using a parameter to construct dynamic SQL in a stored proc, but there isn't anything like that going on here.

This is a textbook example of when parameterization prevents injection.


Generate C File Stream Object on remote machine without fopen() Let's say we have an elf a and a textfile a.txt in the same directory.
The a elf is a program, that is remotely accessible/executable.
In addition a contains the instruction fgets(buf,len,stdin); and a remote attacker manages to get full control over the stdin object. Is the attacker able to reliably generate a file stream object pointing to a.txt? It should be the equivalent to the object generated by fopen("a.txt","r");. If yes, how would he do that?

If by "full control over the stdin object" you mean provide stdin input to a, then this depends on the size and location of buf, the memory layout of a, and what len is. In this case, the way you pose your question does not provide enough information to answer this.
If you mean corrupting the pointers in the struct FILE, then yes, usually it is possible. Unless the file descriptor of a.txt is already present in the target process, it's unfortunately not as easy as overwriting the file descriptor and clearing the buffers in the struct FILE. It is however usually possible to gain arbitrary code execution by overwriting the stream buffer pointers and writing to stdin, which gives you a write-what-where primitive. The precise overwrite targets again depend on the target executable.
For a detailed discussion of a similar exploit technique, see the "Play with FILE structure" HITBGSEC 18 talk (video/slides/whitepaper).


Intercept HTTPS traffic.. with a cert So I am working with Charles proxy server, I understand I can decrypt HTTPS traffic, if the user accepts the invalid cert warning on the browser or trusts charles as a root CA.

However what I have is, a real verisign cert, and private key off another server I own. So if I install that, technically the cert should be trusted by all clients already.

The problem I have after installing the cert into charles, is I still see the cert error on the client.

For example goign to facebook.com i see
issued to: *.facebook.com (fine)
issued by: xyz.com

(where xyz.com is the fqdn I got the cert off) Am I doing something wrong here?? Will this work?

It's doing exactly as it's designed to do. The Facebook Cert is designed to allow trusted connections only to domain names for Facebook. Your personal Cert is designed only to work for that personal domain. Just because you have a valid Cert doesn't allow you to spoof any domain you wish.


What are the risks of antivirus exclusions for virtual machines’ files? For performance reasons, I would like to whitelist the following files from an AV protection:

.vmdk (VMWare virtual disk file);
.lck (VMWare lock file for disk consistency, created in the same directory as the .vmdk file);
.vmsn (Virtual machine snapshot file);
.vmem (Virtual Machine memory snapshot, made during snapshot creation while the machine is powered on).

Would there be any negative effects of excluding these files from runtime protection on employees’ workstations (not production or testing environments; only PCs)?

I believe that the risk is pretty low, but I would like to double check it.

I can think of the following points:

A malicious file could be stored using these extension. It is not impossible for your hypervisor to contain a bug that could lead to an exploit once a crated storage file is loaded. Potentially, your AV could be made able to detect such a problematic file before you have the time to patch your hypervisor, reducing your window of vulnerability.
Your AV might be able to understand the format of these files and look into them for potentially harmful files. I'm not aware of any product that does that but I haven't looked very far (and I'm not overly interested by such a "feature").
It is possible that the AV heuristic engine could actually detect some form of malware directly in the files while they aren't in use (most likely shellcode).
Depending on how your AV works, if the files are stored on an NTFS file system, a malicious file could be stored as an alternate data stream for one of these files then the AV might also skip the ADS linked to the excluded file.

IMNSHO, I think that the above risks are well worth taking given the high performance cost of on-access scan of VM files (which tends to be huge).


What risks are there with a Bluetooth based door lock, and are there any mitigations? There are a few interesting Bluetooth door locks on the market that use version Bluetooth 4.0 however there seems to be a few issues with this

E0 Encryption flaws
Risks during pairing
Attacks unique to operating environment (temperature, installation, nearby RF)
I'm opening up my mobile device to various Bluetooth attacks

.. and to top it off I believe it's possible to "war drive" and locate these locks of interest without being physically close to the lock.

My question is; are these risks reasonable for me to consider?  ...or am I being prudent in not using Bluetooth locks on a home I'd rather keep low-profile.

The convenience factors are very intriguing but I want to make sure I fully understand the risks before installing it.

Very interesting Technology Indeed

If the technology is designed, developed and safely, then it can be fairly secure. It seems to provide a lot of cool features.

Configure keys to access house centrally on "App".
Deploy "Key" to person as needed and for agreed timeframes and without physical delivery.
Decommissioning keys as needed.
Many keys possible, named and configured and reported.
Bluetooth wardriving might be possible, but can be minimised/eliminated by system provider.

BUT: It introduces additional risks

The Key System provider has full control and access to your home.
The Key System provider must stay in business to continue to use the locks.
Internet access can be actively disrupted and stop certain features from working (wipe/disable of keys)
Design bugs in the system (not enough information on site to tell).
Implementation bugs in the system, includes their web systems (may allow complete access to attacker).
If important: Government can access your home surreptitiously.
Denial of Access to home: System fault or bluetooth radio could stop ingress or worse egress from house (Think about how you would access you home if the key system was inoperative, remember that the key will not be pickable by a locksmith).
Remote or physical compromise of any phone with keys could compromise your house.


Does visiting cached pages disclose my IP address to site admin? I know it discloses my IP to Google,
but is my IP also disclosed to the owner of the site of which Google made cached pages that I'm looking at?

And how about anything I do within the cached page - like copying a URL or email address off it (by just holding down or right clicking on the blue hypertext to copy, and not clicking that would open the URL or activate Email application!) - does that give my IP to the original site?

The cached page still contains references to the original content (images, scripts and style-sheet files, etc.) so, when you look at the default cached page, your browser will request this content to the original website, possibly along with a "referer" header telling explicitely to the website that you are currently viewing the Google cached version of which page.

However Google offers you the alternative to see the "Text-only version" of the cached page. By this way all these tags linking to the original content will be stripped off and your browser will contact only Google servers.

And as per you second question, all your interaction with the text-only version of the cached page will remain local to your browser: you can right-click, select, copy, save or examine the source code of the whole web page or a some elements of them freely.

Foot note: the above statement is true for a "normal" behaving browser and environment. Some browser plugins and antivirus proactively check the links contained on a webpage displayed in the browser without the user having to click on them (use case can range from checking the URL reputation to actually downloading the web page to accelerate navigation). You should know if your system has got such feature installed on it. In case of doubt, a simple test with a network monitoring tool like Wireshark would tell.


What are the arguments for and against having anti-virus on domain servers I have been hired at a start-up where I seem to have become the de-facto admin despite being hired to do application support (to be fair I do have a background as an all-rounder).

Amongst the interesting things I have found is a lack on anti-virus on the domain's Microsoft servers the argument being that they are not the point on ingress therefore as long as all the ingress point are covered, protection for them is not needed.

Whilst my knee-jerk reaction is too blanket install (eset in our case) across all of machines, it got me thinking, what is my justification for the licence and performance cost?

Some people argue that installing an antivirus would in fact increase the system attack surface because to the vulnerabilities of the OS, you now have to add the vulnerabilities of the antivirus.

Another common argument is that antivirus could reduce system performance and stability.

In my opinion, these arguments are valid and true but you have to balance these facts with the increased security you could gain installing an antivirus.

How an antivirus can effectively increase the security of a domain controller?

In my opinion, if you implement and mantain good security practices you don't need an antivirus but cause this is difficult, installing an antivirus will cover you in some cases.


Scapy: Sending forged Probe Requests and capturing them in a different device Objective:

Sending a forged Probe Request frame from one machine and capturing it on a second machine.

I have two codes running:

sender.py

interface = sys.argv[1]

dot11 = Dot11(addr1='ff:ff:ff:ff:ff:ff', addr2='11:11:11:11:11:11', addr3='ff:ff:ff:ff:ff:ff')
probeReq = Dot11ProbeReq()
dot11elt = Dot11Elt()

frame = RadioTap()/dot11/probeReq/dot11elt
sendp(frame, iface=interface)

receiver.py

interface = sys.argv[1]

def packetHandler(pkt):
    if(pkt.haslayer(RadioTap) and pkt.haslayer(Dot11)):
        dot11 = pkt.getlayer(Dot11)
        if(dot11.addr2 == "11:11:11:11:11:11"):
            rssi = str(radiotap.dBm_AntSignal)
            print("Received Probe Request with rssi = " + rssi)
while True:
    sniff(iface=interface, prn=packetHandler, store=0)

Problem:

The receiver don't always gets the packets.

When I use the loop=1 parameter on sendp() it usually takes around 5k sent packets until the receiver catches a single one.

I've used wireshark to ensure that all Probe Requests are being sent, however, my receiver program seems to ignore most of them, is this a normal behaviour for scapy? Am I doing something wrong?

It appears the code you are using doesn't check or set the wireless channel for either transmitter or receiver. If they are not on the same channel, they cannot communicate.

Since you have success some of the time, there could be other daemons that are hopping channels (e.g. scanning for available networks). For your code to work, you will need to kill other daemons that are using your wireless card, and force the channel with:

iw dev <interface_name> set channel <channel>

The airmon-ng utility can print out processes that may be using your wireless card.


Is it OK to seal data to TPM SRK directly? In reviewing various TPM programs and libraries, I have noticed that
when sealing data to the TPM, a new key is always created (wrapped by
the SRK), and that new key is loaded and used in the seal operation.  When unsealing,
the sub-key must first be loaded (unwrapped) before the unseal operation
can be performed.

Is it necessary to create a new key for each sealing operation, or
can the SRK be used directly to seal data?  If it is necessary, what are
the security and/or practical reasons why it is necessary?

In theory, it is possible as a sealing operation needs a Storage Key, and a SRK is a Storage Key. In pratice, it is not implemented as usually the SRK is given the WKS(Well-known-Secret = 20 bytes of 0x0) or an empty password, so concerning the security dimension, it is not a good idea.

EDIT: I just checked in TrouSerS, tpm_sealdata creates a key withkeyCreateKey which calls Tspi_Key_CreateKey which needs a wrapping key. tpm_sealdata calls keyCreateKey with the SRK. So if you use TPM 1.2 and TrouSerS, you need a wrapper, and this wrapper is the SRK. I don’t know how it is done for the TPM 2.0