Can I read the domain name from HTTPS before SSL handshake? I am researching if I can host multiple domains on one server through HTTPS but for each domain, I have a different certificate.

In this case, I would need to know the domain of the incoming connection so in that first part of the SSL handshake, will it have the information I need to send back the correct certificate for that domain?

Yes, as long as the server and the clients support the Server-Name-Indication (or SNI) extension.   This extension allows for virtual hosting for HTTPS, where you have multiple independent domains and certifications bound to a single IP address.

Most clients these days do support SNI.  The place where you might have issues is if you have older clients using platforms like Windows XP, old versions of Android, or Java 6.


Backup is corrective control or a preventive control? This is a theoritical question. There are preventive controls and corrective controls. So, is Backup a corrective control or a preventive control? There are mixed answers and mixed explainations. (CISA EXAM)

Corrective Control

It isn't a control until it can be used and the only benefit is corrective, it does not prevent the media loss, it just helps fix the media loss.

Who cares that it needs to be implemented beforehand, and operational costs are incurred beforehand.

All other tools need to be implemented before they can be used, except maybe forensics.

That said, you need to "Channel" whoever wrote the exam and I am not CISA myself, RTFM.


Is there any CBC based ciphersuite which are secure for known attacks like LUCKY13? If you select the modern profile in https://mozilla.github.io/server-side-tls/ssl-config-generator/ , you can see it recommends to enable following four cipher suites also.

ECDHE-ECDSA-AES256-SHA384  ( =
TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA384)
ECDHE-RSA-AES256-SHA384 ( =
TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA384 )
ECDHE-ECDSA-AES128-SHA256 ( =
TLS-ECDHE-ECDSA-WITH-AES-128-CBC-SHA256 )
ECDHE-RSA-AES128-SHA256 ( =
TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA256 )

According to various sources in the internet, attacks like LUCKY13 are possible if you use CBC based cipher suites. (e.g. Why did TLS 1.3 drop AES-CBC? )

The question I have is,
 - As Mozilla clearly recommend above CBC based cipher suites, are those not vulnerable to LUCKY13, and also are those secure against any known such attacks?

No, all TLS CBC cipher suites have the same problems: most old implementations and a minority of currently deployed implementations (some unpatchable, some where the vendor could not be contacted by researchers, etc.) have a variant of lucky13 or poodle (both have many named variants).

The Mozilla list is likely from before the discovery of the new variants of poodle which finally caused SSL Labs tester to mark all CBC cipher suites "weak".

It is possible to implement CBC cipher suites correctly, but it is too hard. If the effort is made to implement them correctly, it would be better to spend the effort at supporting GCM or CCM or ChaCha20-Poly1305.

If the other side can support AEAD, you should use AEAD. If the other side can't support AEAD, you have to be very suspicious and test its CBC thoroughly. TLS is supposed to be secure without first testing the other side, so if you can drop CBC support you should do that. This means you drop support for TLS versions below 1.2.

Of course, for business reasons, many will choose to support CBC cipher suites for a long time. When can a business drop support? When no such clients exist in practice. When will users stop using clients (or proxies) that can only do CBC? When such clients can't connect to important servers (e.g. google, facebook). This will take a long time.

Chrome might show UI for "insecure" for sites that require CBC cipher suites next year, but dropping them completely - I guess not. Google's servers can't show UI for insecure - they either allow connections or not, so I think they will allow connections with CBC cipher suites for a long time (though they have published they want people to upgrade to AEAD and only promise to support ECDHE with AEAD).


Freaked out by "impossible click" in logs I was staging an isolated production environment and accessing it's remote PHP script from my local mac on
http://example.com/XbAM7Kt7SJj3M8ytJfEQZbwcBLzg0gNWGfyCHL2b0f0

I saw my click in the log as follows:

{
  "id":"XbAM7Kt7SJj3M8ytJfEQZbwcBLzg0gNWGfyCHL2b0f0",
  "timestamp":1535672410,
  "ip_address":"MY.IP.AD.DR",
  "user_agent":"Mozilla\/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/68.0.3440.106 Safari\/537.36",
  "referer":null,
  "parameter":"XXX"
}

And I couldn't believe my eyes when I saw the following in the next line of the log:

{
  "id":"XbAM7Kt7SJj3M8ytJfEQZbwcBLzg0gNWGfyCHL2b0f0",
  "timestamp":1535672411,
  "ip_address":"159.203.81.ADDR",
  "user_agent":"Mozilla\/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko\/20100101 Firefox\/33.0",
  "referer":"83.222.249.ADDR",
  "parameter":"XXX"
}

Just one second later (see "timestamp"), there was a Click from a Digital Ocean IP "159.203.81.ADDR" using a fake user agent and fake referer, with the same exact GET parameter ("XXX").
There is no way on earth that they could have known about the ID "XbAM7Kt7SJj3M8ytJfEQZbwcBLzg0gNWGfyCHL2b0f0" which my local machine generated randomly just a few minutes earlier.

I assume that this means that my local network is somehow compromised? My network activity is being sniffed by Malware and since the request was non-HTTPS the malware was able to replicate it in order to spy for sensitive information?

I have scanned my local mac for Malware using ClamAV and Malwarebytes, both didn't find a single thing.
How can I get to the bottom of this? Could it be that my home router is infected with malware?

I'm not sure if this is relevant, but as of recently I have experienced wired things on my mac and mobile devices. For example when surfing random websites, I sometimes suddenly get redirected to a scam ad website ("Congratulations you have won, please enter your information..."). I took a screenshot of one of those on my mobile device: https://imgur.com/a/UngqSlJ

It might be some security software on your system or in your network which inspects if the URL's you visit are harmful. They often do their visits from systems which are not obviously associated with security companies, since attackers often try to serve innocent content if they detect a bot from a security company. Thus, instead of trying to find any malware, try to disable all security software on your system or inside your network and see if the problem vanishes.


GET and POST Interchangeability In some applications, the HTTP methods GET and POST can be used interchangeably.

For example, the application may expect a POST request, and the frontend will also send the data in a POST request, but if the request is tampered with, the data will also be accepted in a GET request.

An example for this behavior would be Javas getParameter or PHPs $_REQUEST, which both deliver GET as well as POST parameters.

Is this generally considered a security issue? Is it documented somewhere, for example as a CWE or by OWASP?
Does this issue have a name?
What are the dangers of POST to GET downgrade? One example I could think of would be the possibility to exploit CSRF issues via img tags, which means an attacker can place CSRF payloads on websites where they cannot post scripts, making it considerably easier to exploit the issue. Are there other benefits for attackers?
What - if any - are the dangers of GET to POST change?

It is a bad practice as it makes the development more confusing in order to ensure that there is no overlay between the possible GET and POST parameters which are normally processed separately.

It also makes it a tiny bit easier for a hacker to benefit from a vulnerability in your site but it doesn't create breaches on its own.

In a well organized web application, the GET parameters are used for routing (page or module selection and relevant options) while POST parameters actually represent data submitted by the user.  Following this simple guideline makes the development much more organized, so safer from errors on your end.


PCI - prohibiting direct connections to the Cardholder Data Environment In PCI 1.3.3 it states:

  Are direct connections prohibited for inbound or outbound traffic
  between the Internet and the cardholder data environment?

A Cardholder Data Environment (CDE) encompasses any device or server that stores or transfers cardholder data. (PCI Glossary available here)

With our system, a user adds a credit card via the web, making each one of our front-facing servers a part of the CDE. In my view this is a paradox because any server the user has a direct connection to will always be considered a part of the CDE.

Any clues about how I should approach this?

The Guidance column of PCI DSS 1.3.3 (v3) states:

  Examination of all inbound and outbound  connections allows for
  inspection and restriction of  traffic based on the source and/or
  destination  address, as well as inspection and blocking of  unwanted
  content, thus preventing unfiltered  access between untrusted and
  trusted  environments. This helps prevent, for example,  malicious
  individuals from sending data they've  obtained from within your
  network out to an  external untrusted server in an untrusted network.

This means firewall controls and content controls (IDS/IPS, WAF, DLP proxies) should be used to limit CDE ingress/egress.  Permitting traffic in to limited, necessary ports is okay.  Permitting broad traffic in to unnecessary ports is not okay.  Permitting unregulated outbound traffic which could allow an attacker to exfiltrate data is not okay.

It really boils down to "preventing unfiltered access between untrusted and trusted environments."  I'll grant you the wording isn't directly useful.

(There is no guidance column in PCI DSS v2, but the requirement itself is the same, and the whole point of adding a guidance column with v3 was to provide, um, guidance to clarify the intent of the requirements.  So it's valid whichever version you're working with.)


ports above 1024 vulnerable against man in the middle I heard, that it would be possible to get man-in-the-middle-attacked this way, but the details are not clear to me.

Is it dangerous to use ports above 1024 for things like SSL? And why?

I think you are mixing up two things:

A man-in-the-middle attack happens outside your computer in the network. All ports are in principle vulnerable against such attacks, unless you use a secure protocol on them
Only the root user can bind to the lower ports (up to 1023), but any user can bind to the other ports. Therefore, you usually don't want to use a higher port for things like ssl.


Is there a well-researched and user-friendly solution to the password problem? The Password Problem has been spoken on many times, but most places I've seen offer terrible solutions such as modifying a dictionary word, changing your password requirements to include special characters (or using dumb password complexity requirements at all), etc.

I'm thinking the temporary solution to the password problem from the user side will be to use an OSS, securely encrypted (community-checked) password manager such as KeePass, etc. (which exactly is another question), but is there a good article that recommends this to users and cites scholarly articles? I'm thinking something along the lines of:

Install a password manager (here's how link) (Ref. to Academic paper with rationale)
machine- (or better yet dice-) generate your master password. (ref. to penetration testing of diceware-generated passwords)
setup 3 security levels in the generation profiles in your password manager, use the strongest (longest, highest entropy (Ref. to what entropy is)) when allowed.
For each site, check password against dics, turn on two-factor wherever possible, don't use "security" questions. (Refs)

  note: for the above, blogs, wikis, and other user-contributed sites are considered invalid citations. Actual academic journals are
  preferred, but official documentation sites are acceptable as well. The article I'm seeking can be a blog (but not Wikipedia), but the scholarly references it cites cannot.

I'm primarily looking for an end-user-side article or post, though one that also includes a section educating website owners on the server-side of this problem (citing, for instance, The NIST) would be even better.

An article or page that is already written is preferred, but iff none exists, we will have to make an answer to this question the first one.

The password problem is multi-faceted.  For this answer, I won't duplicate what others will tell you (your process looks fairly good, yet complex).

I will tell you this - the algorithm is the most important piece.

You can use a password of 81OTl*8tlxI+VqTZI7%wK however, if the place you have this password just stores plain text, ROT13, DES crypt, or MD2, MD4, MD5, NTLM, with or without a little salt, then oclHashcat can crack it in no time flat.  However, even Password1! with script and 100,000 rounds is more secure than 81OTl*8tlxI+VqTZI7%wK on crypt()...

Reference: https://en.wikipedia.org/wiki/Scrypt
(or for you "Wikipedia is not a reference" folks:  https://www.tarsnap.com/scrypt/scrypt.pdf)
https://medium.com/@mpreziuso/password-hashing-pbkdf2-scrypt-bcrypt-1ef4bb9c19b3
https://medium.com/@mpreziuso/password-hashing-pbkdf2-scrypt-bcrypt-and-argon2-e25aaf41598e (2019 revision)

This isn't an "end-user article" however, this can be used for "educating website owners on the server-side problem".


Can clients visit my site, and spam socket.emit(something); to my server, or is there some security behind socket.io? I'm using Socket.IO and the client side looks like this.

<script src="/socket.io/socket.io.js"></script>
<script>
    var socket = io();
    socket.emit("sendData", "hello!");
</script>

I'm wondering what's stopping a random user, from joining my site, looking at the code, and add the following lines to it, using Chrome's code view app or something of the sorts:

<script src="/socket.io/socket.io.js"></script>
<script>
    var socket = io();
    for(i = 0; i < 50; i++) {
        socket.emit("sendData", "hello!");
    }
</script>

A bit of a loaded question really. However;

While that is a possibility, it is the nature of HTTP(S) & the WS(S) protocols. Making requests is just that, a request. In regards to the underlying question being posed regarding security...

For browser restrictions you are relying on the same origin policy, for injected content via MITM attack vectors you should utilize the wss (Web Socket Secrurity) protocol which would then leave you with the typical XSS attack vectors.

These can be mitigated by using a combination of the HTTP Security Headers implemented with the HTML5 specification and sanitizing your input and output which is best done with character encoding.


SQL injection inside XSS Is it possible to perform an SQL injection inside an XSS attack?
And if so, where can I find information on this or some examples?

That depends on what you mean by "inside". For example, as Conor Mancone suggested, there could be a combined reflected XSS and SQL injection. That could look like this:
http://example.com/badendpoint?q=<script>$('input').value="';DELETE FROM USERS;--";$('form').submit()</script>

In this example, the SQL injection is the payload of the XSS. That's sort of putting the SQL injection "inside" the XSS.
When a hapless user opens that link, the script tags will get added to the page. The JavaScript will then fill out a form and submit it. The data entered in the form contains the SQL injection that deletes all users from the target database.
As nobody said, it may be better to call this chaining the vulnerabilities together.


Why would a client need our CSR file? I am a beginner to TLS/Ops.

Our operations team have setup a number of virtual hosts with domains we own for hosting endpoints on our Cloud.

We have 3 virtual hosts-

internal - to be used internally for integration purposes with the
other departments in our organisation like Siebel CRM...
partner - for organisations with which we do business.
public - as the name suggests

All communication is over TLS.

There is a new partner to whom we(I am a developer) have exposed a new API.

When a developer from their team tries to consume our API with Postman, all he gets is -

Client Certificate is not trusted in this subdomain and/or this endpoint explicitly

Their postman console shows this as seen in the attached image-

In the communication which our OPS team had with the client OPS team, I see that our Ops requested for a CSR file from the client and vice versa.

From the web, I see that a certificate signing request (CSR) is one of the first steps towards getting your own SSL Certificate.

Why would a client need our CSR file and similarly why would our Ops need theirs?

If I understood correctly, your peer's client-side certificate is not trusted by your organisation. Your ops team would have asked for a CSR to return a signed certificate that you trust, so that their (new) client-side certificate becomes trusted.
Unless there's more involved that isn't clear in the question, you don't need to send them a CSR, since your peer would not need to sign certificates for you.

About the CSR: To have a certificate signed, you need to have a key pair (private and public keys) and issue a certificate signing request (CSR) which contains bits of information and your public key. The CSR is handed over to the CA who in turn produce and return a signed certificate file for you (also containing your information, your public key and a signature).

Conversely, but less likely, if the 'client certificate' term in the error message is misleading, this could mean that your org's server side certificate isn't trusted by your peer's client software. This is where they may be asking you to change your server side certificate, hence why your ops could have decided to do initiate that by sending them your CSR.


Checksums do not match when I download file over http Just for the test I did the following:

Downloaded a page from Wikipedia via wget on remote server and named the file test.dat. Then I executed md5sum.

I download the file via HTTP and check it back on my home computer. The checksum does not match.

When I download the same file via SCP the checksum matches.

When I compare test.dat and test.dat.original in diff viewer I get these kind of differences.

When I download the file via 3G (not using my mobile phone, not my home WiFi) there is no such problem.

Any idea what might be the problem and what to look for ?

Edit by KoCMoHaBTa

Actually me and gotha are performing the test.
The problem is in my network and here is full description of the problem.

From several days I have experienced issues with downloading iOS apps from the appstore on all of my devices - they downloaded but iOS does not let them to install and gives an error.

Then I started digging around.
In short what it came out is that every time I download a file from internet - it gets altered.

I have tried with anything, applications, RAR files, ISO files.
They never match the provided MD5 and SHA1 check sums.

The test we have performed was intended to see what is happening. The changes are always actually at random place - they are never the same.

Before umping into what I have discovered, here is my home network configuration:

1. I have a modem provided from my ISP - Cisco EPC3208
2. Then I have a D-Link router - Dir-810L, flashed with DD-WRT (the only build available for it)
3. I have 3 iOS devices and a Windows PC
4. I own the router from about 2-3 weeks and this problem started 3-4 days ago.
5. Before this router I had D-Link Dir-300, again flashed with DD-WRT - never had any problems with it.

So digging even more:

1. Modem -> Router -> Device (Wi-Fi or Lan) - the problem occurs
2. Modem -> Windows PC (LAN) - > the problem does not occurs
3. iOS Device (Tethering over Cable) -> Windows PC -> Router (LAN to WAN) -> iOS Device (Wi-Fi) - the problem does not occur
4. iOS Device (Tethering over Wi-Fi) -> any device - the problem does not occur

So at this point it appears that the problem occurs when the router is connected to the modem.
So I'm not sure if my ISP or my router is doing something bad.
Or my ISP is doing something bad, which my router does not like :)

Anyway, we are trying to figure out what is the origin of the problem.
Here is a link to test files - Test Files
This archive contains the same file downloaded when I was connected directly to the modem and when using my router. It also contains WireShark dumps of the network for both cases.

At first point, when using my router, everything appears OK to me in WireShark, but the file is modified.

The interesting thing is when you look at the dump when I was connected directly to the modem - a large number of "duplicate" and "out of order" packets appears, but the file was delivered as expected.

Any thoughts on this?

Looks like an issue handling out-of-order and/or duplicate packets at the router, perhaps an issue with that build of DD-WRT when processing large transfers. The problem occurred using wget but not scp because most authenticated protocols will handle discrepancies at the application layer as they occur—scp runs over SSH which includes integrity protection—while raw HTTP relies on the integrity of the transmission as reconstructed at the presentation layer. In any case, I do not believe this to be an issue of information security.


Command Injection when all dangerous characters are escaped? OWASP recommends as defense against command injection to escape all special characters (if a whitelist approach cannot be used).

I wrote a quick PHP script doing this:

$input = $_GET['x'];
$dangerous = array("{", "}", "", "(", ")", "<", ">", "&", "*", "|", "=", "?", ";", "[", "]", "$", "–", "~", "!", ".", "%", "/", ":", "+", "'");

$input = str_replace("\\","\\\\",$input);
foreach ($dangerous as $char) {
    $input = str_replace($char,"\\$char",$input);
}

echo  passthru("echo '$input'");
echo "

executed: " . $input ;

However, if I use ' as input, it will result in an error (Unterminated quoted string).

I wasn't able to bypass the escaping of these characters, but it doesn't seem ideal that an attacker can generate a bash error because of invalid syntax.

Is there a way to bypass the escaping of these special characters?

I know that using a whitelist or existing mechanisms like escapeshellcmd would be recommended. I am more interested in the general idea of bypassing the escaping of special characters.

I came up with a bypass.

As @Sjoerd mentioned, backslash escapes don't work in single quoted strings, so it's possible to get out of the single quoted string.

Your list of 'dangerous' characters does not include backticks, or hashes; which allows a payload such as this one to work:

' `hostname` #

Or urlencoded:

%27%20%60hostname%60%20%23

The single quote becomes \' (which is treated as a regular quote, and '\' becomes the first argument to echo), the command in backticks is executed with the command output passed to echo. The hash is treated as a comment and causes the shell to ignore the trailing single quote, avoiding a syntax error.


Is it possible to get infected when using a smartTV between two computers? Been given a smart tv that used to be used as display connected to a pc with a HDMI cable, now I'm using it as a display as well, over HDMI too.
I was thinking maybe when connected to a network or inserted an usb into the smart tv it could get infected, but what about when connected over HDMI cable?
As far as I know HDMI only transfers video and audio, but I think theorically it could transfer "raw data", not sure here, so how come my computer can identify the smart tv, brand and model, if only video and audio is being sent?
Also, how much of a risk would using it be given if one computer has some malware on it?
To clarify, I mean using this TV as a display with one computer at once.
Thanks in advance

It is theoretically possible for a TV to get malware (either from the internet or a computer connected to it), and then for the TV to exploit a vulnerability in your computer's firmware, display drivers, or some other component it can talk to over HDMI (see @Esa Jokinen's comment about Ethernet over HDMI).
However, such malware would likely need to exploit multiple zero day vulnerabilities across different products in order to pivot in this way, and thus would probably be a very targeted and rare attack.
I do not think this is something the average person needs to worry about.


REST API - XSS prevention - When and how? I am currently developing a REST API with Java EE and MySQL, it will feed Data to a Android App. The Data comes from an AngularJS Frontend.
So my questions are, when:
When do I escape the data? Before it is filled in the prepared statements?
When I deliver the JSON? Both?

And how:
How should I escape the data? I currently am fiddling around with ESAPI and encodeForHTML - the problem here is, that is escapes stuff like @ and :) which I would like to support.

When do I escape the data?

Basically, as late as possible. The database is somewhere to store data, it is not a place to encode (escape) data. Of course use parameterised prepared statements to prevent any SQL injection attacks, but that should be as far as you take it. Your goal for writing to the database is simply to store the data successfully and to avoid any attacker breaking context and manipulating any queries to their own advantage.

Always think if a client/manager/supplier needs an export of the data, it is much easier if this data is already in plain format. It can become a headache if you then have to start converting it from HTML/JSON and then back into the correct format for export.

So the solution is to encode for JSON (but not HTML) when you deliver the JSON (preferably using a tried and tested Java JSON encoder).

You don't mention how you are rendering in your Android app. If you are using a non web control then you don't need to escape at all. If the controller doesn't interpret HTML and you are simply setting text elements then the application will not run any injected scripts. If you are generating a webview in Android on the client then you should HTML encode at this point.


How can I export my private key from a Java Keytool keystore? I would like to export my private key from a Java Keytool keystore, so I can use it with openssl. How can I do that?

Use Java keytool to convert from JKS to P12...

Export from keytool's proprietary format (called "JKS") to standardized format PKCS #12:

keytool -importkeystore \
    -srckeystore keystore.jks \
    -destkeystore keystore.p12 \
    -deststoretype PKCS12 \
    -srcalias <jkskeyalias> \
    -deststorepass <password> \
    -destkeypass <password>

...then use openssl to export from P12 to PEM

Export certificate using openssl:

openssl pkcs12 -in keystore.p12  -nokeys -out cert.pem

Export unencrypted private key:

openssl pkcs12 -in keystore.p12  -nodes -nocerts -out key.pem


How can CloudFlare save your website if the attacker knows the IP of the server? I saw CloudFlare's services where you need to change the DNS of your domain name to their provided DNS address.

The traffic coming as "mywebsite.com" goes through CloudFlare. What if I have a dedicated IP and the attacker targets the IP address. Is CloudFlare useless in this case?

found the answer here

Use CloudFlare IP addresses to your advantage

Take action to prevent attacks to your site during peak season by configuring your firewall to only accept traffic from CloudFlare IP addresses during the holidays. If you only accept CloudFlare IPs, you can prevent attackers from getting to your original IP address and knocking your site offline.


How can I find webpages with webapps using a specific framework? How can I find webpages using webapps using a specific framework, like you can look for apache servers with shodan.
In my case the application are made with java.

There are many ways you can get an idea what technology a particular site uses. Among them are:

observing file extensions in URLs
technologies mentioned in job postings
tech blog articles
company's open-source work
header leaks

So build a list of candidate sites and then go inspect them.


Honeyd: log grows too fast I'm having trouble with honeyd log; it grows way too fast. I started the honeyd daemon with

honeyd -l /var/log/honeypot/honey.log -u 1000 -g 1000 -f honeyd.conf

/var/log/honeypot/honey.log is 1+ GiB log after ~4 hours.

I'm using the following honeyd.conf file:

create default
set default default tcp action block
set default default udp action block
set default default icmp action block

create windows
set windows personality "Microsoft Windows XP Professional SP1"
set windows default tcp action reset
add windows tcp port 22 "scripts/test.sh"
add windows tcp port 135 proxy $ipsrc:135
add windows tcp port 137 proxy $ipsrc:137
add windows tcp port 138 proxy $ipsrc:138
add windows tcp port 139 proxy $ipsrc:139
add windows tcp port 445 proxy $ipsrc:445
add windows tcp port 8008 "scripts/web.sh"
add windows udp port 137 proxy $ipsrc:137
add windows udp port 138 proxy $ipsrc:138
add windows udp port 445 proxy $ipsrc:445

set windows ethernet "realtek"
bind "192.168.1.6" windows

In the logs I can find that it's logging also all packets sent to 192.168.1.2, and 192.168.1.5, which are the other IPs in this Ethernet segment.

Is there any way I can filter what's being logged? I only want to log packets directed to the honeypot (192.168.1.6).

Thanks in advance.

Usually a large number of log entries from a honeypot are from one of two reasons:

Your environment is getting scanned like a smudged barcode.
You made the mistake of putting your honeypot on a non-dark network.

You've configured your honeypot as a pretty typical Windows desktop, so lots of Windows service active, open sharing, etc. What you are likely seeing is just how incredibly NOISY the NetBIOS protocol is. Windows is exceptionally chatty what with the file and print sharing discovery, Workgroup auto-configuration, and my personal favorite...Browser Elections.

Without actually seeing an analysis of your log files, I'm going to guess you're just being flooded by the honeypot reporting all of that Windows discovery nonsense. By and large honeypots are designed to sit on dark networks, that is a subnet in your address space that is otherwise unallocated. They assume that any traffic reaching the system is malicious, or at the very least invalid, and should be reported on.


Is there value in pen testing iOS apps that will operate within a MDM environment? I'm an iOS developer looking to get more in to iOS Pen-testing. To do so I wish to justify the business value for this. I create iOS apps internally for my company which can only be downloaded by employees using our mobile device management application which ensures, phones aren't jail-broken.

Is there value in pen testing applications which are assumed to be in a jailbreak free environment and are MDM applications bullet proof when preventing the business apps that may be downloaded via them from being used on a jail-broken phone?

It's all about risk reduction. MDM and testing cover different types of risk. You need to figure out what risks will be covered off by testing that can't be addressed by the MDM. Think: defense in depth.

For instance, is there info leakage? Are user credentials exposed? Is data accessible from the app to storage so that the user can download? MDM might address some of these issues (depending on how it is configured), but what happens when MDM fails? Or if someone configures the MDM differently for themselves or an exec (gosh, I've seen that too many times).


IR Jump Bag - What kind of bag/container to use? I am working on putting together an Incident Response Jump Bag (detailed here).

Any suggestions on what type of container/bag to use for this?  It seems like a lot of little items that could be packaged together, and some big items.

I have a messenger bag and backpack, but they don't really seem to cut it.

Anything else that I should take into consideration? (chain of custody issues, etc?)

Depending on the amount of kit you require in your jump bag, you may want a wheeled trolley case or a rucksack, to avoid injury (speaking from experience, I once had to implement a wireless honeypot as part of incident response and the kit included 5 laptops (running simulations, logging etc) and my back ached for weeks)

In any case the only real restriction I would advise is keeping it below airline maximum size and weight considerations - putting forensic kit in hold luggage on the return effectively breaks the chain of custody, and if you do have to fly, leave your screwdrivers/multitool at home in case you aren't allowed to fly with it.


Is openssl aes-256-cbc encryption safe for offsite backup I have around 20000 files (around 9GB) each of which is encrypted using openssl enc -aes-256-cbc -in infile -out outfile -k mypassword command. Each file uses same password. My openssl version is 1.1.0e.

Will I be vulnerable to any known attacks if I back these file up on offsite location? If not, what are my alternatives?

You should never use OpenSSL's command line utility for general purpose encryption. It is actually designed only as a test of the library's internal encryption routines. Because of this, there are a few problems inherent in using it when real confidentiality and integrity are needed:

You will be vulnerable to malleability attacks, as CBC mode is unauthenticated. This can allow your files to be modified in certain predictable ways without knowing the encryption key.
No integrity checking means decryption with the wrong key can succeed, despite outputting corrupted gibberish. Utilities designed for file encryption will tell you if the key is wrong.
The default hash used to derive the master key is MD5, which is far from ideal. It is possible to change the hash, for example with -md sha512, but it still will not use key stretching.
New versions may not be able to decrypt previously encrypted files by default. When the default hash value was changed from MD5 to SHA-512, it required an explicit -md md5 to work again.
Both the key and IV are derived from your input password. Using the same password to encrypt multiple files will result in IV re-use. This is bad for CBC mode, and fatal for CTR mode.
It is not well tested. For many versions of OpenSSL, enc using GCM mode encryption worked, but decryption did not. This might even still be the case.

This is not unique to the enc command. The OpenSSL command line utility has other gotchas when one attempts to use it for anything other than testing the library. Another example is the s_client command, used for connecting to a server over SSL or TLS, which does not validate the certificate of the target. Overall, you should not use the OpenSSL utility. Just use GnuPG:

You can use its symmetric encryption with ciphers such as AES256 and Twofish.
It supports key stretching through an algorithm which it calls S2K.
Integrity protection is provided by symmetric encrypted integrity protection and MDC.
It uses the standard OpenPGP message format, making it compatible with other PGP tools.

The only time I would ever use OpenSSL directly is if I needed to encrypt something with a completely random key or a specific raw key and IV and did not care about message integrity. For example, writing a pseudorandom stream seeded by the kernel to stdout can be done with:
openssl aes-128-ctr -nosalt -k $(xxd -l16 -c16 -ps /dev/urandom) -in /dev/zero

Likewise, decrypting a blob of plain encrypted data when you know both the raw key and the raw IV in hexadecimal (bypassing the need for -md for key derivation) could be done with:
openssl aes-128-cbc -d -nosalt -K $hex_key -iv $hex_iv -in infile -out outfile

But for general-purpose file encryption? Just use GnuPG.


Further potential problems with Windows 8 SmartScreen Some research was recently published that showed that Windows 8's SmartScreen feature sends certain details about every single application that you install to Microsoft.

Ignoring the obvious privacy violations, what other security issues might this cause? The article touches on some SSL issues, but says that they haven't been verified to be vulnerable.

Actually the article does not say that the SmartScreen client uses SSLv2; it just says that the server which SmartScreen contacts would be happy to accept incoming connections using the SSLv2 protocol. It would be surprising if SmartScreen indeed used SSLv2: most plausibly, Microsoft reused their own existing code for a SSL client, and that code does SSLv3+ by default. Using SSLv2 would imply extra effort for no gain.

Also, most of what is said about security of SSLv2 (in this article or elsewhere) is covered with a heavy layer of FUD. SSLv2 has issues, sufficient to warrant not using it (especially since SSLv3 and TLS are available), but not as dire than what is usually suggested. See for example this page; it is claimed that:

  Message integrity compromised. The SSLv2 message authentication uses the MD5 function, and is insecure.
  Man-in-the-middle attack. There is no protection of the handshake in SSLv2, which permits a man-in-the-middle attack.
  Truncation attack. SSLv2 relies on TCP FIN to close the session, so the attacker can forge a TCP FIN, and the peer cannot tell if it was a legitimate end of data or not.
  Weak message integrity for export ciphers. The cryptographic keys in SSLv2 are used for both message authentication and encryption, so if weak encryption schemes are negotiated (say 40-bit keys) the message authentication code uses the same weak key, which isn’t necessary.

The first point is downright FUD. It is a knee-jerk reaction: "MD5 ? BAD BAD BAD !". It is unsubstantiated. I am not saying that MD5 is rock solid; but I claim that the integrity check in SSLv2 is not that easy to defeat.

The second point is, at best, confusing and misleading. The "man-in-the-middle attacks" which are alluded to are the following: in SSL (v2, v3+...), both client and server may support several cipher suites; the client sends the list of suites it supports, and the server chooses one. With SSLv2, an attacker who is in position of doing a MitM can alter the list sent by the client, to force the client and server to use a specific cipher suite (within the set of suites that both supports, of course). The alteration is not detected later on (whereas, in SSLv3+, it would be detected at the end of the handshake). Then, the reasoning goes, SSLv2 is weak because the attacker can force client and server to use a "weak cipher suite" (e.g. one with 40-bit keys). But can it ? In fact, the attacker can force the use of a cipher suite that both client and server were already ready to accept -- and THAT is the weakness. What the attack breaks is the optimistic upgrading to stronger cipher suites when available; but the real weakness is when client and servers accept to use 40-bit keys.

The fourth point is more of the same: it says that if a key is weak and used for two usages, then breaking the key allows attacking the two usages. But the true weakness here is using a weak key.

Only the third point is really true: an attacker can force a connection close, and the machines cannot know whether the closure was intended by the peer. This is a serious problem with HTTP/1.0 without Content-Length attribute but not with other protocols, including HTTP as it is used nowadays.

Summary: SSLv2 is "broken", but not as much as is rumoured. No, a SSLv2 connection cannot be instantly decrypted by an attacker. And I personally deem it highly improbable that the SmartScreen client uses SSLv2; it would make too little sense.

(None of the above says anything about privacy issues with SmartScreen.)


Verifying factory reset on phone? I have some old Android phones that I'd like to recycle, but obviously I want to wipe them before doing so.  While I realize it's unlikely anyone will attempt a forensic recovery on my phones after even a basic factory reset, it got me to wondering how a user can verify that a factory reset erased their data.  All of the research I'm aware of involves "chip-off" forensics, which isn't practical for most users.  (Or even myself for fine-pitch BGA flash.)  Is there any way for a user to be "reasonably certain" about the efficacy of a factory reset in protecting their data?

I'm particularly wondering about devices not from a flagship line.  I imagine Google Nexus/Pixel, Samsung Galaxy, etc. devices have well-designed erase (probably by always encrypting data then destroying the key), but a lot of users may have phones made with firmware that is less well-designed.

Note that this differs from How secure is wiping an encrypted Android device? because I'm looking for information on verification, not information on the proper design.

If you don't trust the device manufacturer without a full hardware and OS audit you can never be certain. For all you know the device could have cached the encryption key in a separate piece of flash buried under another chip on the board - or even a full clone of the user space.

I would be surprised if any modern android device is using non-standard android encryption. If they are if anything its likely to be a flagship device with an unusual hardware encryption module. So the odds are if you can verify this then the question falls back to do you trust google/android and the prior question you referenced - How secure is wiping an encrypted Android device?.

If the device is using non-standard encryption you need to ask yourself why do you not trust the manufacturer. Are you expecting malicious behavior or incompetence? If you are expecting a malicious manufacturer then it is already end game. For all you know they have been transmitting your personal data away from the device throughout its use.

For incompetence there are ways to reassure yourself. For example write random data (to avoid any risk of compression) to the device until full. Then read this data back and compare against what was written. If they match you can be reasonably confident the full disk space has been overwritten.

There is one possible caveat. Flash memory has a limited lifetime. As it degrades the device can detect this and decommission certain blocks. Without modifying the storage control firmware decommissioned blocks will no longer be readable/writable to - meaning for older devices there is risk that old data is still contained and available to a determined opponent with access to a forensics lab.

However the odds of randomly decommissioned blocks containing useful confidential information - especially on a priorly encrypted device - is extremely slim. For any individual that does not consider themselves extremely high risk (and if you are you aren't going to be worrying about this - destroying the NAND chip is going to be a far better option than the second hand value of the device) I'd argue there is very little point considering this.


How to mitigate the risks of using new, third party imported electronic accessories? As someone who is naturally good at recognizing risk and who are striving to maintain a wholistic view on security, I’m wondering how to evaluate and reduce the risks of hardware accessories (I.e. charging plug-ins, Thunderbolt cables), specifically peripheral or generic devices imported from a company other than the manufacture of the primary device (I.e Apple).

Obviously, any time you use third-party hardware there is some small degree of risk they contain physical or digital spyware. This is true 100% of the time unless you built the hardware yourself. There are cases of physical and digital spyware in both big-name U.S. manufacturers and foreign manufacturers.

It’s usually safer to order an electronic accessory such as an iPhone charger directly from the manufacture, and the risk increases when using third parties and further with resellers.

I’m not sure how large the risk when using a third-party iPhone charger is, but it’s a serious enough risk if you’re serious about security that you should at least recognize it since it will have physical access to your phone, and potentially to your computer and whole network. The obvious risk is that it could install rootkits, I’m sure there could be more.

What are the risks of using third-party electronic accessories and how do we mitigate them?

The risks of buying compromised hardware to spy on a common user is grossly overestimated. By several orders of magnitude. The absolute majority of security personal on all the world will die before being able to see such a thing on his hands. Way more people will die by lightning hit than those hit by Lightning-of-the-death cables.

First: compromising hardware is expensive. Adding additional gear to spy on you while maintaining all original functionality takes time, skill and resources, so the creator of it will not dump crates full of compromised Lightning cables on Aliexpress to sell everyone.

Second: the exploits are precious. Very precious, and the value of any exploit decreases every time it is used. If someone abuses the exploit and uses lots and lots of compromised hardware, security solutions will start to detect and alert users, turning the compromise ineffective on the long run.

Third: there are easier ways. There are lots of cheaper and more effective ways to compromise our systems, so hardware modification is so down the list that we can care about all the other ways first: phishing, hole watering, drive-by downloads, DNS manipulation, vulnerable firmware, and the list goes on. Those attacks are way cheaper, and more effective.

How to mitigate such risks? Don't buy obviously fake hardware, or vastly cheaper versions, keep security systems updated, and take care of external devices connected to the network: tablets, cell phones, and so on. Common day-to-day security advice.


Are password and username revealed when server ip and domain ip are equal? Using plesk, I run some cron jobs with domains on my own server, ie for instance

https://username:password@domain.com/cron.php

The ip of my server is the same ip of domain.com.

Will others see username and password?

If yes, how do I run the cron.php which requires username and password from within the server?

If the domain resolves (on that host) to one of the IPs attached to an interface on that host, then the traffic will remain within the host.  However, should you add a CDN (Cloudflare, etc.) at some point in the future, then your traffic will go out over the internet to the CDN before coming back to your backend.

If you're using a proper implementation of HTTPS (as implied by the URL in your example), then the username and password are not revealed even if the traffic traveled over the network.  (Unless using an SSL-terminating CDN, but you'd already be putting a lot of trust in that CDN.)


Are there any systems to mitigate the risk of losing a Signing Key? I want to design a system that hinges on ECDSA. All messages are signed using the algorithm, and this is used to prevent spoofing.

However, if a user were to somehow lose control of their key, they would be forced to create a new key to sign their messages.

Is there any mechanism that can be implemented to transition people to the new signing key securely and automatically? Additionally, how could one "revoke" the old key?

Both PGP and the global SSL PKI solve this problem in roughly the same way. You create a super "trusted" key with a long expiration which you guard with religious fervor; key stays encrypted, tucked away in a holy temple, only ever glimpsed by duly anointed CSOs, that sort of thing. It's the one you trust. You do not use it.

Then with that key, you sign your "every day" key. It has a relatively short expiration, but you follow best security practices with it nonetheless. Still, it goes where it is needed to go.

When you ever suspect that the "every day" key may have been compromised, you revoke it and sign a new one with the holy temple key.

Revocation is as simple as keeping a list of revoked keys (probably their hashes) in a globally visible location. That list should be signed. When someone checks whether to trust a key, they check the key's signature path up to a trusted root. They also check the revocation list.

Performance of key revocation checking is an issue, but if your key infrastructure is small, you can easily have only one global revocation list which you push to everyone on a regular basis.


Partially controlling LDAP BindDN parameter In an application I was assessing, I found an interesting piece of code that took my attacker-supplied input and put it into the bindDN while preparing to connect to an LDAP server.

[USERNAME]@domain.com

Specifically, I can inject whatever I want into the [USERNAME] in the above sample bindDN, including something like testusername@anotherdomain.com@domain.com. I do not control the LDAP URL though. Is there anything risky security-wise with this small bug?

The following points are worth considering in any attempt to leverage this, though I don't believe anything except attempts at denial of service would work.

Where LDAP URLs are used, these do not support in-band credentials in the URL, as the (now deprecated) method that HTTP URLs used "http://user:password@host/". There should be no way to inject a malformed bind username into such URLs (typically used for search queries) to alter their effect. However, some directory implementations support non-DN usernames in a bind operation — specifically Active Directory (userPrincipalName); or OpenLDAP with SASL and/or olcAuthIdRewrite/ olcAuthzRegexp. If OpenLDAP is configured to take a non-DN bind username (in the form of an email address or uid @realm), or otherwise uses the rwm overlay to rewrite in bindDN context, and formulates an LDAP search URL to determine the real user DN, this will only be as robust as the administrator's rewrite instructions, and could be subject to injection of malformed usernames. This is fairly unlikely, and probably very difficult to do blind (without being able to inspect the rules). I suspect it's simply an AD backend here though.

On the wire, the bind request will be a DER encoded structure of the form

 0   53: SEQUENCE {
 2    1: . INTEGER 1
 5   48: . [APPLICATION 0] {
 7    1: . . INTEGER 3
10   33: . . OCTET STRING
       : . . . 63 6E 3D .. ..            cn=user,ou=...
45    8: . . [0] 'password'
       : . . }
       : . }

An anonymous bind will already have been created, establishing the connection. Unless there is some horrible bug in the underlying ASN.1/LDAP library (e.g. to let you formulate a username with a DER parseable trailing password of your choosing, for brute force) then the best you can probably do is exercise the parsing, escaping, or UTF-8 encoding layers, or determine the maximum size of a DN (not defined by LDAP schema).

The best you might be able to achieve is:

denial of service, possibly through the use of very long or dubiously escaped/quoted usernames
lockout of an arbitrary user - assuming the directory implements this, e.g. AD policies, and the directory service is not otherwise accessible (in which case it's probably trivial to achieve in other ways)
attempt to enumerate other users in the same domain/directory, how practical  this will be depends on feedback during the authentication attempts (see this for LDAP error codes)
attempt to find another user with the same password as this user (though how that might be useful, I don't know)


Table or row level security in ASP.NET MVC 5 and Entity Framework 6 I've already asked this question on Stack Overflow, but no one answered, so maybe it's a more appropriate place to discuss it. Please let me know if I'm wrong and having duplicated question on different networks is not acceptable.

I'm using ASP.NET MVC 5, Entity Framework 6 and SQL Server 2008 to build my Intranet web application. Two security needs have been assigned for this project and I'm not able to change them.

Application logins to database should be permission limited. Remember it's an Intranet app and will be installed on customer's server. They'll have the database login but still we don't want them to be able to mess around. The suggested approach to implement this requirement was to use database logins for app authentication. In other words, every user will have his or her own database logins. App doesn't have any default login, so when user tries to login into app, authentication controller tries to use that login credential to connect to the database. On success, user will be authenticated into the application, otherwise the login action will fail.
Authorization at row level. Each user and therefore database login will have not just limited permissions on tables but also on rows. I think I can implement this need in the app alone and forget about the database.

I'm so confused, any guidance and personal experience about these requirements is welcome. I think I need to have an authentication system that works this way and is able to use database logins. Can I override MS Identity? And what else does this project need!?

I will post an alternate solution to the one that is proposed in MSDN's "Granting Row Level permissions in SQL Server": https://msdn.microsoft.com/en-us/library/bb669076%28v=vs.110%29.aspx.

In my solution, you have a meta table for each table where row level permissions are required. I like to call that meta table as an ACL (Access Control List) table. So as an example, your target table is called Contacts, then you create another table call Contacts_ACL. Now in that table, I put in Contact_Id, User_Id and Permission (or Permission_Id if we have a separate Permissions table).

create table Contact (
    contact_id INT PRIMARY KEY,
    ...
);

create table Contact_ACL (
    contact_id INT REFERENCES Contact(contact_id),
    username varchar(100),
    permission varchar(20)
);

I do this because I feel Stored Procedures is an overkill for something that is very simple (authorization). It also imposes additional code maintenance as everything you change the base table, you have to change the views and the stored procedures.

Here is an example LINQ Query to retrieve stuff:

from contact in Contact
join acl in Contact_ACL on contact.contact_id equals acl.contact_id
where acl.username == <username>
select new {
    contact.contact_id,
    ...,
    acl.permission
}


Character escape sequences for ">" OWASP gives all character escape sequences for "<". Where can I find a similar list for ">"?


Pattern based password cracking I need to select a project for this semester. I'm a second year uni student in Ethical Hacking and Countermeasures. My idea was to see if using some kind of pattern based password cracking can be more efficient than standard brute forcing or dictionary attacks.

By pattern-based cracking I mean something like:

CvvcDcv

where C is uppercase consonant, v lowercase vowel, D digit and so on. I would use lists of actual leaked passwords to generate a list of most likely patterns and code a little program to brute force it's way through the list based on the patterns. The above pattern would result in something like:

Baab1ba
Baab1be
Baab1bi
...

I've been trying to research if/how this was done before. However I'm unable to find any information. I think I'm using the wrong terminology for my searches.

What would this kind of cracking be called?

Is this likely a dead-end or is it possibly a (more) efficient way of attempting to brute force passwords?

(Alternatively, and I fear this might be off-topic, what are the 'newest' and promising methods of cracking passwords in 2014, if there are any? Anything worthy of doing research in?)

EDIT:

I've started generating the pattern list, if anybody is interested you can check the list here:
http://mayar.abertay.ac.uk/~1204925/temp/list.txt
So far it's generated using only a list of passwords leaked from Hotmail a couple of years ago. Will have a complete pattern list in a few days if anyone is interested, using 100'000s actual passwords

What you're talking about sounds similar to what John The Ripper and Hashcat offer with rules based password cracking.

This essentially defines a set of rules to generate passwords rather than relying on straight brute-force.  There more information on the hashcat site or the John Site

There's probably some interesting work to do there in comparison of various rules options and different password dumps..


Should every post request include csrf token? What is the vulnerability level if the anti-csrf token is not sent with every post request? (If the vulnerability levels were high, medium and low). I understand for critical functions like login etc you would need to include csrf token.

What factors should I consider when deciding whether or not to implement CSRF for each set of permitted requests in a web app?

Update: I found this article here that explains need for csrf token for each request
It is interesting that more and more web apps are considering it for each request.

If the POST changes state on the server then not including a csrf token leaves you vulnerable. The level of risk depends upon the specific functionality served at that URL if the attacker abuses it with a csrf attack.


How is hashing safe if a given string always generates the same hash? I am a newbie to hashing, and I understand that MD5 (I know it's broken) and SHA-1 are all fixed hashing algorithms, but given that most passwords are dictionary words or other similar passwords, what's the point of storing it in a hash if an attacker can use Google to backtrack the original password?

I mean, isn't SHA-1 or SHA-2 or any of those algorithms rendered useless?

This is why you need to use a salt.

Adding a globally unique salt to each password ensures that even if every password is the same, they will still each generate unique hash values.

That said, a single iteration of SHA-1 or SHA-2 is still not a good way to hash passwords, because they are too fast.  Even with a unique salt, modern hardware is capable of hashing billions of candidate passwords each second to find the inputs.   A good slow algorithm such as bcrypt with an appropriate work factor should be used instead.


What kind of privacy leakage do stuff printed to stdout pose? 1- When a program outputs to stdout, is that normally logged anywhere else?

2- When is it an issue to make a command verbose in printing to stdout instead of working quietly or redirecting to a file?

Printing to stdout is pretty safe, since it's not logged anywhere by default. The data will be lost when the console session dies, though bits might end up remnant in memory. Piping to a file is a different issue, since once it hits disk it might end up being left on slack sectors.

Keep in mind that the command itself will usually be logged into your bash history. You can clear this using history -c, or you can stop the command from being logged by prefixing it with a single space. Commands prefixed with a space aren't stored in your bash log, and aren't kept in your session's command history.

If you're really worried, just pipe it to /dev/null and it'll be immediately discarded.


What fuzzy hashing algorithms exist? I have been trying to find information on fuzzy hashes, and I have found surprisingly little.

I know that fuzzy hashes can be used to detect if a piece of malware has changed slightly. I would rather not develop my own algorithm since that seems like a terrible idea.

I found ssdeep which looks interesting, but I don't see any alternative.

Are there other fuzzy hash algorithms? Does anyone use these?

Here are a few other "fuzzy hash" algorithms:

Nilsimsa: was developed for email spam detection. However it results in more false positives then some others.
TLSH: (https://github.com/trendmicro/tlsh) A Trend Micro fuzzy hash.
Sdhash: another fuzzy hash like algorithm. http://roussev.net/sdhash/sdhash.html

These are used for several things. One is to forensically locate similar files. Another is to identify malware, even if some of the code is changed. A third use is in spam detection


How secure is using MD5 for signature Generally speaking, MD5 is considered as broken for secure usage these days, but I came across a signature design using MD5 many times recently in my company. The detail shows as following:

T = text, which is directly viewable as plain text in a HTTP header.

AppId, AccessKey = ID and Key pairs authorized from server. The ID is also appended as plain text in HTTP header.

signature = MD5(T || timestamp || AppId || AccessKey)

My question is how secure is this signature design? I've searched for many sorts of collision attacks, and the closest one to this condition is the chosen prefix attack, which seems still hard to effectively exploit this signature.

Any idea would be greatly appreciated.

MD5 is broken in the sense that it is possible to create two pieces of data with the same hash. However, you need to be able to modify both pieces of data.

For example, you can create two images with the same MD5, by manipulating both images. Then if a user or system checks only the MD5 of the file, you can swap the images and the MD5 remains the same.

In your example, it would be possible to create two texts that have the same signature, for an attacker that has a AppId and AccessKey. I don't think that breaks the security of the system, but that depends on how the signature is used.

It is not possible to create a file with an arbitrary MD5, or to find the original data from an MD5 hash by a method other than brute force. So if they keys used in your example are long enough, it is secure against an attacker that does not have an AppId or AccessKey.

However, because MD5 turned out not to be collision resistant it is no longer trusted by many people to be a good hash function. It has a bad reputation and isn't considered suitable for any use. So if you develop a new system, don't use MD5 (or SHA1).


Logging access tokens In our REST API we write a log entry for every call made, including things like the query string, response code, duration etc... along with a SHA256 hash of the access token used. The thought process behind this is that the hashed values still lets us correlate API calls (e.g. these 5 calls are all made with the same access token), however even if an attacker obtains the logs there is no way for them to reverse the hash and obtain a usable access token. Is this reasoning sound?

SHA256 is still a secure hash.  As a result the main concern is someone trying to bruteforce your access token.  SHA256 isn't a slow hash so depending on how much entropy your access token has, this may be a valid concern.  You can calculate the cracking time from the amount of entropy versus the hashing rate the attacker can achieve.  As it turns out, SHA256 is what bitcoin uses so hashing rates for various setups are readily available.  For non-specialized GPU hardware you can roughly estimate a hash rate of 1GH/s (1,000,000,000 guesses per second).  Let's take that and run through two extreme examples of the entropy of your access token:
1. Access token is a simple permutation of creation time + user id.
Ever seen something like access_token = md5(time() + $user->id)?  Things like this are surprisingly common.  If an attacker knows the id of the user they are trying to attack (which is likely since it may also live in the logs) and know how your access tokens are created, then they just need to guess the account creation time.  Even if the creation time includes microseconds, this is still extremely easy to guess.  At a rate of 1GH/s and given a fixed user id, you could brute force all creation times over a decade in a second ((86,400,000 possible hashes/year) * (10 years) / (1,000,000,000 hashes/second) = ~1 second
This access token has no security from brute force at all.
2. Access token is a GUID
Alternatively, your access token may be a GUID.  These typically have 128 bits of entropy or roughly 3.4e38 possible combinations.  This means that bruteforcing one would take: 3.4e38/1e9 = 3.4e29 seconds, which is approximately 10,000,000 times the age of the universe.
This is absolutely safe from brute force.
Another option
Finally as a different suggestion (which may not be applicable) is to store the id of the access token, presuming that it is stored in the database and therefore has an associated id.  After all, the access token is the sensitive part, but the id of the access token is just as useful for tracking and (normally) not sensitive.  Of course if you aren't storing your access token in a database (for instance, if you are using a JWT) this isn't possible.


My bank's homepage is on http. No SSL. Isn't it trivially easy to MITM+change links & get login credentials? The homepages of several banks are available over http. Some have search engines linked to http.

This, it seems to me, makes their users trivially vulnerable to MITM attacks if they visit the bank over e.g. public wifi.

This, it further seems to me, means that bank account security is depending on  “I hope they only access their bank accounts from secure home networks” <crosses fingers>.

It looks to me that for an outlay of (1) a wifipineapple or other Evil AP device and (2) a $fewhundred to pay someone to customise SSLStrip with fake versions of 3 or 4 specific bank sites, I can:

Go sit in a shopping mall for a couple of days with the pineapple
Collect entire traffic user<->bank
Take over sessions and start making payments

i.e: easy-to-mitm-public-wifi + easy-to-spoof-http-homepage => easy to hack.

What have I missed—it can't be that easy and cheap to hack bank accounts, can it?

————————————————————————————————————————

PS I raised a complaint with my bank and they called back to point out that the login page asks me to install https://www.trusteer.com/ProtectYourMoney (an IBM product) which apparently addresses this kind of attack by closing down the browser.

Also that I should not use the search engine to find their website. But I suppose once you've stolen a public AP, DNS poisoning is simple too

On websites that experience large amounts of traffic (e.g. consumer sites, like banks) administrators have decided to use mixed plaintext HTTP and HTTPS implementations.  Typically, HTTP is used for public information, and the switch to HTTPS occurs when accessing private resources such as a login screen.

This practice largely came from the days when SSL (now TLS) encryption/decryption was costlier (1990s and early 2000s) from a CPU perspective, and could severely slow down page load times.

Now, with faster CPUs more adept at using hash algorithms like SHA256 and encryption ciphers like AES, this problem is less obvious.  However, if you're running a large-scale web server receiving thousands of hits a minute, the administrator will surely notice TLS traffic vs non-TLS traffic in terms of CPU utilized.  The plaintext site will require less CPU and IT maintenance overhead, and in turn cause a savings to the organization in terms of hosting expense.
Additionally as pointed out in a comment by @mgjk, the costs of certificate management between bank IT departments (business versus personal, trading vs other commerce, WAF and DDoS mitigation layers that need to be able to do SSL decryption, etc) is also significant and cumbersome in a large organization, and can lead to a reluctance on the part of management to roll out a TLS-only site.

Thus many banks continue to leverage mixed HTTP and HTTPS web sites.  New best practices are being developed to control for problems and attack vectors present in this setup, notably "SSLStrip" style MiTM attacks.  Control measures include use of HSTS headers, and are making headway to banks -- but have yet to achieve wide-scale commercial implementation from these large, generally risk and change averse entities.

As far as the specific situation you describe with a WiFi Pineapple as an Evil AP, this would be possible if you stage an "SSLStrip" attack, or another man-in-the-middle attack.

However, many banks take measures to protect against session hijack attacks -- notably expiring the session quickly. If the device had visited the site before and it sent HSTS headers, an error (perhaps enough to scare the average user) would surely result.  So, the attack scenario you describe is a bit simplistic and would require a bit more sophistication before being viable against modern bank web site implementations.

However, yes, when banks don't force the use of TLS with HSTS and certificate pinning, a large attack vector is opened up similar to what you describe -- and this practice should be phased out!


Now that CloudFlare offers potentially-insecure free SSL to all users, would a new HTTP header be useful? I'm not sure where to post this, so I figured I'd just post it here.

CloudFlare is now offering free SSL to all sites. There are two different types of SSL connections, however. There's "Flexible SSL" which runs HTTPS on the Client <=> CloudFlare connection, but regular HTTP on the CloudFlare <=> Server connection. While this is certainly better than nothing, it's misleading to the user who thinks that his or her data is entirely encrypted for as long as it's on the wire.

There's also "Full SSL" which is secure for the entire User <=> CloudFlare <=> Server connection.

Therefore, I propose a new HTTP header named something like X-Proxy-Security which could indicate to the user-agent how the proxy is handling secure connections. Its value could be something like end-to-end for full end-to-end encryption or client-to-proxy for connections that are only secure between the client and the proxy. The header ideally shouldn't contain any specific CloudFlare references since there are plenty of HTTP proxies like CDNs and services similar to CloudFlare.

If it were implemented, browsers wouldn't know how to handle it at first so nothing would change. However, browser extensions could be developed to relay the status to the user. Browsers could eventually implement some form of indicator similar to how they indicate mixed content or whatever currently.

Would this work? How would we push to implement it?

This is part of why you check who the SSL cert is from.  If it isn't the site you are trying to access, get the hell out of dodge.  If cloudssl is using a root certificate in an insecure way, such as generating certs for each site on demand, then people can simply reject the authorization of that root certificate.  Problem solved.

A new http header for this is not helpful, is overkill and would still be open to abuse as nothing guarantees that someone would properly set it.  The same level of detail could just as easily be included in the certificate itself without need for new headers.


Will deferring password choice until after account activation improve security? About one year ago, for about two months, lots of user accounts with unverified login email address started to pile-up.

All addresses belonged to @yahoo.com. It appears (don't know for sure) some sort of Yahoo! Messenger vulnerability allowed some hackers to spread to many systems and then create accounts on our website.

Some users clicked on the activation link, although the email was correctly informing not to take any action if they did not request an account.

The only thing that could be deduced as usefull for the attackers, was that they knew the passwords for the new accounts, and were hoping to create as many accounts as possible (from different IP addresses) with an automatic effort from different locations, while avoiding captchas or other rate limiting protections.

This same type of attack can be used to impersonate someone with elevated access to some services (me thinks).

The only protection I can think of is asking the user to choose a password after clicking the account activation link, which will also perform auto-login. To create an account, the user will only be asked for his email address.
I haven't seen this done anywhere else at all, is there a security drawback I am missing?

So if I'm reading your question correctly, you're concerned about attackers creating accounts using e-mail addresses they did not own.

The first question would be "why is this a problem?" I'm guessing that only a small percentage of the people who's e-mail addresses were mis-used would have clicked a sign-up link for an account they did not request?

Also it's generally possible for anyone to create an account on a site which just requires a valid e-mail address.  If you have your own domain name you can use [anything]@domain.name for as many accounts as desired and also there are services which provide temporary e-mail addresses explicitly for the purpose of signing up to things.

If the problem is that you don't want these accounts cluttering up your system, then I'd suggest that the best way to prevent it is to make them take some action after they click the link in e-mail, before you activate the account.

For example ask them to log in with the credentials they used to sign-up, and tie that to the one-time code in the link.


Resume VPN after hibernation (sleeping mode) vs real IP detection Imagine I am using VPN service app on my PC and I am logged into a website. Then the PC enters sleep mode.
Disconnection sequence of sleep mode I suppose: first browser, second VPN. And for re-start mode: first VPN, second browser.
When the PC wakes up, will the VPN start first? Is there any way the website can register my real IP? Or just once my PC is being re-started during any of this disconnection/connection process?

It is possible that the VPN could become disconnected during the resume, and traffic could be sent by the browser without using the VPN. This behavior may be unpredictable, but if revealing your true IP address is undesirable (i.e. part of your threat model), you will want to defend against it happening.
A common way to mitigate this is to create firewall rules that prevent non-VPN traffic from leaving your computer. Some VPN  applications may provide a similar option as a feature.


Using VPN on Android, Necessity of Rooting I have just gotten a new phone and would like to protect my privacy better than I have in the past. I have read about rooting and then installing OrWall, OrBot, and OrWeb. If I understood correctly, OrWall, which is the only app requiring rooting, forces all apps into Tor.

I would love to avoid rooting the phone, and therefore I am considering VPN. If there is no logic in that statement, it's because of my lack of knowledge.

My question is: Would using VPN make everything, including app usage, anonymous, or just browsing?

Also, would I achieve a higher privacy level if I root my phone and then use VPN?

Edit: I have a HTC ONE M8s

The Or apps use the Tor network, which is different to a 'normal' VPN.
You don't need to root your phone to use a VPN. Check out VPN providers such as Anonymous VPN or Express VPN.
Yes, when connected to a VPN all of your data is transmitted through the VPN connection. In regards to anonymity, it's best to do some research on VPN providers before choosing one. Many VPN providers keep logs and will provide these logs to enforcement agencies if requested.
Rooting your phone alone will not offer a higher level of privacy.


Is Skype secure enough to transmit passwords? Is it considered "secure" to send a password in a skype message and delete the message after the recipient remembered the password?

Questions I would ask myself before using skype for sending sensitive information:

Is the encryption truly end-user to end-user or is the data only encrypted between the user and Skype (thereby potentially giving Skype access)?
How are IM logs managed? Can you be sure that you have 'deleted' the password from the log?
Even if logs are not being stored to disk directly buy Skype, is the memory Skype uses for this non-pageable? i.e. could the password be placed into a page file without you being aware and hence become retrievable for local users?

Before satisfying these questions my own answer would have to be no.


What are the privacy implications of the "Your Phone" app on Windows? I'm trying to decide whether or not to use the Your Phone app on Windows, and not finding much information on it.
It requires a Microsoft account, but I don't really see why that should be necessary for a local connection between my phone and my computer. It makes me wonder about the privacy implications.
This page claims the following, but I find it unsatisfactory:

Your Phone relies on local connections through Wi-Fi (the iPhone also needs Bluetooth), but the system never takes your data and stores it on Microsoft's servers. When disconnected there is no maintained data, but rather a local cache on the user's PC for some items.

In particular, "relying" on local connections and not "storing" it on Microsoft's servers is not the same thing as "never sending data over the internet" to begin with. What I want to know is if they transmit any of my phone (or PC's...) data over the internet in the first place, or whether all data stays local to my network. If they send some of my data over the internet but promise not to look at it, that is not the same thing to me as not sending it in the first place.
So: does the app send any kind of data from my phone over the internet (except my login credentials, obviously)?
Is there a way to ensure it keeps all my data within the LAN (whether it's app data, SMS, call, whatever)?

Your data is sent to the internet, yes.
I think that the connection phone-app that "your phone" does is somehow similar to Whatsapp Web's, your data is sent to the internet and received from your computer, but not stored anywhere.
You can test this, try to connect with the phone connected 4g and your PC on Wi-Fi. It must work.


What are the security implications of systemd compared to systemv init? I'm just beginning to learn about the init system, so I only know about the high level characteristics of both.

I have noticed a lot of fuss over systemd, even some people claiming that systemd was created to purposely introduce vunerabilities!

The argument I see most often is that systemd introduces a new, large (and unfamiliar) attack vector. On the other hand, it seems to me that a system like systemd is actually a good thing because it is standardized code as opposed to ad-hoc init scripts. In this respect, I see similarities to the kernel. Sure, everyone can create their own easy to read OS, but is it not better to reuse the same code so that a large number of eyeballs are monitoring it?

Am I on the right track here? Are there issues I am not considering?

(mostly) people don't inject vulnerabilities deliberately, they occur by accident. As the volume of code increases, the number of defects increases. But its not just size - the number of bugs increases with the complexity of the code and it increases faster than linearly. So more code is bad news for security.

The attack surface of systemd is massively larger than initd - the default configuration has multiple interfaces.

A big annoyance for me is the design philosophy; the intention is that systemd provides a more unified way for distributors to integrate services. But this means removing control over the system from syste admins (over and above the impact of replacing a complex but well understood eco-system). It deliberately makes it hard or impossible to achieve thing which could be done with initd (note that there are many options for service managers running under initd - djb daemontools, upstart, initng, rund, procd, openrc.... Most of which solve the paralellization / dependency problems that limit the sysv rc init system).

A lot of the logic of the start up of a unix system is implemented in shell scripts. This makes it much easier to not only reverse engineer the operation but also to instrument it and extend the capabilities. Systemd moves more logic into binaries and relies more on a complex and poorly documented configuration.

The combination of deliberately reducing the level of control by the system administrator and failing to support the system administrator in their task makes it more difficult for them to do their job - which encompasses assuring the security of the system.

A further consequence of all this complexity in PID 1 means that you should have to reboot your system a lot more frequently. In addition to the impact on availability this also means moving your system through a series of interim states - which can temporarily expose vulnerabilities which are difficult to detect on a homeostatic system. Using daemon-reexec to work around this brings a new set of problems.

The benevolent-dictator-for-life model seems to work well for the linux kernel, but that is not how the rest of the open source industry operates. Indeed it is perhaps the exception which proves the rule - that open source works because nobody is in charge, not despite nobody being in charge. Systemd assumes control over a lot of the functionality in a linux system, yet it operates as a relatively small community. And as per the pwnie award it appears to be somewhat inward looking: there are not a lot of eyeballs on the code: nobody is listening when concerns are raised about the code.


How can an email from a Yahoo address be sent through Yahoo without authentication? I received this bounced email, yet I have a password with 105 bits entropy, my sign in history only shows local sign ins, I do not have any linked accounts nor apps, and I have not been to GermanyDenmark.

Received: (qmail 90091 invoked by uid 102); 3 Apr 2014 21:27:50 -0000
Received: from unknown (HELO mtaq2.grp.bf1.yahoo.com) (10.193.84.33)
  by m9.grp.bf1.yahoo.com with SMTP; 3 Apr 2014 21:27:50 -0000
Received: (qmail 11784 invoked from network); 3 Apr 2014 21:27:50 -0000
Received: from unknown (HELO smtp1.cybercity.dk) (212.242.43.251)
  by mtaq2.grp.bf1.yahoo.com with SMTP; 3 Apr 2014 21:27:50 -0000
Received: from uf9.cybercity.dk (uf9.cybercity.dk [212.242.42.52])
    by smtp1.cybercity.dk (Postfix) with ESMTP id 5DAD010881D;
    Thu,  3 Apr 2014 23:27:50 +0200 (CEST)
Received: from vip.cybercity.dk (unknown [197.160.61.185])
    (Authenticated sender: dsl366676)
    by uf9.cybercity.dk (Postfix) with ESMTPA id 0E24F3F414;
    Thu,  3 Apr 2014 23:27:37 +0200 (CEST)
Message-ID: <002d8c496c08$3a6ab066$aa7d9632$@yahoo.com>
From: Chloe <xxxxxxx@yahoo.com>
To: "tiwana13" <>, "sammy" <.com>, "nyccf business" <.com>, "larissaschwartz" <.com>, "red diamond deals" <.com>, "rharmon" <.com>, "pattonjtp" <.com>, "costanz" <.com>, "colleen mac15" <.com>, "A1HomeImprover" <.com>, "Complaints" <.org>, "kk" <.com>, "mavrickn" <.com>, "rajat" <.com>, "underthehood" <.com>, "madelynballester" <.com>, "NYLAUNDROMATS" <.com>, "deal analysis nyccf" <.com>, "charles cameron" <.com>, "mdaney01" <.com>
Subject: Fw: News
Date: Wed, 3 Apr 2014 10:27:37 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
    boundary="----=_NextPart_000_5E55_7BD63691.616F00EF"
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 16.4.3522.110
X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3522.110
X-eGroups-Remote-IP: 212.242.43.251
X-eGroups-Remote-IP: 10.193.84.33

This is a multi-part message in MIME format.

------=_NextPart_000_5E55_7BD63691.616F00EF
Content-Type: text/plain;
    charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello! News: http://sigortasirketim.net/kfb/view.php
      =20
Chloe       =20

------=_NextPart_000_5E55_7BD63691.616F00EF
Content-Type: text/html;
    charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello! News: =
http://sigortasirketim.net/kfb/view.php

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =

Chloe&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;

&nbsp;

------=_NextPart_000_5E55_7BD63691.616F00EF--
Thread-Index: AXSzUC5+hzg0azlseGxkcnAwNzZ3cw==

The important thing to remember about email and email addresses is what can be set by users and what can't be set.

The To: address is set by the user and can be though of as the name and address that you put on the top of the a written letter that you might write. The From: address is the address that you would put in the upper right hand corner of that page.

But, notice that letters are mailed in envelopes, which may have different addressing information on the outside (the return address on the outside does not have to match the address on the inside). Mail clients usually show the address from the top of the letter (not the addresses on the outside of the envelope). The one thing that you can't control when sending a piece of postal mail is the cancel stamp (which has the name of the city that canceled it). All of those Received headers can be though of as cancel stamps as the email moves from system to system.  Looking at those headers you can see the traffic flow:

vip.cybercity.dk (Authenticated sender: dsl366676) sent it to
uf9.cybercity.dk at Thu,  3 Apr 2014 23:27:37 +0200 (CEST)
Which then sent it to smtp1.cybercity.dk at Thu,  3 Apr 2014 23:27:50 +0200 (CEST)
Which then sent it to mtaq2.grp.bf1.yahoo.com at 3 Apr 2014 21:27:50 -0000
Which sent it to a mail server process (qmail 11784) at 3 Apr 2014 21:27:50 -0000
Which sent it to m9.grp.bf1.yahoo.com  at 3 Apr 2014 21:27:50 -0000
Which sent it to a mail server process (qmail 90091) at 3 Apr 2014 21:27:50 -0000

This shows that the mail came from cybercity.dk to yahoo.com

Of note, this email says it was created by a Microsoft Live Mail

X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 16.4.3522.110
X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3522.110

Which is not used by yahoo.com. The problem I see here is that Yahoo.com should have flagged as spam email from someone using a From: address that was *@yahoo.com without that connection first being authenicated as a valid yahoo.com user. Some email providers do this, but others do not (Yahoo appears to be in the second group).


Is Creating a Restricted Database User in Microsoft SQL Server Decent Protocol Forgive me for the heavy metaphor but it's a situation's complexity kind of goes over my head.

Assume I'm Leonard Shelby (My short term memory only lasts 5 minutes).  I'm a freelancer that reads databases for a living.  In my job, I need to access extremely sensitive database but I only need to read relatively nonsensitive data (ie, the database has credit card numbers and passwords but I only need to view user names and favorite colors).  Keeping in mind that this database is MSSQL and remotely accessible from any computer.

Now because I can't remember the logins to these databases, or the combination to my lock box, I need to have them tattooed on my forearm.  I usually remember to where a long sleeve shirt when I go out, but sometimes I end up wearing a t-shirt with all DBA logins in plain sight on my arm.  Anyone could just jot down the information and go home, open up SQL Server Management Studio and drop all of their tables or steal all of their credit card information.

Ideally, no one should ever be able to get their hands on the login information, but the reality is, they might.

Is it acceptable to create a new user for each of my clients
databases and restrict access to only non-sensitive fields and
disallow anything but read access on these accounts?
When somebody inevitably uses this restricted user account to get
into the database, will they be hampered enough to justify the
overhead of creating this user account, or will this just be a minor
(or non-existant) obstacle on their road to stealing all of the data?

This is a very good idea.

This uses the least privilege principle, where we give any user the least amount of access thus mitigating our risks.


Are all SSL domain validation basically the same technically speaking? I've googled this and haven't really been able to find a straight answer and this question which I have read is a bit different and is a bit outdated considering the landscape has changed a lot recently.

What I want to know, is if you aren't planning to get a OV or EV certificate and just need the plain DV type certificate then we have offerings of varying types, such as:

Free Certificates from places such as Let's Encrypt
Many hosts are giving away free certificates now with their hosting (not always by Let's Encrypt)
AutoSSL from cPanel (Free)
$198 Standard SSL certs from DigiCert
$59 Standard Certs from RapidSSL

I could go on, but you get the point. Is there any technical difference between these certificates? From what I have read certificates from LE only last 3 months so you will have to renew them quite often - is that about it?

If there is no real difference then why not go with the free ones provided by cPanel? Why would one spend $198/year when they can get it for free?

The only other non-technical difference I can think of is that if you pay for one then you get the included insurance.

Are browsers more likely to have the ones you pay for in their CA trust store and free ones should be avoided because of this?

So I think I understand the non-technical differences, but am looking for an answer on if paying for one is going to be technically or a more "safer" option?

"If there is no real difference then why not go with the free ones provided by cPanel?"

  Use this interface to install an SSL certificate on a domain, subdomain, or addon domain. Before you can use this feature, you must create or purchase a certificate, and you must possess the certificate's key.

Directly from cPanel's website it looks like you MUST either purchase a cert, or you can use one cPanel provides, but that MAY be a self-signed certificate. Without seeing what is offered by cPanel, I have no way of guaranteeing what cPanel is offering is a CA signed certificate.

If you choose the free certificate from cPanel, it will tell you if it is of the self-signed variety:

  When you install a certificate, this interface indicates whether your certificate is self-signed. Self-signed certificates are easy targets for attackers and generate security warnings in your users’ web browsers. Only install a self-signed certificate temporarily, until you can replace the certificate with a certificate from a valid certificate authority (CA).

You can actually look at the certificate you are provided and determine if it is "technically" the same as another.

If you want to decode a cert on your computer use the following:

openssl x509 -in certificate.crt -text -noout

If you don't mind providing your certificate to a website to be "read" (this is the same thing that happens when the cert is read while in use):

https://www.sslshopper.com/certificate-decoder.html

Usually you select a modulus value (2048 or 4096, anything less is weak), the PKI encryption type (ECC or RSA, either is safe for common use), symmetric encryption type (AES 128 is safe for common use) and any hashes (SHA-256 is common, I prefer SHA-384 because more bits). If you compare two RSA 2048, AES-128, SHA-256 certs they are technically the same regardless of how much they cost.

In March of 2020 most browsers will no longer accept SSL (any version), TLS 1.0, or TLS 1.1. If you have the option, ensure that you are using a TLS 1.2 certificate, at minimum.


How are SCrypt's memory-hard requirements substituted with more CPU? I've implemented scrypt with two separate APIs and in both there existed no settings providing a way to substitute CPU for memory. Both were locked one-to-one with rounds and memory.

However in answers from field experts it seems to be understood that scrypt can substitute CPU for memory.

From openwall:

Can somebody explain what this tradeoff means and how it is achieved?

SCrypt's memory usage comes from its use of a long list of psuedo-random numbers.  Since this list is pseudo-random, there are two ways of dealing with it:

Pre-compute the entire list and store it in memory.  Since each element is expected to be accessed many times, this reduces the CPU cost but increases the memory cost.
Compute each list element on an as-needed basis.  This has many times the CPU cost of pre-computation, but memory use is reduced to only the list element that is actually being used at the current step in the process.

It may be possible to do a hybrid algorithm where part of the list is pre-computed and the rest is computed on an as-needed basis, but most implementations will go for one extreme or the other.

The goal is to limit the ability of GPUs to compute many hashes in parallel.  Since the typical GPU has only a few megabytes of RAM per core, an attacker needs to either use an efficient algorithm on a few cores, or use all the cores but a highly inefficient algorithm.


Clarifications sought about SSL cert signing process Currently I have a cert (signed with SHA1) expiring soon and I have extended its expiry incorporating SHA2 signing algorithm. I have done this by creating another CSR using certutil command with the undocumented -Z SHA256 option. However now, some of my applications encounter problems and I have to revert back to SHA1. Can I know whether i just need to reissue the cert and choose SHA1 as the signing algorithm or do I need to create a whole new cert based on a new CSR with SHA1? thanks

If you are asking can you use the same keypair, yes you can always use the same keypair.  Your first and second certs could have also used the same keypair.

If you mean will the CSR do a reissue instead of requiring you to purchase a new cert?  That isn't a technical question.  They certainly "can" but most will not.  Any change to the cert will require you purchasing a new cert.

You have a bigger problem however.  I don't think any CSR are still issuing certs using SHA-1 anymore.  While it may not matter for your purposes most browsers have deprecated SHA-1 certs so for compatibility reasons they will probably require for it to use SHA-256.


When would a Authenticode signature expire? I'm curious about how Windows check the Authenticode signature.

For example, I would sign test.exe

I know that if test.exe doesn't have a TS (timestamp) signature from a TSA (Timestamp Authority), the signature would expire after the certificate's NotAfter datetime.

I used to believe that if test.exe have a Authenticode signature with a valid TS signature, this signature would expire after the TS certificate expire.

However, it seems I'm wrong... When I was cleaning my old computer, I found the PlantsVsZombie!（⊙o⊙） You can download the main file from here ( I'm not sure how long can I keep this link available... )

Its signing certificate expired at 2012/9/21 and its timestamp certificate expired at 2012/6/15. Both of these two certificates expired now. But surprisingly, its signature is still valid (Checked using Powershell command Get-AuthenticodeSignature and viewed from the attributes-Signature tab)

Then I wonder will a signature with timestamp expire? If it would, at which time?

I'm curious about how Windows check the Authenticode signature

Microsoft's Authenticode is a mechanism that is based on PKI as any other digital certificate verification process:

Public key verification
Certificate lifespan
Certificate status (revoked?)
Trust chain
Timestamp (if used)

In case of timestamp, the signature will be valid as long as the certificate is valid.
Otherwise, it will expire when the certificate does.

From DigiCert:

  Timestamping ensures that code will not expire when the certificate expires because the system validates the timestamp. If you use the timestamping service when signing code, a hash of your code is sent to the timestamp server to record a timestamp for your code. A user’s software can distinguish between code signed with an expired certificate that should not be trusted and code that was signed with a Certificate that was valid at the time the code was signed but which has subsequently expired.


I've shared my WiFi with my neighbour. How can I ensure they're not downloading illegal content? I want to ensure they're not downloading any illegal content (torrent websites in particular). If they're using a VPN or Tor, then I guess there's not much I can do, but if they're just connecting directly to, say, pirate bay, without masking their traffic and downloading content through them, is there a way for me to spot that and tell them off?

I'm not interested in throttling their traffic or monitoring what websites they otherwise visit. I'm only interested in detecting if they access the popular torrent websites (pirate bay, kickass, demonoid etc.) and download stuff through them.

My WiFi router is Technicolor 582n.

I guess that most corporate people setting up Internet access for the employees may have the same need: how to ensure that employee does not waste enterprise's bandwith to download torrents?

Usually, the main answer lies in two things:

Restrict the destination port numbers to the really needed ones,
Setup a DNS cache server, which can provide an easy way to blacklist certain domain names (this implies that rules above do not allow port 53 as destination port),
Make the HTTP flow go through a proxy,in the current case a non caching proxy like privoxy may be usefull.

For HTTPS content, you will not be able to check the actual page or data content however you will be able to know the domain name of the website currently visited (both thanks to DNS requests and SNI) and compare it to a blacklist, which seems sufficient for your needs.

edit: Just a thought, in case of a one time check to answer questions like "Internet is going damn slowly, I hope my neighbor is not using all the bandwidth with torrents", you have the possibility to use a network sniffing software (like wireshark) on your wifi network to check what is going on currently.