does using a long delimiter multiple times degrade encryption security? I need to condense multiple distinct pieces of data into a single encrypted string that can be decrypted and separated out later.

Before encrypting, I need to separate the data with some kind of delimiter that will never be confused with the data.

I have chosen to use a single, constant 20 character hexadecimal delimiter. For example:

data_piece
data_item
data_obj

becomes

data_piece214c1a16bb5236e7090cdata_item214c1a16bb5236e7090cdata_obj

which then becomes

vjXC4Xd7LU6aZX4QClZkU330XT39hnoLoQYIFNov39tPX96OKsid7mOBHwoVb4KspyvMpVPrsfHCUd1zbzXyETtgW5yF4b0oaK8Q%2FZCZN2XBvbfL3vooD%2FDLOza3%2FSrSNNzIW8oALZhv08LBzeg3DvgUgC8fg0xv4%2BCAEIQLIhM%3D

after running it through a standard Rijndael encryption algorithm with a 256 bit key and a url encoder.

Does this repetition of a single delimiter degenerate the security of the encryption if there are occasions when it may be used two dozen times? If so, should I use an array of unique delimiters so that they are never repeated within the same string, or does the difference really not matter for practical encryption purposes?

UPDATE:

The reason I chose to use a long delimiter instead of a small one is for cases like this:

delimiter = |
data1 = mydata\\\\
data2 = \|\|\|data

unescaped: mydata\\\\|\|\|\|data

escaped: mydata\\\\\\\\|\\\|\\\|\\\|data

writing code to unescape that and separate it out is not very straightforward. It is possible to do, but there will have to be a loop that continually looks for an end to sequence of escape characters preceding the delimiter, then unescapes it only if the number of escape characters in the sequence is odd.

Since this involves checks before every unescape function, I thought a long delimiter was better, because it can be practically guaranteed to never occur in the data, and allows the separation process to be as simple as possible.

You are supplying what is known as a "crib". If you use a long sequence, especially at the beginning, you are losing some (albeit very little) security.

You can easily mitigate the problem by using a random string, as long as you are able to recover it. For example you might use a 20-byte random string. You know that the first 20 bytes are the delimiter, and look for that in the rest of the string. This still supplies a check for a brute force attacker to determine whether he has found the correct decryption, but the brute force itself should be unwieldy enough that this little help is of almost no use. He still has to decrypt a sizeable portion of the ciphertext before running the test. Compared to only decrypting the crib section, it's an improvement.

You can also use a short, escaped delimiter. Instead of "betting" (with astronomical chances in your favour) that the delimiter will never come up "passively" in the text, you actively endeavour for it to not come up by replacing it or escaping it. For example you can escape all "\" and "|", then decide that a single "|" will represent a delimiter. The chances of a unescaped "|" in a incorrectly decoded ciphertext are astronomical, which makes cribbing worthless for an attacker. At the same time, your escaping naked "|"'s guarantees you that no naked "|"'s will occur in your plaintext. On the other hand this requires one additional stage:

 plain|text\nand --> plain\|text\\nand|another text --> ....
 another text

If you choose a delimiting character that's usually -escaped, such as maybe $, you can do this with several standard libraries and commands in various languages.

Updates

As for security: the random delimiter at the beginning does not decrease security by being at the beginning: since it's random, it cannot be used as a crib. The decrease in security comes from the fact that the delimiter will occur several times in the decrypted text, thereby supplying a confirmation that it is indeed the correctly decrypted text. (If the delimiter is short, chances of it occurring naturally in a incorrect text are not negligible, therefore its occurrence is not a confirmation. And of course its non-occurence can't be a confirmation either). The delimiter has to occur at the beginning because that's the only way you have (the delimiter being random...) of knowing yourself what the delimiter is. Every ciphertext will have its own.

Space considerations

TL;DR unless you have many chunks and/or very short, delimiters are probably the way to go to save space.

In general, you will have enough knowledge of the incoming data to choose an infrequent character as delimiter and as escape character, or at the very least, you will rarely have "pathological" plaintexts. To squeeze to the utmost the data, you can in theory write a function that will (a) determine the two less often used characters in any given plaintext, and (b) use them as delimiter and escape. At most, these characters will occur 3 times every 256 characters. All of them need escaping and will make 256 characters grow to 259, which is a 1.2% increase in size. Also, you will need to store these two characters e.g. at the beginning in order to know how to unescape the string. So we have a fixed overhead of two bytes, a size-overhead of 1.2% and a delimiter overhead of 1:1; if L is the total length of the message and N is the number of chunks, the plaintext thus treated will grow to be 1.012*L+N+2.

Using a delimiter and an unescaped plaintext of length L bytes, the probability of a sequence of length D occurring at position x is (1/256)^D and there are (L-D+1) possible values for x. So the probability of D not occurring anywhere is 1-(1-(1/(256^D)))^(L-D+1).

(Or =(1-POWER((1-POWER(1/256,$D$1)),A2-$D$1+1))*1000000 if you want to get it into a Google spreadsheet and calculate collision probability in millionths).

For a sequence of chunks 16K in size, to be sure to have a Pcoll < 1/million I need at least a delimiter length of 5 (which is overkill; but 4 is too short, giving a Pcoll of around 4/1000000).

So four chunks of 4K each would require 1.012*16384+4+2 = 16586 bytes with escaping and 16384+4*5 without, i.e., delimiters allow a saving of about 182 bytes (with a probability of the delimiter occurring by chance of less than one in a million), and 178 bytes if you use a 6-character delimiter (chances of less than one in a billion, or one thousandth as before).

We hit parity when 1.012*16384+N+2 = 16384+N*5, i.e. when you have more than 50 chunks (or 38 chunks if you use six-char delimiters).

PHP

Working in PHP I think you might find it advantageous a sequence like:

serialize (you obtain a string with all your chunks)
gzcompress (you save space, and get a maximum-entropy block of data)
encrypt

Bruteforcing the first AES block will allow verifying whether the decryption key is correct (the beginning of the gzcompressed serialized object may act as a crib), but doing this in the first place (and weeding out the false positives) is still computationally unfeasible. It would still be cheaper to beat the key out of you. And the implementation and maintainability advantages are worthy of the risk.


IMEI or IP being recognised? Can a website see my IMEI number? I have been banned from a website for multiple accounts, although I always cleared cookies, disconnected and reconnected from "the cloud" which gives me a different IP address every time. How do they know?

Cookies are not the only persistent mechanism they may be using.  Flash LSO, HTML5's Local Storage are two that come to mind...


Where does authenticity fit into the CIA Triad? Consider a chat application where an attacker is able to send messages in any user's name. This obviously violates the message's authenticity. But what aspect of CIA would be violated?

Integrity seems closest to me but that usually means that data must not be changed.

I support David's view that if you had to fit your scenario into one of the CIA categories, integrity would be the appropriate one because you're creating an unintended state thus violating integrity.

But also have a look at the Parkerian hexad which is a popular extension of the CIA triad. It consists of the attributes confidentiality, possession or control, integrity, authenticity, availability and utility. In this model, writing messages in the name of  another user would fit into the authenticity category.

Also, you might want to think of the CIA triad mainly as overall security goals. But it's not necessarily a powerful tool to classify specific vulnerabilities.


Which kind of Wifi is safe to use ? I travel a lot, so I most of the time get Wifi from Hotel or Cafes.
I payed attention to the fact that some Wifi does not have security password !
Here is a screenshot of the type of security I found :

I usually trust WPA2 Personnel.

Please, I have heard that it is possible to "sniff" the network packets if the hacker is on the same network. not sure if it is true. So I asked this question to get to know more about the best practices concerning Wifi: do I connect to only WPA2 Personnel ? What is WPA ? is there small utility application that allow me to check the information about the surrounding Wifi .... on macosx ?

WPA is the authentication and encryption system preventing people not knowing the right password to access a Wifi network. However, no matter if it is WPA2 protected or not, you may legitimately not trust Wifi networks from hotels and other public places.

The usual advice in such condition is to use a VPN. It is an application which will build a secured tunnel from your PC to the remote VPN server, ensuring that no matter the Wifi security level your connection will remain secure (no other Wifi user will be able to either sniff or alter your communication).

There are a lot of companies offering such service:

Price varying free to a few dozen of dollars,
Service varying from giving you only parameters values to providing you a full fledged automated software allowing you to use the VPN with no technical knowledge (the price pay such service, but also speed: cheapest server may be slower),
Various VPN servers location around the world. For your use, I would recommend a VPN server in the same country as yours since it will limit the speed loss (by making your traffic make a detour to the VPN server it will be obviously slower than direct one, however the nearest the VPN server is, the less significant the difference would be).


Is it a good idea to test a live company website as part of an interview process? I got an interview task, which is to pentest the careers section of a company's website. I'm keen to play around with any website, and permission was given but this feels like a free pentest. I imagine that other candidates will perform a similar task, but is it a good idea?

A lot of companies are giving challenges as part of the interview process these days, mostly on sample apps, I've never heard of testing on a live site as part of an interview.

Do you have a paper trail? Is there an email from someone at a high level approving of this? If not I'd ask for an email from someone at the director level or higher that indicates you have permission. Then agree on a time and have everything in writing.

Are they looking for a free pen test? Maybe, but oh man is that shady if true.


CSRF tokens in file that we can upload a file I am dealing with a website vulnerable to CSRF. Let's say that the page (upload.php) has the following code
if (isset($file_submit)) {
      //submit_file()
 }
 else {
     show_submission_form()
   }

 submission_form()
 {
     $tool_content .= <<<cData
     <form enctype="multipart/form-data" action="upload.php" method="post"  onsubmit="return
     checkForm(this)">

        ${langWorkFile}:
        <input type="file" name="userfile" class="FormData_InputText" />

        ${m['comments']}:
        <textarea name="stud_comments" rows="5" cols="55" class="FormData_InputText">
        </textarea>

        &nbsp;
        <input type="submit" value="${langSubmit}" name="file_submit" />
$langNotice3

     </form>
cData;
 }

In order to protect it I should use CSRF tokens and so I have change the code into this:
  if (isset($submit)) {
      if ($_REQUEST['token_form'] != $_SESSION['token']) {
        die;
      }
      //submit_file()
 }
 else {
     show_submission_form()
   }

 submission_form()
 {
     $tool_content .= <<<cData
     <form enctype="multipart/form-data" action="upload.php" method="post"  onsubmit="return
     checkForm(this)">

        ${langWorkFile}:
        <input type="file" name="userfile" class="FormData_InputText" />

        ${m['comments']}:
        <textarea name="stud_comments" rows="5" cols="55" class="FormData_InputText">
        </textarea>

        &nbsp;
        <input type="submit" value="${langSubmit}" name="file_submit" />
$langNotice3

     </form>
cData;
$tool_content .= "<input class='FormData_InputText' type=\"text\" size=\"40\" name=\"token_form\" value=\"$_SESSION['token']\">	";
 }

In simpler words I have added
  if ($_REQUEST['token_form'] != $_SESSION['token']) {
    die;
  }

and
$tool_content .= "<input class='FormData_InputText' type=\"text\" size=\"40\" name=\"token_form\" value=\"$_SESSION['token']\">	";

at the end.
This creates a form that its value is the token (I will make it hidden) and when the user presses submits the token is supposed to be send. However, if ($_REQUEST['token_form'] != $_SESSION['token']) seems to be true and so I can't achieve my goal. Do you have ideas why and how I can fix it? Thanks in advance!

The <input /> should be inside the <form></form>.
As the <input name="token_form" /> is currently outside the <form></form>, the token is not sent when you submit the form.


Replacing revoked SSL with a new cert but domain still showing old revoked cert I bought and installed a SSL cert for my domain but then changed my mind and canceled the purchase and bought a slightly cheaper one. The old cert is then revoked and I proceed to install the new cert.

Here is when things got worse. The domain still showing old revoked SSL and that makes my site couldn't be loaded on Firefox or any browser which are using OCSP. I tried reinstalling the new cert and even reissue it but to no avail.

Can anyone tell me how exactly can I purge the old revoked cert from getting in a way of the new cert? I believed this has caused downtime to my site.

Is this an issue with SSL provider or server side? The hosting company kept bouncing this and blaming SSL provider while the other one pointed me to the hosting company.

Very simple solution for such issue is just redirect all https request to http using 301  and visa versa.

this will refresh browser and server ssl caching.

hope this will help.


Is there a supported way to run a custom log export script at boot time in Checkpoint's Gaia OS? Specifically, we're using fwm logexport piped to logger to dump the audit logs in real time via syslog to our SEIM.  It works great if the command is run manually (in the background) from the "expert" command line, but then we have to remember to go back in and re-start it after a reboot.

The "Job Scheduler" allows for running a job at startup time, but it doesn't allow you to enter multiple commands connected with a pipe, and it turns out that its "@startup" happens too early in the boot process for this use (before all the CP processes have started).

Gaia tends to overwrite settings that are made outside of the configuration tools, but I don't know how extensive that is, so I'm hoping there's an official place for custom scripts that won't get purged.

You should check article sk87560 from Check Point, it explains a supported way how to syslog to external server. Here is a shortened explanation.

Gaia OS logs to syslog server:

HostName> add syslog log-remote-address <IP_Address> level info
HostName> show syslog all
HostName> save config

Check Point firewall logs to syslog server:
(in expert mode)

[Expert@HostName]# vi /etc/rc.d/init.d/cpboot

add row to the end

 fw log -f -t -n -l  2> /dev/null | awk 'NF' | logger -p local4.info -t CP_FireWall &

So in that sense /etc/rc.d/init.d/cpboot should work for your purposes, remember to add & to the end or you might get problems with the booting process.


Malicious payload in media file content As with anything to do with software, there have been many documented security vulnerabilities that relate to media files. While many of these exploits take advantage of attributes or variables of specific files types, such as metadata or comments associated with a file, my question is this:
Is it possible for a maliciously crafted media file (e.g. image or audio file) to contain its malicious payload not in the specific metadata of a file type but in the raw media data of the file itself, regardless of format?
For example, let's say that a malicious image file contains a specific sequence of pixels with specific RGB values that are parsed by an appropriate library and execute attacker code. Could this possibly constitute an attack vector?

...  that are parsed by an appropriate library

Can one create such an appropriate library which will look for payload inside arbitrary images (not only metadata), extract and execute it? Yes, this is possible.
Will a "normal" library behave this way? No, it will not. It might have specific vulnerabilities which can be triggered by interpreting the image in the wrong way, i.e. making wrong assumptions about needed buffer sizes, value of parameters in image etc. This is only about metadata but about the encoded pixels themselves, especially if compression is involved - like in CVE-2020-1895.
But a universal vulnerability, which can be attacked regardless of image format, is very very unlikely to happen by accident. It could be part of a deliberately placed backdoor though. Or it could be a way to hide a more complex second stage payload which gets retrieved and executed by a small initial attack payload.


Secure way to store Userdata without encrypting the Database I'm looking for a way or best practise to store Userdata securely in a Database without encrypting the Database.

We’re talking about an Application Server connected to a Database-server. My approach was to encrypt the userdata at the Application Server(How?) and store the encrypted Data in the Database Server. If a User authenticates himself at the Application Server the encrypted Data has to be read from the App-Server, decrypted and served to the User...

Update: It's mandatory that the App-server can decrypt the userdata (for example name, surname, blood type, products they bought, other personal data, Not talking about passwords here) because the App-Server has to decrypt the stored data in the database to present the data to the customer.

Are there any tools/best practises for this scenario?

I guess a fully encrypted Database might be the better solution but are there any ways to secure this environment without fully encrypting the database?

Update

I'll try to clarify the Usecase:

The Customer is running a Website where Users log in with their credentials (Username/Password). Appserver is tomcat, database is oracle afaik. There are no legal requirements (no PCI, Sox, HIPAA, etc.) involved for the stored data, however the customer wants to protect the data by encrypting it. The customer doesn’t want to encrypt the database because of license issues,  performance issues, and the "issue" that the database admins might be able to decrypt the database... therefore the data has to be encrypted at the application server and then sent to the database server.

The software architects want to go with the Security by obscurity approach and develop their own "encrypting" technique (maybe rot14 or whatever :) ) and implement it at the application server layer. The customer is fully aware of the fact that all the Software architects might now be able to read the encrypted data stored in the Database but thats fine to him...

The use case is still a little merky, but here are some thoughts I have reading through the above so far.

Is it a requirement that the application does the decoding, or is the requirement that encryption not be performed in the database? You can have a intermediary server encrypt/decrypt or use a hardware security module, etc.
Assuming that its not a requirement that the web application owner needs read access, you may be able to do a private-key encryption of the sensitive data (obviously not on child-parent table references and such). It's a pain, but its possible to assign end-users certificates for login and authentication and I believe you may be able to leverage that for encryption.
If you just want data encrypted in storage and have reasonable trust of your developers (you shouldn't) you can have the application use its own private key for encryption in the application of the sensitive data and encrypt it before storing it in the database. You would also need to figure out how to protect the private key. You may be able to use a hardware module here as well.

Also, even if the organization doesn't think they have HIPAA requirements, it sure does sound like that. They might be a  "business associate", which could still have some HIPAA implications. I would also wonder about the business model where they have a boat-load of data but don't want the ability to aggregate or data-mine; you can use all sorts of pseudonym referneces to tie things together at the individual level for a per-person processing (e.g., query all my blood test rows and do the aggregation when I load the page). Has the organization considered the impact of doing encryption at the application level, or perhaps this is only for a few key pieces of data?


How can I test that I have correctly disabled unnecessary HTTP methods? I am making a web-based application and I disabled some of the HTTP methods which are not necessary for the website (specifically, OPTIONS, HEAD and TRACE).

I put this in the httpd.conf of my xampp to test whether this works:

RewriteEngine On
RewriteCond %{REQUEST_METHOD} !^(GET|POST|PUT)
RewriteRule .* - [R=405,L]

How would I know whether they really are deactivated? How can I test that this setting is working properly? I am new to server-side administration.

@Owen nailed it, but just to show an example of doing it yourself:

$ telnet localhost 80
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
TRACE / HTTP/1.0

HTTP/1.1 405 Method Not Allowed
Date: Tue, 19 Nov 2013 12:11:40 GMT
Server: Apache/2.2.22 (Linux/SUSE)
Vary: accept-language,accept-charset
Accept-Ranges: bytes
Connection: close
Content-Type: text/html; charset=iso-8859-1
Content-Language: en
Expires: Tue, 19 Nov 2013 12:11:40 GMT

The TRACE / HTTP/1.0 is what you type, followed by two newlines.  The first line of the response (405 Method Not Allowed) tells you that the web server doesn't accept TRACE.

Knowing how to form a request of the different methods can be difficult if you don't already know HTTP; the OWASP project has some examples on how to Test HTTP Methods which can help you.


SQL injection Are there any instances where a vulnerable url would not contain an 'equals' (=) symbol I have a question I'm hoping you could help with?

I am looking to filter/grep a very long list of spidered url's from my site to only get the url's that could possibly be vulnerable to sql injection.

My question:
Is it true to say that any urls that could potentially be vulnerable to sql injection always contain an 'equals' (=) symbol in the url?

Therefore, if I was to grep for all the url's that contain an '=' symbol in the url, would I miss any other url's that do not contain an '=' symbol that could still be vulnerable?

For example these all contain an '=' symbol and could potentially be vulnerable to sql injection.

http://[website]/index.php?itemid=10
http://www.[yoursite].org/site/page.asp?CID=72&DID=
http://www.[mysite].com/site/page.asp?=

Are there any instances where url's do not contain an '=' and are still vulnerable to sql injection?

-------EDIT-------

I am ONLY interested in altering/injecting the URL in my browsers URL bar to see if any URLS in my list are potentially vulnerable to sql injection (i.e not interested in injecting forms or POST requests and so on yet).

I have a list of URLS in a txt file

FILE.txt

http://www.[site].com/index.php?itemid=10
http://www.[site].com/
http://www.[site].com/site/page.asp?CID=72&DID=
http://www.[site].com/animals/pictures
http://www.[site].com/pictures
http://www.[site].com/index.php?itemid=7
http://www.[site].com/faq

I want to filter/grep this txt file so I only get the URLS that contain an '=' symbol as shown below:

FILTEREDFILE.txt

http://www.[site].com/index.php?itemid=10
http://www.[site].com/site/page.asp?CID=72&DID=
http://www.[site].com/index.php?itemid=7
http://www.[site].com/site/page.asp?CID=72&DID=

Using these URLS in the FILTEREDFILE.txt I will then use a foreach loop to add an apostrophe to the end of each one to see if it is vulnerable to sql injection by looking at the response content lengths to see if there is a change/difference.

I know that even on the URLS and do not contain an '=' that there still may be sql injection vulnerabilities in the forms and POST requests and so on, but I am not interested in those at the moment.

IMPORTANT:

I am only interested in vulnerabilities that can be determined by changing/altering the URL itself (i.e by adding an apostrophe to the end of http://www.[site].com/index.php?itemid=7 and so on).

What I want to know is whether by greping the txt file for URLS that contain an '=' symbol will I miss any URLS that could still be vulnerable that do not contain an '=' symbol. (excluding forms, POSTS, url rewrites, just manipulating the URL in the URL bar)

Hope this better explains my question,

thanks for your help

SQL injections can be performed in any part of the request. Any parameter of the HTTP request can hold SQL data that can trick the application into injecting it into the database.

For example, Amazon has the product IDs in the URL http://www.amazon.com/gp/product/B008GFRB9E This is called an URL rewrite and the webserver extracts the product id from the URL and uses it to query the database for it.

Without having the source code available, there is no way to know what SQL queries are being performed. One web application can perform a reverse DNS on the connecting IP address and insert that name in the database. But the IP can resolve to a string that performs an SQL injection.

Here are some of the ways to get variables from the URL into the web application:

Wikipedia uses the colon (:). ex: http://en.wikipedia.org/wiki/File:Bald_Eagle_Portrait.jpg
JavaScript applications can use fragments (#) as input. ex: https://www.youtube.com/watch?v=9CTkdih2kU8#t=15s
Tilde (~) was popular once. ex: http://www.cigital.com/~gem/
You can encounter protocol handler links like data: or javascript: that can indirectly pass data the web app. ex: javascript:addtocart(5)

When parsing your links remember that characters can be URL encoded.


Using optical illusions as CAPTCHA Would using the "flaws" in human perception of an optical illusion graphic allow a system to differentiate between humans and machines (using these pictures like a CAPTCHA)?

Some examples are where a human might count "dots" (that are not really there) or choose which parts of a picture have matching colors (when the colors don't actually match due to the illusion).

Some example pictures:

All the cars above are the same size, but humans see one as larger.

The orange circles above are the same size, but humans see one as larger.

The squares above are same color, but humans see the bottom one as lighter. Cover the line the arrow is pointing at with your finger and you will now see the squares as a computer would.

If a computer were asked to pick out the largest car or circle or the lighter square from these pictures, it would have more difficulty than a human would.

This will probably not work for a long time because there is nothing inherent in these "flaws" which cannot be reproduced by a machine.

The first problem you need to solve is to create an algorithm which produces such images which are easy to solve for most humans but hard to solve for current image recognition. Once you have this system in place to protect important sites it gets attractive enough to break it. And then it is only a question of time, i.e. the efforts to break the captcha are related to how much can be gained by breaking it.


Can URLs be sniffed when using SSL? I know that http requests can be sniffed, so sniffer can see the requested URL from the victim. So 2 days ago I my bank made me a web-account to see, send money etc...

The thing I saw is my session id is always on my URL.. I copy/pasted it on another browser and I successfully logged in from it without entering username/password(on the new browser).

So my question is whether https:// (get) links sniffable over the wire (e.g., with ettercap)? Should I be worried?

HTTPS uses TLS, which is Transport Layer Security.  HTTP as a protocol,  runs above the transport layer.  This means that all of the communication made by HTTPS,  including the URL is protected.

Passing the session id in the URL is insecure for other reasons.  For example it exposes the possibility of Session Fixation.  The Session ID  written to paper if a user prints a webpage.  It also defeats the use of HTTPOnly cookies...  This is just a bad idea and its likely that this bank has made other poor choices in regards to security.


Security implications of FileExists() from javascript in browser What would the security implications be if JavaScript, in a browser, could perform a typical FileExists() operation with normal file paths (win and/or mac)? Something like Node's fs.existsSync(path) but from JavaScript running in a browser's sandbox. Assuming the logged in, browser running user's normal file permissions are respected. I understand this is an information leakage problem.

My question is: what are the concrete consequences of this leakage that a semi-technical product manager would understand? Examples would be helpful. The JavaScript could be from a secure or insecure site, nothing else special, just the ability to test for the (Boolean) existence of files (not directories) with an absolute path.

You could learn a lot of interesting information about the users system this way.
This information could be used to find the correct exploit for the user, or just be collected or used as part of a system fingerprint to identify users (Even with another used browser).

Detecting the OS would be extremely simple, but also the detection of used versions of static libraries should theoretically be possible.

Most services create pid files when they start. This could be used to check if specific services are running and try to attack them (Think of some web admin panel without csrf protection).

As @TessellatingHeckler mentioned: You could also try to "bruteforce" (more dictionary attack) usernames.


Preventing jwt replay attacks against the client-side I already read good answers about preventing replay attacks with JWT and a lot of resources like jwt.io.

The conclusion was that I needed to use the jti claim. From: Can I prevent a replay attack of my signed JWTs?

My schema right now is simple:

User logs in.
Server answers with a JWT.
Client checks if it's valid and stores it.
Client sends the JWT.
If it's valid the Server answers with a new JWT.
Wait 30 seconds
Go back to step 3.

So I started using jti, On step 4 it will use the jti stored on db from step 2 and create a new one for the next request.

While this works to prevent replay attacks on the server-side, it doesn't for the client-side. The flaw I found is: What if user redirects the traffic and always answers the same jwt, the client will think "hey this jwt is valid".

I had the brillant idea of saying "well, the jwt can't be the same as the last one". And found another flaw: now the user only needs 2 jwts to break it.

And now I have no idea on how to prevent this. I can't save all the jwts on the client side.

@edit: I forgot to add, this desktop app requires constant internet connection, it's like a game where you login and if someone logs in with your account you get kicked because your session is not valid anymore.

I'm trying to prevent multiple users on the same account at the same time, and ofc trying to prevent the user from using the same jwt and not needing to login anymore. (it's a paid software)

What you are saying is that you do not want a client to be able to share his valid token with another client and thereby share his session.

You have different options to achieve that:

Use a counter in the body of your token. Every time you exchange the token, increase the counter by 1 on the server side. You remember the current value of the counter for the user on the server and verify that it matches the token you receive back. If another client uses the same token, the protocol will get out of sync and only one of the sessions will stay valid.
Store a client specific value (e.g. the IP address) in the body of your token. Since the token is signed, the client cannot manipulate this value. You can check on server side, if the value matches the client property. So if another client with a different value for this property (e.g. coming from a different IP address) uses the token, you can detect this on the server side. If you use the IP address for this, be aware that this does not help if both are behind the same NAT or use the same proxy. If you use another property, make sure to choose something that cannot be emulated easily be different clients.
Rethink your token strategy. Maybe a classical session management is better suited for your needs than token based authentication. Without further insight into your architecture, this is hard to tell, but you can evaluate this option and see if it solves your problem.


What prevents a man in the middle attack when verifying a certificate with authority? If a certificate looks suspicious you'd want to verify it with the authority.  As such you'll need to open a channel to the authority's verification server.  Who/what protects this verification channel against man in the middle attack?

If a certificate looks suspicious you'd want to verify it with the authority. As such you'll need to open a channel to the authority's verification server.

No. TLS certificates are verified entirely locally. The certificate authorities' public keys are stored on your system (maintained by OS and browser vendors), and public key cryptography gives you the ability to verify that the certificate was signed by the corresponding private key.

The only thing close to what you're saying is checking for revoked certificates, which historically has involved a network check. Due to issues with an attacker being able to make those requests fail, Chrome at least now bundles revocations into its software updates.


Can my software get FIPS 140-2 certified? I am starting the early stages of researching the possibility of getting FIPS 140-2 certified, but I have run into some confusion. To start, our software is written in Java and does not actually do any of the encryption/decryption, currently that is done by BouncyCastle libraries and the hope is that when BouncyCastle becomes FIPS certified our product can become FIPS certified as well.

The problem I am having is right in the first line, that is what FIPS 140-2 defines as a cryptographic module, it states:

A cryptographic module shall be a set of hardware, software, firmware, or some combination thereof that
implements cryptographic functions or processes, including cryptographic algorithms and, optionally, key
generation, and is contained within a defined cryptographic boundary.

Since our software is not actually implementing any of these algorithms, we are just using a service provider, does this mean that our product can not be certified? Are we stuck in the FIPS complaint zone? If our software can get FIPS 140-2 certified what would the testing labs actually look at since our software does not do any of the processing?

I have gone through many of the FIPS 140-2 certified projects and it seems that my fears may be true. Most things that are certified are proprietary cryptographic libraries that are used by larger software projects such as the Windows 8 cryptographic kernels and Symantic cryptographic libraries.

My understanding of the FIPS 140-2 standards, unfortunately, aligns with your fear.

As far as I understand, the FIPS 140-2 standards are about proving that you handle private keys in a responsible way. If your software lets Bouncy Castle touch the private keys, then even if you wrote the most secure software in the world, your overall product is only as secure as Bouncy Castle :-(


Evil Twin Attacks against WPA-TLS Today I'm getting into the details of WPA-Enterprise. Most of what I saw was difference between protocols that use certificates. Most posts say that EAP-TLS is the most secure authentication protocol and that it addresses the Evil Twin attack problem.

Does it really though?

When using a protocol with a server side certificate (EAP-PEAP) the clients may still accept an invalid server certificate. Can be misconfigured client or by user error when manually accepting the certificate.

In case of EAP-TLS (or EAP-TTLS with client certificate enabled) the client needs to have his certificate in order to authenticate to the network as well. But taking into account that the client may trust an untrusted certificate he will still send his certificate to the hacker, right? then the hacker could use the certificate to login into the real network, right?

Am I missing something in EAP-TLS??

But taking into account that the client may trust an untrusted certificate he will still send his certificate to the hacker, right?

yes, if client ignores invalid server certificate error during connection.

  then the hacker could use the certificate to login into the real network, right?

no, because only public part of client certificate is sent to RADIUS. Public certificate without private key (which is not sent to server and never leaves client computer) is useless in terms of hacking/impersonation of legal user.


Security concerns of browser injected JS To employ end-to-end encryption, I am using a small tool that encrypts contents that is then posted and stored on our servers. While there are several concerns on client based encryption, I think it is better then no encryption at all.

The tool is not delivered by the web pages itself, but stored on a trusted server and injected by Browser Extensions or Bookmarklets into the page we want to use encryption on.

For now, the pages where the tool is used are under our control too and somewhat trustworthy. However, I like to use the tool on third-party pages too, like webmail sites.

That makes me wonder about how a malicious (or even just a sloppy) website may threat the encryption, eg. by funneling the key or plain text to the server. Is there any chance of sandboxing the injected JS, or do DOM events and JS namespaces provide access that cannot be blocked in any way? How large are the chances that "good" sites will siphon the key by accident?

If you are executing the code in an extension, it is run in a separate context (for security reasong) and it can be made to run without the code/key being concealed to the called webpage (which is a bit different than the web page not being able to detect that you used some script within the page).

For example, GreaseMonkey is designed for doing this kind of thing (running scripts on third-party pages) and, as far as it is properly written,¹ the affected page can't read/manipulate the script.

¹ Some insecure constructs, like unsafeWindow, would allow a compromise of the script, and even for the page to run javascript with chrome privileges.


JSON Web Tokens - How to securely store the key? I was building a RESTful Web Service when I came across JSON Web Tokens as an alternative to traditional cookies for authentication. The conceptual core of this method is that the server is the only agent that knows the secret key used to digest (commonly done using HS256) the payload, so only he can determine if the client altered the content of the message. My concern with this approach is: How can I securely store the secret key used by the server to encrypt the payload? Should I change it periodically? Should I generate it 'randomly'?

I thought of generating a 'random' string when my RESTful Web Service is initialized and storing it in a 'global variable' used afterwards to digest my payloads.  However, I fear the possibility of another process accessing my REST api 'memory space' or that my operative system's virtual memory feature exposes my secret key.

The reality is if other processes can access your process memory or features of your
virtual machine, the game is probably over as you're already compromised. If a process
has access at this level, it can probably gain other information, such as the initial
credentials used to authenticate before obtaining the token or just modifying
results to make token verification return true despite the actual verification result
etc. Don't focus too much on extreme possibilities. Most compromises occur through
far simpler exploits or configuration errors, such as storing the private key on the
file system which is world readable and accessible to your web server etc.

The best way to manage keys and secrets will depend a little on your platform. Some
platforms provide key management frameworks and perhaps using one of those would be
appropriate.

Don't focus too much on the fact this is a secret key. In reality, it is no more
critical than other credentials you need to manage. For example, how do you manage
the credentials which allow access to your databases? If that solution is good enough
for your databases, then it is probably good enough for your secret key. If it isn't,
then I'd be asking whether it is actually good enough for your database. The reality
is, if someone is going to compromise the system, then it is likely they are doing so
to gain access to whatever data/service the interface is providing. In most cases,
this underlying service or database also needs credentials and credential management
and these are the real keys to the kingdom.

I think it is best to use a consistent approach to manage all the credentials your
application needs and not to treat the secret key for token creation/verification as
extra special. Don't over think the solution simply because it involves words like
'key' or 'secret'. All credentials are sensitive data which need to be managed in a
secure manner. A large proportion of the mistakes that are made are due to
over engineered complex solutions that become difficult to maintain and easy to get
wrong. Consider solutions which use existing, known and tested facilities/frameworks,
such as keytool, key chain managers etc. Failing that, use something which can be
easily understood and maintained. Something as simple as a database may be
sufficient. Avoid solutions which involve storing the information as constants or
global variables as this can become difficult to maintain because changing the key
now means a code change and now you have to test, do change management and promote to
production, etc.

As to how you generate the keys, well that will depend on your environment and the
types/levels of risks you need to manage. As a rule of thumb, I'm always very wary of
anything that relies on 'random'. Generating true random values is extremely
difficult and often doesn't do anything to improve security. In fact, assumptions of
randomness which have later proved to not be random can reveal patterns, which in
turn means the possibility of being able to predict future values, which is almost
always a bad thing when you're talking about keys. In this scenario, I don't think
randomness is going to gain you much from a security perspective unless you're in an
environment where it is critical that sys admins don't know the key. Likewise,
regular changing of the key is unlikely to provide much other than inconvenience for
your users. Whenever you change the key, all currently issued tokens will become
invalid. You might want to consider having a policy to change the key when staff
leave or change roles and you could even consider a policy to change the key whenever
the software is updated, etc.
However, religiously changing the key every week or so
is unlikely to provide anything with respect to security.

Note that the above does not hold true for all keys. There are situations where a
private key needs to be managed with extreme care - for example, the private key for
root CA. Not all keys are equal. Your management approach needs to match the
requirements and risks you need to protect against. In the case of JWT, you are
dealing with a largely closed ecosystem - the key is used to generate/sign and verify
tokens. The objective is about detection of tampering, not protection of secrecy. The
risk is that if someone gets the key, they can create forged tokens and gain
unauthorised access to your service. What this ultimately means depends on the
service. The extent to which someone will try to do this also depends on the
underlying service and its perceived value. The lengths you go to to secure the key
should reflect the threat.


Which HTTPS certificate is the content verified by if the content comes from multiple servers? If a webserver has an HTTPS certificate and a page on the server pulls resources from other webservers - maybe a CDN with a protocoless path, or not, for things like static images,  stylesheets, and JS libraries - which web servers' HTTPS certificate are they verified by?  It seems like that might be important given things like SSL-strip.

If it gets resources from a site like a CDN the certificate will be verified against the URL of this resource, in this case the CDN. The URL of the HTML file embedding these resources does not matter in this case, only the URL of the resource itself.

  ... with a protocoless path

A path like //host/page instead of http://host/page or https://host/page just means that the same protocol should be used as the embedding page uses. But this does affect how the certificate will be validated.


What is a good email site that doesn't mine your personal data? I am becoming less and less ok with Google and Facebook collecting data on me based on my online activities and then selling that to companies. Is there a good email service out there that respects privacy and doesn't mine data about you?

If you are worried about your email provider intercepting your messages then you should consider running your own SMTP server.  However,  any message transmitted in plain text can be intercepted by an adversary.  So even if you run your own server, this doesn't guarantee secrecy.

...So Perhaps asymmetric cryptography can help,  I like Enigmail.


distinguish between bots and legitimate clients If an attack (DoS & DDoS) involves thousands of bots, how can the server distinguish them from legitimate clients?

It's going to vary for every single attack.   With DoS attacks, you can looks for attributes that are different than "real" requests, say values that are out of range, or the lack or specific format of a particular piece of data like a user-agent or referer in a HTTP request.

Generally speaking for DDoS attacks, if the traffic gets to the server, you've lost, and it doesn't matter.   DDoS attacks are purely designed to choke resources and the most common bottleneck is the network bandwidth.   You can potentially identify characteristics of a DDoS attack, but it almost always needs to be identified and managed upstream so the traffic never reaches your servers.


Hardware compatibility with Hashcat in Windows 10 (64-bit) This question is not a security question but about a security tool.

Why am I unable to leverage my decent hardware (I think) with hashcat?

This is what I see when I run hashcat in Win 10 (64-bit).

C:\Users\USER\Downloads\hashcat-4.0.1>hashcat64.exe -m 1700 -o cracked.txt sha512.txt -a 3 ?d?d?d?d?d?d?d?d?d?d
hashcat (v4.0.1) starting...

* Device #1: Intel's OpenCL runtime (GPU only) is currently broken.
             We are waiting for updated OpenCL drivers from Intel.
             You can use --force to override, but do not report related errors.
* Device #4: Not a native Intel OpenCL runtime. Expect massive speed loss.
             You can use --force to override, but do not report related errors.
ADL_Overdrive_Caps(): -8

ADL_Overdrive_Caps(): -8

OpenCL Platform #1: Intel(R) Corporation
========================================
* Device #1: Intel(R) HD Graphics 620, skipped.
* Device #2: Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz, skipped.

OpenCL Platform #2: Advanced Micro Devices, Inc.
================================================
* Device #3: Hainan, 1523/2048 MB allocatable, 5MCU
* Device #4: Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz, skipped.

Hashes: 1 digests; 1 unique digests, 1 unique salts
Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates

Applicable optimizers:
* Zero-Byte
* Early-Skip
* Not-Salted
* Not-Iterated
* Single-Hash
* Single-Salt
* Brute-Force
* Raw-Hash
* Uses-64-Bit

Password length minimum: 0
Password length maximum: 256

ATTENTION! Pure (unoptimized) OpenCL kernels selected.
This enables cracking passwords and salts > length 32 but for the price of drastical reduced performance.
If you want to switch to optimized OpenCL kernels, append -O to your commandline.

Watchdog: Temperature abort trigger set to 90c
Watchdog: Temperature retain trigger set to 75c

Cracking performance lower than expected?

* Append -O to the commandline.
  This lowers the maximum supported password- and salt-length (typically down to 32).

* Append -w 3 to the commandline.
  This can cause your screen to lag.

* Update your OpenCL runtime / driver the right way:
  https://hashcat.net/faq/wrongdriver

* Create more work items to make use of your parallelization power:
  https://hashcat.net/faq/morework

[s]tatus [p]ause [r]esume [b]ypass [c]heckpoint [q]uit =>

Session..........: hashcat
Status...........: Running
Hash.Type........: SHA-512
Hash.Target......: 88be1866a370d4c538f8fcf5a27d94a681a4e16b43ccf1a2db3...08e862
Time.Started.....: Sat Feb 10 09:27:15 2018 (45 secs)
Time.Estimated...: Sat Feb 10 10:46:11 2018 (1 hour, 18 mins)
Guess.Mask.......: ?d?d?d?d?d?d?d?d?d?d [10]
Guess.Queue......: 1/1 (100.00%)
Speed.Dev.#3.....:  2109.1 kH/s (7.58ms)
Recovered........: 0/1 (0.00%) Digests, 0/1 (0.00%) Salts
Progress.........: 96153600/10000000000 (0.96%)
Rejected.........: 0/96153600 (0.00%)
Restore.Point....: 96000/10000000 (0.96%)
Candidates.#3....: 4124563999 -> 6207615789
HWMon.Dev.#3.....: Temp: 35c Fan:  0% Util: 88% Core:1030MHz Mem:1000MHz Bus:4

[s]tatus [p]ause [r]esume [b]ypass [c]heckpoint [q]uit =>

It is clear from above output that everything is not happening in right way.
Then I visited hashcat page and checked the GPU driver requirements and visited:
AMD Page
and
Intel Page

Then I downloaded and installed AMD Radeon software adrenaline edition but unable to figure out what to download on the Intel page.

Which software should I download in order to use hashcat effectively?

I don't have a lot of great news for you, but I do have a couple of pointers.

On the Intel side, as noted in the output, the Intel OpenCL drivers have a known problem with hashcat that must be resolved by Intel. There's not a lot you can do about that part.

On the AMD side, I think that the device that's actually active in your test run - the AMD Hainan - is a Radeon 8800 or similar? If so, it's pretty old, and probably not likely to perform very well. You'd be better off renting an AWS GPU instance.

You might also try -d 4 to explicitly try the AMD driver for your CPU to see how it performs. It might actually be faster than your AMD GPU.

Once you've got your platform established, adding a couple of options should help:

-O (use optimized kernels, since your target mask is short)
-w 4 (highest workload factor)

But that's about all you can do with the platform you have. There are no driver changes that are going to significantly help that I'm aware of.


What was the original intent for the feature that StrandHogg uses? The "Affinity" of Android tasks seems really complex to handle. The StrandHogg vulnerability uses tricks with "Affinity" to render itself inside an another app.

The information that I've found this far does not provide exact details of vulnerability but as far as I know there is not a technical vulnerability but a poorly designed API which allows for clever social engineering attacks.

Is there a real use case for the API behavior that StrandHogg uses?

If I have understood correctly, the API the vulnerability uses allow attacker to place its own Activity on the victim "Back stack". From reading the API description and the provided example cases the main intent of this API is to allow embedded activities from other apps to be displayed within your own task. However, the StrandHogg vulnerability seems to the other way around: using API to push your own activity over another task's "Back stack".

My best guess is that the attack uses the weird behavior described on page 100 of presentation called "Manipulating Android tasks and back stack" from year 2011. However, I cannot imagine any sensible use case for the behavior described.

It's not just the victim "back stack". There are various possibilities. For example, let's say the victim app has not yet been launched. An attacker can place their activity in the background. Then when a user taps the icon of the victim app to start it, the "back stack" that the attacker's activity is lurking in could then come to the foreground and be treated as the victim's "back stack", just because of its declared task affinity.

  From reading the API description and the provided example cases the main intent of this API is to allow embedded activities from other apps to be displayed within your own task. However, the StrandHogg vulnerability seems to the other way around: using API to push your own activity over another task's "Back stack".

Regarding this use case, think of it this way: activity A is the intended embedded activity, coming from application 1. Application 2 is the one that would like to incorporate activity A. With the StrandHogg feature, application 1 can launch activity A into application 2's back stack, thus allowing the user the experience of activity A as an embedded activity within application 2, even though it is coming from another app. One can imagine that a legitimate use case would have application 2 first communicating with application 1 to request the embedding of activity A, and then application 1 using the StrandHogg feature to do so.

We could argue, and rightly so, that this is not the best way to support this kind of embedding, as it could be abused for phishing attacks and other attacks, but that's another question.


what is a valid challenge for 2 factor authentication? When designing a password reset process:

Is an email address or an assigned username a valid piece of information (identifier) to ask for in two factor authentication?
How does two factor authentication work for password resets in general? wouldn't asking more information from the user be an overkill when they have already forgotten their password?
Is sending a reset code via mobile coupled with a unique identifier qualify as two factor authentication?

Two-factor or multi factor authentication is based on three possible forms of authentication:

Something you know which is considered secret (password)
Something you have (token, SMS token, card,...)
Something you are (biometrics)

If either two of these three are combined, you can speak of two-factor authentication. Saying two things you know (such as two passwords or username and password) IS NOT two factor authentication.

You can use as an identifier but you cannot use it as the secret (if you plan to use it as the "password").
Password resets will depend on the procedure in place. It can be the same as with a password, you just get a reset link in your email. This doesn't mean the second factor is altered! The password should preferably not be changed based on another factor of authentication (especially applicable in case of something you have in case of theft).
Yes, but you should ensure that the token is only limited for a certain period.


Cross Domain Javascript security I used a web vulnerability scanner to scan my web site. It indicates several links with "Cross domain Java script source file inclusion."

May I know how would an attacker exploit this type of vulnerability, exactly? For example, the JS in question comes from addthis.com  (share buttons etc). For this exploit to work, attacker have to exploit addthis.com, change their addthis.js and then some how when my users browse my website, this modified addthis.js will be executed on my client browser PC? Am I even on the right track?

If I wish to do remediation, what is the correct approach? Download the external domain JS to our side and run from our webserver? What other better and safe approach could there be?
thanks

Yes, all your assumptions are correct there.

As you are including content from addthis.com, your client-side Origin is fully trusting this domain. If there was any compromise to addthis.com, or if addthis.com decided to change the script to do something more invasive then your site would be vulnerable.

For example, addthis.com may suddenly decide they want to collect data from end-users of their script, and this data might include cookies, and HTML5 storage data. By including the script on their domain you are allowing them to make these changes without agreement from you.

Yes, downloading the file and hosting from your own domain is the safe approach. Bear in mind however that you still need to trust the actual code to do what you're expecting and only what you're expecting. So it might be worth while manually auditing the code and doing any operations such as minification yourself.


Why browser hijacker changes the homepage to yahoo I have seen many browser hijacker like istartsurf,  ask.com which changes the victim's search engine to yahoo. Why many(almost all)  browser hijacker changes the search engines to yahoo. Is there any thing in yahoo.

Yahoo redirect virus can also be added to "browser hijacker" and a "potentially unwanted program" categories. Programs that belong to this group are spread using three different techniques:

Traditional installation method. You can install Yahoo redirect malware or similar browser hijacker with a help of typical installation technique, which requires going to the official program's website, selecting the program and downloading it to the system. This is a clear example how attentive and careful you have to be while browsing on the Internet and looking for the software that you need.

Bundling Yahoo redirect problem can also start interrupting you out of nowhere. In this case, you should know that you were tricked into installing a browser hijacker on your computer in a bundle with other software. Programs that are most frequently involved in the distribution of browser hijackers are various download managers, PDF creators, video streaming software, video recording software and similar free applications.

Malvertising There are lots of illegal and legitimate websites that were affected by malvertising. This term means that they were filled with the malicious code that causes the appearance of misleading pop-up ads on these websites. Typically, they offer downloading "needed" updates or promote surveys and contests.

The easiest way to avoid infiltration of the browser hijacker and protect yourself from Yahoo redirecting problem is to install a reliable anti-spyware. If you need a tool that could warn you about the possible infiltration of potentially unwanted programs and viruses, you should choose spyhunter

This virus is similar to Google Redirect virus wiki and Bing Redirect virus . As soon as any of these threats gets inside the system, it causes changes on each of web browsers. Settings that are mostly altered by Yahoo redirect virus are the homepage, the default search engine, the new tab page and the bookmark list. In most of the cases, hijackers are capable of altering these settings without being noticed, so you can notice Yahoo redirects at the worst time. Also, this threat starts generating income for its developers by causing altered search results on people's search engines and redirecting them to predetermined websites. Here, we should warn you that after clicking on such ads you can be redirected to a truly malicious website that is used for spreading serious malware.


handle user-session-cookie and csrf token correctly for javascript app I have a django web app serving restful api endpoints and a javascript web app communicating with those endpoints through ajax.

They are under the same domain but in different ports.
server api ---- www.example.com:9000/api/endpoints
web app ---- www.example.com:9001

Now, we save two types of cookies.
user-session-cookie # authenticate the user. secure = True, http = True
csrftoken # secure = True

I wonder in general, is this implementation secure? In what circumstance the site is not secure?

I don't mark csrftoken http = True because the javascript app need get the csrftoken to send requests.  However, I am exposing the csrftoken to an XSS attack.  Is there anyway I can prevent csrftoekn from XSS attack?

XSS and CSRF have a rock/paper/scissors interaction.  XSS is always dominant over CSRF,  and almost all methods on the CSRF Prevention Cheat Sheet can be bypassed with XSS. A case where XSS and CSRF cannot be used to trigger a request is if the request requires the current password, a token texted or emailed to the user, or another value that cannot be obtained using a browser with the constraints of the SOP.  The Sammy MySpace Worm is a good example of how a CSRF sync token can be undermined using an XHMLHttpRequest().

XSS is a serious problem.  A strong method of defending against XSS is defining  a Content-Security Policy(CSP) rule set that prevents injected HTML from executing JavaScript.  The CSP along with strong input validation can be used to prevent all XSS within an application with a high degree of certainty.


have opened HTTPS port but still no response I have watchguard firewall and server behind it configured with NAT.

I was told to open port https for 1 of the server.

I have create a rule from any to the NAT server to allow port 443, the windows firewall has already disabled too. but when I scan with nmap, nmap shows that the port is blocked :

PORT    STATE  SERVICE
443/tcp closed https

and I scan with TCPing, it shows "no response" answer :

Probing 27.50.16.148:443/tcp - No response - time=2001.491ms

Does it happen because there is no web server?
The current condition is that the application that will be built on port 443 has not been created yet.

A TCP port is considered open if a client can connect to it. This means that there 1) need to be a service on this port and destination host and 2) that it the service is reachable from the client. Configuring a packet filter like Watchguard to let packets pass just lets the client reach the service if there would be any but does not create the service itself.


Can I prevent my ISP from accessing my network if I change my router config? A few days ago my internet provider automatically changed my Wi-fi network name.

I was very annoyed because I add to reconfigure all my devices, and I had no choice to refuse this update.

As they are able to alter my router configuration. I wonder to what extent they can control things in my local network.

Can they access my computer from the outside ?
Should I consider buying a custom router to have more control over my network?

I would be very surprised if your ISP can change the settings of your router. I suspect that they changed the settings of their router that you rent. If you are unhappy with this, use your own router after changing all default passwords and enabling other appropriate security settings.


Is web application connected to a database via an application server more secure? I have heard from my colleagues and some other people on web suggest that it is more secure to run this configuration:

Web server -> Application server -> Database, than this:

Web server -> Database

The reasons that if an adversary takes control of a web server, then there is one more layer to overcome if you need the database.

I think that if an adversary controls the web server then they are as good as having full access to the database, since they will be able to execute arbitrary requests to the application server that will trust them. It will slow them down I guess, but the extra effort to implement a middle tier + all possible holes in the application introduced by that seems not to be worth the effort to me.

P.S. Since I was told that my question is to generic, I will add more information on the setup that I have.

I have a SPA client that talks only to the API and token is used as an authentication scheme. Web application really provides only the initial request to hook up the application and there are no other calls apart from static files and API. The web application then talks directly to the database in the Data Layer. I have just one user in the database and all access is controlled by the business logic and/or the authorization layer in my framework (e.g. roles in a token can be verified with attributes before it goes to business layer, so without a required role you are not allowed to access some API at all). So there is not danger in anyone calling any of the API (unless I fail in protecting them appropriately, but that's another story).

So taking into account this setup, would there be any advantage from security point of view to make web application's data layer to talk to the application server that will handle the business logic instead of the database directly (and the application server will talk to the database). In this case the web application is generally reduced to the initial loading of the client + a proxy to the application service, which seems quite superfluous to me.

If you distinguish between web server, application server and database then you actually mean front end, business logic and back end (storage). This is also called a multi-tier architecture with presentation tier, application tier and data tier. In this case the application server will not simply pass through any requests from the web server but only allow actions which fit the business logic. This means that all the security stuff (i.e. who can access what) is essentially done in the application server and the web server is just there to make this information accessible via a web browser.

If you instead only have web server and database then the business logic is essentially part of the web server. While this makes it often easier to start wih some web application the missing distinction between presentation and business logic will lead easily into a mess which nobody can understand anymore and which often allows to bypass the business logic and thus get direct access to the database for an attacker.

Note that the separation between the layers does not necessarily need to be done with a separate server or application, but it can also be an in-process seperation (i.e. API, classes...). But it is important that this separation can not be simply bypassed which can often be handled more securely  with a separate process or server. A missing separation between presentation and application can sometimes be seen in that you can't access specific information by HTML but they are still accessible by a JSON or XML API.


Can I query on row-encrypted data in my database? Please let me know if any of my assumptions are incorrect.

Say I had a database, where all of the rows of a database column is encrypted at the application level using a single passphrase, "SECRET", using password based key derivation:

Both the random salt and IV ensure that encrypting the same data for two different rows will produce different encrypted values. However, if an attacker has read access to my database and is able to brute-force the encryption of a single row, they would then know my "SECRET" passphrase and could decrypt all of the encrypted rows.

Does this mean that the main benefit in using a random salt and IV for each row is that it hides the frequency of values of my encrypted data? For example, the downside to not using a random salt and IV would be that an attacker could look at my database and see "50 rows have value X, 49 rows have value Y, and 1 row has value Z" but would not know what X, Y, and Z actually are unless they could also crack the encryption? Are there more reasons to use a random salt/IV per row?

Say I needed to query my database for the values that are encrypted. Does using a random salt and IV make the query "Give me the rows that have value N" impossible? How can I protect my data with encryption and still be able to query on it, and what kinds of common threats would I then be vulnerable to?

First off, it isn't just frequency you are protecting.  If the attacker cracked value X in your example, he now knows all 50 rows.  Let's say the rows are users, and the encrypted value is a password.  Attacker has now just popped all 50 users at once.  That's more valuable than just knowing 50 entries were the same.

Random salt and IV per row doesn't make your query impossible, per se, but does make it really difficult without doing a lot of other gyrations.  Look up the term "homomorphic encryption" which offers a number of ways to perform some searches over encrypted data.  In practice, this isn't really scalable, or done in production, but it isn't impossible.

https://en.wikipedia.org/wiki/Homomorphic_encryption

"How much security" to sacrifice for functionality, is really a question only you can answer.  What is your threat model? What's the value of the data being protected?  Security has to be in service of your business goals, not an end unto itself.  It has a cost which must be less than the value it brings.  If the attacker gets control of your search function, they get all your data any way.

In practice, if your data can fit in memory, your best bet may be to decrypt the data, search in memory over the plain text, and leave the data encrypted on disk.  If you can't, you may have to leak partial information by breaking the stored data up into searchable-sized subchunks.

You don't want to give up the masking nature of the same plain text encrypting to different cipher texts if your protected information is something like passwords, or credit card numbers.  Anything an attacker can run a forward encryption on can be used for a known plaintext attack.

Example: Baddie (with read access to your database - but not the secret) signs up for your service as a legit user, and provides "password" as her password. She then pops the database, finds her own record, and now knows all the other users who also picked "password."  Very bad.


Proper way to target spammers on pages such as user registration, password recovery, etc What is the best way to handle spam on pages like user registration or password recovery? I am not asking about whether to lockout a user for a few minutes or how to put up a captcha. I'm interested to learn on how do I target the spammers.

Iv'e read that it is bad to target a user via:

IP since a lot of users share a common IP (e.g. users connected to the same wifi, users on a proxy, etc.)
Session and Cookies since users can just close open browsers and not allow cookies

So how do I target them so that I can implement proper spam prevention systems? I think it would be very easy for a spammer to just use the password recovery or registration form to spam away my site's confirmation emails, which would result to users flagging the emails as spam and stacking the server with unnecessary requests. Any ideas?

You are right about your assumptions on "what is bad", but when dealing with these kind of problems you have to ask yourself several questions:

How many same-ip users are going to ask for remembering their password?
Does my solution works reasonably well? (time-effort/solution)
Is this really a risk in your system?

I believe that the best way to approach this problem is an heuristic solution. The best thing to do is to study how many users do use this system a day and how many petitions you usually have. Once you have done this you can automate an alarm so that it sends you an e-mail when your algorithm find suspicious traffic.

Also, locking the page (as you suggest) will prevent malicious users to exploit this page and you are in fact mitigating the other problems.

Consider also some other actions:

setting some thresholds like: "maximum 2 mails a day for retrieving password for user".
using different from-emails for different actions (just in case they mark one of them as spam).
adding text in the e-mail so users are able to identify if somebody is trying to hack them.
others?

As a rule of thumb and when addressing security issues, never try to overkill a problem, consider always the risk ( probability of the materialization of a threat vs the impact over your business). Small and easy solutions are usually the best if they address well enough a vulnerability. Consider always the security/usability trade-off.

Hope this helps you.

(Feel free to add any grammar/syntax correction since English is not my mother tongue).


How dangerous is it to reveal your date of birth, and why? At some point I told a friend that it's dangerous to reveal your birth date (kind of like your social security number or your mother's maiden name), because it's a crucial piece of information for identity theft. However, I'm not sure what exactly an identity thief could do if the only non-public information he had about me was my birth date. (I'd consider my name, and probably my address, to be public here.)

How and why exactly is revealing your birth date itself dangerous?

Note that I'm not asking why knowing it in combination with other personal information (e.g. SSN) can be dangerous. I'm asking why even knowing it in isolation is dangerous.
What kinds of things could an ID thief do with just with my birth date? Can he, for example, open a bank account? Recover a bank password? Open a credit card? Take a car loan? etc.

(I'm assuming the country is the United States of America.)

The issue is not the birthday itself, the issue is a that unfortunately a lot of companies and websites are still using it for verification purposes. This is certainly bad practice and lots of companies are changing their policies just for that reason.

Banks sometimes used it for retrieving a password, but in recent years they too have changed their procedures significantly (depending on bank you use).

So to answer your question is it safe to reveal your birthdate. Preferably you only reveal it whenever it is really necessary (e.g. inquire each time if they really need it), the information is not considered secret and you will be required to disclose it on occasions for legitimate purpose. As with any personal information the best thing to do is to disclose in as few occasions as possible. On the other hand if identity theft is done and the culprit turns out to be someone being able to retrieve information or performing an action by just giving your birthday (which is easy to find). Then most likely the company will be liable for not adequately protecting your personal information or being to negligent in their verification process. Of course this will mean you will have to deal with it (which is a nuisance and very time-consuming).


owasp top 10 2017 automation I am working on security automation - checking web application for the OWASP top 10 vulnerabilities. I'd like to check for the respective description, CWE-IDs etc and make decisions automatically. I can imagine a machine-readable representation of the top 10 OWASP vulnerabilities that supports security automation. Are there efforts to provide this information in machine readable formats e.g. json or yaml. How do vulnerability scanners support the top ten, what methodologies are used?

It's a good idea to want to approach this problem with automation. The OWASP list itself, however, is not a list of vulnerabilities, where a vulnerability is a known bad version of publicly-released software or known bad configuration that can be scanned for, identified and rectified.

Instead, it is a list of what OWASP calls risks, which are classes of security failures that have led to compromise and loss. In other words, each OWASP item is a higher level abstraction, not an individual, identifiable vulnerability.

Also, many of the vulnerabilities that can be classified under one or another OWASP risk are themselves abstract, and not necessarily easy to scan for.

For instance, there are code patterns that are recommended to help prevent SQL Injection (one class of vulnerability under the Injection risk, the #1 risk now for many years)- like, use prepared statements. However, not all application code that does not use prepared statements is vulnerable to SQL Injection.

From an automation perspective, source code scanning tools known as "static analyzers" specialize in finding suboptimal code patterns- suboptimal both from a security perspective and also from an idiom/tech debt perspective. In my experience, they require an enormous configuration investment and still often only yield barely usable results.

Standing up automation for application security scanning as a whole is not a solved problem, depending only on the availability of machine readable resources. We are still in the banging-stones-together-to-haphazardly-make-fire stage of application security.

Perhaps the most automatable risk is risk #9, using components with known vulnerabilities. Every language platform now has tooling to check versions of libraries in use in a particular codebase against a list of libraries flagged for having known vulnerabilities. Which is great.

However- enormous respect to the overworked folks who without reward or fame toil in these areas- these latter lists are not exhaustive, comprehensive, or definitive. That a particular library doesn't have a vulnerability associated with it doesn't mean one doesn't exist. It more often means vulnerabilities exist but they just haven't been a) found or b) reported.

Overall it's a pretty poor state of affairs, and again, that particular risk is probably where current state of automation is strongest.

To close on a hopeful note, there are a number of promising projects. One that I keep my eyes on is Google's Grafeas:

https://grafeas.io

Its goal is to support the promulgation of machine readable metadata artifacts, from which an application security pipeline can be constructed. It is not close to production ready, but is progressing.


PGP RSA key size - encryption/decryption time From what I've read, PGP only uses the pub/priv keys for encrypting/decrypting a symmetric key used for actually encrypting/decrypting data. I'd reasonably assume that longer asymmetric keys wouldn't be much slower than shorter ones, since they would only be needed for encrypting/decrypting the mentioned symmetric key. This answer and some other googlable resources suggest that keys with bigger lengths decrease performance. Am I missing something here? Aren't bigger keys - for PGP at least - almost always better?

With RSA, encryption is mostly quadratic in the public modulus size, decryption is mostly cubic. This means that doubling the key size (e.g. from 2048 bits to 4096 bits) means four times the cost for encryption, eight times for decryption. (For ludicrously large keys, of more than 20000 bits or so, other algorithms become worthwhile and decryption is no longer cubic, but that does not apply to "normal" RSA implementations.)

However, you are right in that the encryption or decryption is only a one-time operation for a symmetric key. With a basic PC, a rough order of magnitude is that 1024-bit RSA takes about one millisecond for decryption; so 2048-bit RSA will mean 8 milliseconds, and 4096-bit RSA will imply 64 milliseconds or so. As you can see, the figures remain very low, in human terms. The perceived cost of encryption and decryption in PGP depends on the I/O costs more than anything else; when you receive and decrypt a 5 MBytes email, it will take a few seconds to download it, but only a few milliseconds to actually decrypt it (symmetric encryption can easily proceed at 100 MB/s, and the asymmetric decryption is a one-shot operation, as explained).

Longer keys are not necessarily better. We like longer keys because known cracking algorithms take more time when the key is longer. However, there is a point where this argument ceases to be valid: when the key is so long that it cannot be broken with Earth-based technology, then it is "long enough" and making it longer will not bring any significant good. Current RSA-breaking record is for 768 bits, and it is believed that 1024 bits are on the verge of the feasible (but we do not know on which side of the boundary it is). A 2048-bit RSA key is already more than big enough, with a comfortable security margin. The same can be said about 2048-bit ElGamal and DSA keys (which PGP also uses).

On the other hand, longer keys mean longer emails (because a signed email with PGP includes a copy of the key), although this is hardly significant (a few extra hundred bytes per email won't matter much). A more important reason not to use oversized keys is interoperability: some implementations may have internal limits, due to the way they were designed, and a huge key might exceed these limits. Apparently, some versions of GnuPG have trouble with keys of more than 4096 bits. Keys of 2048 and 4096 bits ought to work everywhere.

A more minor reason is that key generation can become prohibitively expensive with larger key sizes -- but you don't do that often, so this is only minor.

To sum up: with PGP, uses keys of 2048 or 4096 bits, and you will be happy. Don't be too worried about that choice; either is fine. Don't go beyond 4096 bits because it will trigger interoperability issues.


Is my bank storing my password in plain text? My bank (and every bank I've come across) only ever asks for individual characters from my password when logging in. Is my bank storing my password in plain text?

I agree with StrangeWill's answer; it appears they are storing it with a reversible encryption, which for many purposes is equivalent to storing it as plain-text -- as a malicious user in full control of their systems can recover the plaintext password.

You should make sure your password for your bank is not reused for other purposes; though this is always a good practice -- esp for anything where security is an issue and you aren't personally administering the systems.

If they aren't storing the password in a reversible format then they must have pre-stored hashes for each of the 56 different permutations (if your password was 8 characters long; there are 8 choose 3=56 ways of choosing 3 chars from it) of your password; and hashed each permutation with a unique long salt (so rainbow tables aren't possible).  However, if an attacker on their systems ever found your hashes; they could easily reconstruct your password since your effective password for each salt is only three characters long.  It would take roughly 803 ~ half a million attempts to crack one hash; or about 28 million attempts to crack all 56.  Since a single modern GPU can generate billions of (standard - md5/sha1) hashes per second; this is brute-forced in under a second.  They could beef this up a bit by using cryptographically secure hashes (bcrypt) or key stretching -- though this seems unlikely due to the large number of hashes they'll have to compute to store and check your passwords combined with given how weak it is initially (and it adds the risk of DoS attacks to the authentication module).

FYI: the reason your bank decided this method is that it helps prevent replay attacks.  E.g., if you log in to the bank on an insecure computer where a keylogger was running, the keylogger won't be able to log in on the next attempt with the same three characters you just used.  This is a bit tricky to do in practice (e.g., you have to make sure that the requested three characters doesn't change if the user doesn't enter a password and tries again later (from a different ip address) that you will get locked out and have to call your bank after say 10 consecutive bad attempts, etc).


Does any nation-state CA (certificate authority) have a public API to verify digital signatures? There are around 200+ nation-states on the planet. Most of these use eIDs. Do any of these nation-states have a public API to verify digital signatures?

Example:

Nation-state Canada issues a eID to Alice, through Canadas CA (certificate authority)

Alice signs some legal document using her eID.

Bob owns a service that needs to check Alice legal document. Bob verifies Alice digital signature with Canadas CA.

Bob used some sort of API, and Canada returns 'true' or 'false'.

And if none of the 200+ nation-states verify digital signatures,

How does Bob verify that Alice is really Alice ?

asked the same question 3 days ago but it was deemed 'to broad',
How would a nation-state provide an API for its citizens to verify their legal identity online?
i've tried to narrow it down now.

Does any nation-state CA (certificate authority) have a public API to verify digital signatures?

No, the CAs do not verify digital signatures, the relying-parties (the recipients) do the verification by themselves, using their own software applications. Eg, use Adobe Reader (free version) to verify digitally signed PDFs.

However, the CA's do publish a public CRL (Certificate Revocation List). That file can be viewed as an API that aids in the verification process. It does not do the verification process per se.

And some CA's provide access for Online Certificate Status Protocol (OCSP) requests. OCSP is a newer technique for determining if a certificate has been revoked or not. Eg Verisign. Like CRL files, OCSP helps with the verification process but is not the same as verifying a signature.

  And if none of the 200+ nation-states verify digital signatures, how does Bob verify that Alice is really Alice ?

Bob opens the digitally signed document or data by using the appropriate software application. To verify a digital signature, Bob's app goes through a number of steps. One of the steps is to re-create the trust chain between a certificate that Bob already trusts and Alice's certificate which Bob does not yet trust.

If Bob's software is able to re-create the trust chain, then doing so gives Bob some level of assurance that Alice is who she says she is.

How high is the level of trust? It depends on the polices and procedures of the root CA and the intermediate CA's on the trust chain. It also depends on Alice properly safeguarding her digital signature device.

If you're into "movie plots" then it is always possible (but not likely) for someone to forge someone else's signature no matter what technology was used.

In the real world, signatures denote trust and relying parties determine what level of trust they need to accept a given signature on a given document.


Workarounds for sites that are broken without cookies? For privacy against tracking, I have my browser set up to refuse cookies by default. I only allow cookies from whitelisted domains. In general, this works OK for me. However, I now have at least one case where it has become inconvenient. I pay for a digital subscription to the Washington Post, because I like their journalism and want to support it, but I do not want them or their advertisers tracking me, so I never log in and don't accept cookies from them. This has worked fine until recently. Within the last few days, they have done something new on their web site with the result that although I can view their home page, if I click through to a story, I get this message in firefox:

  The page isn’t redirecting properly. Firefox has detected that the server is redirecting the request for this address in a way that will never complete. This problem can sometimes be caused by disabling or refusing to accept cookies.

This is not them paywalling the site. In a browser set up to accept all cookies, I can access all their content without logging in, but any page click creates about 20 cookies from washingtonpost.com and about 20 cookies from their advertisers. If I go to the home page, clear the cookies, and then click on a link to a story, it works, but the cookies get recreated. So it appears that there is code on the pages I'm trying to view that attempts to create these cookies and then throws an error if creating the cookies fails.

Is there any good strategy for this type of situation that preserves my privacy? For example, I thought about writing a script that would run every 10 seconds on my machine and delete all cookies except those from whitelisted domains.

related: https://askubuntu.com/questions/368325/how-to-clear-browsers-cache-and-cookies-from-terminal

If you're concerned about trackers, you're probably looking for First Party Isolation.
First Party Isolation is a feature that Firefox adopted from the Tor browser's Cross-Origin Identifier Unlinkability concept. FPI works by linking all cookies to the first-party domain (the one in the URL bar), making third-party cookies distinct between different domains. That is, if you're visiting a.com and a tracker sets a cookie, and later visit b.com which uses the same tracker, it won't be able to see the cookies it has placed earlier, when the first-party domain was different (a.com). Another explanation:

What is First-Party Isolation
FPI works by separating cookies on a per-domain basis. This is important because most online advertisers drop a cookie on the user's computer for each site the user visits and the advertisers loads an ad.
With FPI enabled, the ad tracker won't be able to see all the cookies it dropped on that user's PC, but only the cookie created for the domain the user is currently viewing.
This will force the ad tracker to create a new user profile for each site the user visits and the advertiser won't be able to aggregate these cookies and the user's browsing history into one big fat profile.

(Source)
To enable FPI, you can either go to about:config and set privacy.firstparty.isolate to true, or install the official First Party Isolation add-on. But before you activate it, be aware that some web apps rely on third-party cookies for actual functionality and may become unusable afterwards (e.g. you might be unable to log in). If you experience such problems, try also setting privacy.firstparty.isolate.restrict_opener_access to false which will relax the isolation rules and you're less likely to experience problems during, say, a cross-domain login flow that redirects you between different domains.

Another approach in Firefox are containers.
With containers you're essentially isolating different sessions from each other without having to use multiple browser profiles. E.g., you could read WaPo in a distinct container, and any cookies set by trackers in that container wouldn't be visible in the other ones. Containers are available in Firefox Nightly and as an add-on.
(Chrome doesn't have this exact feature, but you can use multiple profiles to get the same effect.)

I thought about writing a script that would run every 10 seconds on my machine and delete all cookies except those from whitelisted domains.

The problem I see with this is that some sites re-create cookies immediately after you delete them (as long as you still have their scripts loaded). And if your timing is bad, you might eventually run into the same problems you had with disabled cookies.
Finally, there are also reputable addons such as Ghostery that detect and block known trackers. So, you have plenty of options to maintain your privacy without disabling cookies entirely -- which unfortunately doesn't get you very far in the modern web.


How to protect Server running on Windows 10 with Node Ngrok against attackers? I'm running https://ngrok.com/ on Windows 10 pro with a custom app made on Node server running locally (can't be Linux) for a test suite that uses both web and desktop integrated. So I'm basically hosting a server on the machine for another internal machine to access via the internet (there is no other way to solve the problem). Not considering securing the app itself but in case someone discovers the IP of the machine what can I do to secure it? The machine cannot use VPN, it's not connected to a domain but just plugged into ethernet. Only minimum software is running and everything else was removed. Everything is up to date and Bitdefender is installed.

So I'm basically hosting a server on the machine for another internal machine to access via the internet ....

In this case protect the access with authentication, so that only this other machine can access your server. When using the authentication build into ngrok only authenticated requests will reach your server which should greatly limit the attack surface and should allow access only for trusted peers.


Why oauth use a secret with temporal credentials? I am trying to understand oauth protocol. I am currently looking at temporal credentials section of the oauth 1.0 sepecification.

I can't understand why the secret is needed along with the temporal credentials. Secret is sent with the token itself. So if someone other than the app can get the token he can get the secret as well. right? So what is the reason for adding a secret?

Secret is sent only once from OAuth provider to app's server via SSL connection and then stored on app's site never leaving it later, while open part of token travels from a client to app's site with each request (leave alone session caching for now). SSL is designed to resist sniffing, being implemented properly and employing latest strong algorithms, so without compromising SSL algorithms, SSL certification scheme or app's site itself (perhaps, the weakest link...), it's not practically possible to obtain secret and forge fake request from unauthorised clients.


How can I obliterate information on a defunct device, and should I? I have old cell phones with problems that make them useless (non-responsive touch screen, black-on-black display, will not power up). I also have a bunch of solid-state USB memory devices that don't work (e.g. don't connect). I would like to dispose of this non-functioning junk, but I'm concerned that the devices have solid-state memory devices that contain secret stuff that I don't want unscrupulous people to get ahold of.
There is a recycler that can stick my junk under a degausser (unknown what kind), and can stab my old spinning drives.
The removable SD cards were removed from the phones, but I have no idea what is in the deeper recesses. A factory reset to wipe the device is not an option, and software reformatting is likewise impossible. This leaves me concerned that someone with skills might get ahold of a part and sell my information.
Is the recycler's degaussing procedure likely to obliterate the data (what questions should I ask), and if not is there some other reasonably certain method of keeping the data out of the wrong hands, consistent with recycling (I have some cement, if all else fails)?

Degaussing only works for magnetic media, not solid state.
Bashing everything to bits with a large hammer is probably the most practical. True, some of the tiny memory modules could in theory survive sufficiently intact to be reconstructed, but unless you're concern is high end Law Enforcement or a Nation-State that's pretty unlikely.
If you're still concerned, you could also Microwave the pieces but this would be a significant risk of unexpected fire. It would be safer simply to burn it.
If you burn it, be careful of toxic fumes.
A handy wood chipper would be useful.


Phone calls that listen to you saying hello and then say "goodbye" I live in France. About 5-10 times, once every 1-2 months, I receive an automated computerized call that listens to me say "hello" there is silence for 5 seconds, and then there is a voice recording of a British woman saying "good-bye".

If it isn't a sales call or a phishing call, then what is this kind of call? Why do I receive this call with a UK automated voice from France on a French ISP landline number?

We get these too in Australia. The consensus in the Internet seems to be that these are automated calls from cold call telemarketers. These automated callers calls random numbers and wait for the call to be received. When you pick up the phone, what's supposed to happen is that your call will then be routed to the next available telemarketer agent within a few seconds. In this case however, what happens is that at the time you picked up, there is no agents available, so the auto-caller waits a few more seconds for the agent to pick up, and finally gives up and plays the "Goodbye" message and disconnects.


How to cycle OAuth2 client secrets without downtime I have an app that relies on several OAuth2 providers to poll for background data on behalf of users, as a background process. As a matter of best-practice, I'd like to periodically cycle my client secrets.

The OAuth2 providers I'm using (and every OAuth2 provider I've ever seen) will allow me to re-generate a key/secret pair, but will not allow me to create a second pair.  If I re-generate my secret, there will necessarily be downtime, because the existing key will be invalidated and the app won't know about the new secret yet.

I can't work around this by creating a new OAuth2 relationship, because I would lose all of my permissions to poll data on behalf of my existing users.

How can an application cycle OAuth2 keys without downtime?

This is something I've been wondering about as well. I don't think a solution exists right now, but I believe new systems can be designed to do this without downtime by leveraging Trust Assertions for Certificate Keys (TACK) to do so.

When the client decides to cycle to a new secret we need a mechanism to ensure the server can trust the new secret. In other words, the new secret needs to be signed (i.e. a TACK) by the client. That's what the TACK specification covers, and details a lifecycle for creating a new TACK, revoking, etc. - most importantly it covers the handling of overlapping TACKs so you don't have downtime.