2FA: Why not use dictionary phrases instead of numbers? This question is inspired by this one:
How long should 2 factor authentication codes be?

Basically, there is a practical lower and upper bound of 2FA code length. It can't be too short such that an attacker with all passwords could bruteforce a significant percent of accounts. But it also can't be too long such that it's difficult to commit to short-term memory.

So then why not use a dictionary/diceware phrase? Something like puppy banana galapagos moose is just as easy to remember as 327229, but offers much more entropy.

The only disadvantage might be that it is more time-consuming to type, but with mobile keyboards with autocomplete, it would only take an extra second or two while drastically decreasing the percent of accounts that could be bruteforced.

Yes you are increasing entropy but you are decreasing usability.

Firstly you need to get a good dictionary. Things you need to think about are accessibility (how readable is it? Are there b,d or q,p or cl,d or I,l confusions? You can't have click and dick in the dictionary)  Are the words easy to spell from memory? I can't spell 2/4 of the words you used and I have a BSc. You can't have any that are too technical or culturally insensitive (e.g.  Taiwan )

Secondly you say about mobile keyboard with autocorrect. Autocorrect goes wrong, you need to check every word in your dictionary will be in them for a long time (if bananas go extinct tomorrow will the word still be in an autocorrect in 30 years?)  and you are making it harder for those with full size hard keyboards

Thirdly you are cutting out everyone who doesn't speak the language, numbers work across all languages. There are very few other number systems used outside the 123 numbers.

Fourth how are you going to display them? A 6 digit number can be on a 6 digit 7 segment display, 4 words need at lest a 20 digit complex display or better. "But they can be on a phone" I hear you say, but there are places you can't have a phone because there are no wireless devices allowed (its hell on earth, never work in a place like this) and that would fragment the market to those with mobile devices and those without which leads into

Lastly it would fragment the market. For tech like this fragmentation is bad, we trust it because it has been tested lots and lots. Unless the old thing is broken or the new thing is 1,000,000% better than the original it will never take route. As it is we still have broken encryption methods now because they might brake something worse if removed and banks that still use something you know and something you know (2 passwords)

The improvement they could make to 2fa devices  is to be able to set how long the code is on the screen upto 60 seconds max (10 seconds per number for accessibility reasons) and have the box you type it into tagged as a number box so that soft keyboards show either the number row or better a number pad.


Adding self signed certificate to trusted store I have been reading about certificates and often is said that self signed certificate should not be added to the trusted authority store and even if you did, remove it after usage immediately.

MSDN How to: Create Temporary Certificates for Use During Development

  Be sure to delete any temporary root authority certificates from the
  Trusted Root Certification Authorities and Personal folders by
  right-clicking the certificate, then clicking Delete.

Why is adding a self signed certificate to the trusted store considered a security risk? How can this be exploited by a hacker ?

Can someone please explain me with example ?

Self-signed certificates

If you have a CA (private) key, which is the same as the one for the CSR you sign, then you create a self-signed certificate. If instead you create separate keys for the entity whose identity you wish to confirm and the CA used to confirm the identity, it's formally not a self-signed certificate anymore.

Self-signed certificates are mostly used for testing purposes and thus temporary. This can be enforced by limiting their validity period, but often isn't done in favor of convenience.

How the real-world CAs do it

The CAs will have a hierarchy of keys/certs (comprising the certificate chain you probably have heard of). If you - or your OS vendor - choose to trust a root CA cert it implies trust to Sub-CAs whose certs were signed with the root CA key.

What this means is that the root CA key requires the highest security, because it can be used to create any number of Sub-CAs which will be ultimately trusted if someone chose to trust the root CA cert.

  Be sure to delete any temporary root authority certificates from the
  Trusted Root Certification Authorities and Personal folders by
  right-clicking the certificate, then clicking Delete.

Makes perfect sense now, if you consider that a root CA cert (with key) proper will have the biggest potential of being abused and create the biggest bang for the buck for an attacker. if compromised. You'll want to keep those stashed away securely unless you are using them right now to sign a Sub-CA CSR. Hence, remove them and keep a copy for later CSR signing purposes (if you need).

However, since the quote is clearly about "temporary root authority certificates", I think the clue is hidden in temporary and that's something you as the system administrator define for your own CAs and Sub-CAs (i.e. whether you intend to use them in the future or not).

Basically you can consider deleting a temporary CA cert/key as making it unavailable to an attacker, similar to the security measures of actual root CA keys. It assumes that this temporary CA won't be used to sign any more (development-use) certificates.

So that little word temporary implies a little more in the quote than it seems at first glance.

How this looks in practice

Let's say you have a root CA key that never expires (although in most cases it will simply be a relatively long period, like 20 years) and a corresponding root CA cert. You'll want to keep the key secure from any compromise, especially if the certificate is trusted by many many people. That is the case with the root CA certs of, say, Verisign or Comodo.

That root CA key will then be used solely to sign the cert of a Sub-CA (which has its own distinct key), thereby creating the first two links in a certificate chain which your browser or Microsoft's signtool as well as many other utilities let you inspect. The root CA key would never be used directly to process your CSR and thus confirm your identity as an end-user/website/company.

Every respective Sub-CA will usually only be used for a particular purpose (there are extra fields for certain purposes, such as code-signing) and its validity period will be a subset of the root CA cert's.

But, and that's one difference between the root CA's key and the Sub-CA's key: the root CAs key can be stashed away securely (talking physical security here) most of the time, unless absolutely needed to sign the CSR for a new Sub-CA, while the Sub-CA key will likely be used on some kind of highly secured server to sign customer CSRs (when considering a real-life certification authority like Verisign). This means that the Sub-CA is more at risk than the root CA and why you want to apply different levels of security in the first place.

The advantage being that, should the Sub-CA ever get compromised, its certificate can be put onto a ARL/CRL (authority/certificate revocation list), whereas putting the root CA certificate on a ARL/CRL is only really warranted for technical reasons (e.g. using the now compromised MD5 hash, a key length not deemed secure anymore ...). The costs attached to either of these are the defining factor at several levels:

costs for storing the keys securely, in particular the root CA key has to be secured the most
costs when changing root CA certs versus changing Sub-CA certs
costs when revoking (Sub-)CA certs


keeping user names as login info is vulnerablilty in a website Many advice not to post email addresses on the public forum since some may try for several login attempts using some brute force attacks etc.,  but I notice in several websites(even in sensitive websites which deal with money) I can find that it uses email-id/username for login mechanisms and they actually display user names publicly, example website GitHub (https://github.com/login?return_to=%2Fpersonal).

My question are these websites vulnerable to a wide range of bruteforce attacks? Like using web crawlers to gather large number of usernames and brute forcing against with a single popular password.

For example "nopassword" is one of the commonly used password by many people
 Instead of using passwords as wordlists (common method) the attacker could use usernames which are obtained from the bots as wordlists with one single password like "nopassword"

It is narrow spectrum attack but the attacker could gain access to huge number of accounts that use popular passwords by this method. So is this a vulnerability of the websites?

There is a difference between a 'weakness' and a vulnerability. Usernames are not intended to be secret, so once a username is known, then it is subject to bruteforcing. This is a weakness with the entire username/password model and every website that uses it adopts this weakness.

There are ways to mitigate this weakness, like Two-Factor Authentication (2FA), but the weakness of the model is still inherent.

The problem is that there is no viable alternative that will work for the entire world. Sure, you could issue client certificates, but that is not easy to administer.


Hashing Algorithms on GPU, 32 bit vs 64 bit I read here in What algorithms are best be cracked by GPU? that, hashing algorithms such as SHA1, SHA224, SHA256 which do 32 bit integer arithmetic and logical operations are better implemented on GPU as opposed to SHA512 hashing algorithm which work on 64 bit integers.

What is the reason behind this? GPUs do not provide a good support for development using 64 bit integers?

I read on the Nvidia CUDA Developer's FAQ the question: Does CUDA support long integers?

And the answer is Yes, however it says that operations on 64 bit long integers compile to multiple instruction sequences. Is that the reason why GPUs can handle 32 bit integers much better than 64 bit integers?

More information around this would be helpful. Also if there are any references which discuss this more in depth, I would like to know.

To me, your question boils down to, "Why are GPUs 32 bits systems?"

The answer to the multiple instructions for a 64 bit number is the same as a regular CPU. If the architecture is 64 bits, then everything fits into the registers. If the architecture is 32 bits, not everything fits and multiple passes must be made to load and process everything.

What's the reasoning? As with the progression of all processors, GPU architecture has grown to the size it needs to be. Presently, 32 bit GPUs do a fantastic job of processing graphics and nobody's really clamoring for a 64 bit video card.

Consider looking at your question another way: why aren't modern CPUs 128 bit systems? I'm certain there are people out there who would like to run 128 bit operations, but it just doesn't make sense for the bounds of technology as it stands right now.


How can an attacker access a system with a private IP address? I am confused about this concept if a public IP is assigned to my router and my system has private IP address, how an attacker can access my system or can use my system as a BOT.
Its a common scenario when we click or download some malicious file than an attacker got controlled. Is there any other way to open the door(Router) with some thing like duplicate key ?

The router is like a automated door that would:

Let anyone open it from the inside
Require a passcode to open from the outside

There are multiple ways to bypass the normal behaviour, some are exploiting flaw in the implementation of the router, other flaw in the protocols and some in design.

Let's say you invited a friend to stay at your home, then you go to work. If he is a bad friend, calls thieves and open the door from the inside for them, thieves can come in and rob you.

Well, now you decided not to entrust anyone. A thieves can come to your door, confuse the automate to let him think he is inside so that the door opens (e.g. TCP flag manipulation).

The thieves can also go to a bar you're usually in, pay you a couple of beers and get the passcode to enter from yourself.

The thief can also go to the door with a list of passcodes and try them one by one until the door opens.

If you open a port for a service, let's say you are a medical doctor with a secretary. People may come in and go to the secretary, but not come in and go to your house. A thieve can come in, disrupt/dupe the secretary and go in your house while she's not looking.

Back on more computer thematic. Once inside, an attacker can exploit a vulnerability of your computer to install a bot on your machine. Then your machine will try to access the internet, which it is allowed to do anyway.

Per se, NAT masquerading is not a security measure, because it has initially been design to allow multiple computers to access the internet using a single public IP address. The more we progress, the better the router are able to block malicious request coming from the outside. But they are always cases where it's not easy to distinguish legal traffic from forged one.


Authenticating a Proxy server over HTTPS When browsing to a website over HTTPS, the web browser typically does a lot of work in the background - negotiating a secure channel, validating the site's certificate, verifying the trust chain, etc.

If your browser is configured to use a web proxy, the current HTTP protocol supports a CONNECT method - this enables your browser to setup the TLS tunnel to the website, without revealing any of the request contents to the proxy (other than the name of the site, of course).

What does the browser do regarding the identity of the proxy server?
If the proxy does not have a certificate, then potentially it could be impersonated by a MitM.
Even if the proxy does have a certificate, if it's not checked, it might still be possible to impersonate it.

Does the protocol (or any companion RFC) define how this should be handled? How do common web browsers typically handle this?
If the proxy does not have a certificate, is there any feedback to the user? If the proxy does have a certificate, but it is invalid, is there feedback then?

Additionally, is there a provision for securely authenticating the web proxy, even when the request is plain HTTP?
For example, connecting to the proxy over HTTPS even though the request to the website is over HTTP...

NOTE that I am not asking how to identify the website, whether tunnelled through the proxy or having it intercept the SSL chain.
Rather, I want to verify the identity of the proxy itself, to make sure no unauthorized server is MitMing me...

As is customary, let's first answer the exact question which was asked.

Right now, using HTTPS to connect to the proxy is not widely supported. The squid documentation has some information on the subject; to sum things up:

Chrome supports it, but it must be configured through a proxy auto-configuration script because there is no GUI support. This also means not using the "system-wide proxy configuration".
Firefox does not support it, although the feature has been marked as requested since 2007. (UPDATE: Supported in FF 33+)
No indication on other browsers, which can be surmised to mean "no support whatsoever".

What Chrome does when encountering a "somewhat invalid" certificate for the proxy should be tested, but it is likely to depend on the exact browser version (which changes all the time, often transparently), the operating system (since certificate handling tends to be delegated to the OS), and in what ways the certificate is not valid (expired, bad server name, unknown trust anchor,...). Also, there is an inherent chicken-and-egg issue here: full certificate validation, as is mandated by X.509, includes checking revocation, i.e. download of CRL for all certificates in the path. URL for CRL download are usually located in the certificates themselves. But if you are using a proxy for your HTTP traffic, then the CRL download will need to go through that proxy... and you have not yet validated the proxy certificate. No chicken, no egg.

We may also note that the proxy auto-configuration file format does not really support HTTPS proxying. There is no formal standard for this file, but custom is to follow an old Netscape draft which says that a PAC file defines a Javascript function which can return proxy hostnames and ports, but not protocol. So, no HTTPS. For its HTTPS-proxy support, Chrome implicitly uses an extension to this de facto convention by stuffing an HTTPS URL where it has no right to be, and hoping for the browser to make some sense out of it.

As is customary, let's see what alternate proposals can be made.

To ensure protected communication between the client and the proxy, the two following solutions may be applicable:

Use a VPN. This is highly generic, and since it operates at OS level, it will apply to all browsers. Of course, it requires that whoever installs the thing on the client machine has administrative rights on that machine (you cannot do this as a simple unprivileged user).
Use a SSH-based SOCKS proxy. On your client system, run: ssh -N -D 5000 theproxy ; then set your browser to use localhost:5000 as SOCKS proxy. This solution requires that you have the proxy server (theproxy) is also a SSH server, and that you have an account on it, and that the SSH port is not blocked by some ill-tempered firewall.

The SOCKS proxy solution will ensure that the traffic goes through the proxy machine, but does not include caching, which is one of the reasons we usually want to use a proxy in the first place. It can be altered by using some additional tools, though. SOCKS proxying is about redirecting all TCP/IP traffic (generically) through a custom tunnel. Generic support for applications is possible, by "replacing" the normal OS-level network calls with versions which use SOCKS. In practice, this uses a specific DLL which is pushed over the standard OS libraries; this is supported in Unix-based systems with LD_PRELOAD, and I suppose this can be done with Windows too. So the complete solution would be:

You use a SSH-based SOCKS tunnel from your client to the proxy machine.
The SOCKS client DLL is applied on the browser, and configured to use localhost:5000 as SOCKS proxy.
The browser just wants to use theproxy:3128 as plain HTTP proxy.

Then, when the browser wants to browse, it opens a connection to theproxy:3128, which the DLL intercepts and redirects to a SOCKS tunnel that it opens to localhost:5000. At that point, SSH grabs the data and sends it to theproxy under the protection of the SSH tunnel. The data exits on theproxy, at which point the connection to port 3128 is purely local (thus immune from network-based attackers).

Another way to add caching on the SSH-SOCKS setup is to apply a transparent proxy. Squid can do that (under the name "interception caching").

Yet another way to do caching with SSH protection is to use SSH to build a generic tunnel from your machine to the proxy. Run this:

ssh -N -L 5000:localhost:3128 theproxy

and then set your browser to use localhost:5000 as an HTTP proxy (not SOCKS). This will not apply proxying on alternate protocols such as FTP or Gopher, but who uses them anyway ?

As is customary, let's now question the question.

You say that you want to protect against a man-in-the-middle attack. But, really, the proxy is a MitM. What you really want is that the proxy is the only entity doing a MitM. HTTPS between the browser and the proxy (or SSH-SOCKS or a VPN) can protect only the link between the client and the proxy, and not at all between the proxy and the target Web server. It would be presumptuous to claim that MitM attacks are reliably thwarted without taking into account what happens on the Wide Internet, which is known to be a harsh place.

For end-to-end protection against MitM, use SSL, i.e. browse HTTPS Web servers. But if you do that, then extra protection for the browser-to-proxy link is superfluous.

Protecting traffic between browser and proxy makes sense if you consider proxy authentication. Some proxies require explicit authentication before granting access to their services; this is (was ?) common in big organizations, which wanted to reserve "unlimited Internet access" to some happy few (usually, the Boss and his favourite underlings). If you send a password to the proxy, then you do not want the password to be spied upon, hence SSL. However, an attacker who can eavesdrop on the local network necessarily controls one local machine with administrator privileges (possibly, a laptop he brought himself). His nuisance powers are already quite beyond simple leeching on the Internet bandwidth. Also, limiting Internet access on a per user basis maps rather poorly to modern operating systems, which tend to rely on Internet access for many tasks, including software updates. Internet access is more efficiently controlled on a per usage basis.

Therefore, I think that protecting access to a HTTP proxy has some merits, but only in rather uncommon scenarios. In particular, it has very little to do with defeating most MitM attacks.


How dangerous are outdated PHP versions for my clients? In the company where I work (webhosting) our custoumers can choose the PHP version they want to use for their website.

However, I have just realized that all of the offered PHP versions are outdated (ie. PHP 5.4.38, 5.5.22 and 5.6.6  being offered to our clients - current versions are 5.4.43, 5.5.27 and 5.6.11). How dangerous is that to our customers? Is running those old versions pure madness or is it just a minor risk for our customers?

edit: There are no security updates applied, it is just PHP 5.4.38 from a few months ago.

Most new versions come with security improvements, so the older a version is the more time an attacker has to take advantage of it.

You can browse through a vulnerabilities library, for example here is one for php 5.4.
You can check yourself how many vulnerabilities have been disclosed and how severe they are. For the most part I think its a matter of which extensions are enabled and the specific code, I dont remember the CVE identifier but I remember a multibyte function in php (a long time ago) that would cause a buffer overflow if given a specific string.

In my opinion, the versions you currently have are not terribly old, but they do pose some security concerns, here's one example of a DoS vulnerability.

Look at it from another angle, new php versions also come with changes in functions and updating to a newer version may not always be transparent to the application, things may break. So a hosting company should also not automatically update the PHP version without consent from the client.


Why is the code CVE-2010-5298 used for a vulnerability discovered in 2014? I was looking through the OpenSSL vulnerabilities list and came across CVE-2010-5298 as a 2014 vulnerability.

At http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-5298, under Date Entry Created, it says 20140414.

However, under http://cve.mitre.org/cve/identifiers/syntaxchange.html, it clearly shows that format as CVE-YYYY-NNNN:

  The CVE-ID Syntax Change took effect on January 1, 2014.

  New CVE-ID Syntax

  The new CVE-ID syntax is variable length and includes:

  CVE prefix + Year + Arbitrary Digits

  IMPORTANT: The variable length arbitrary digits will begin at four (4)
  fixed digits and expand with arbitrary digits only when needed in a
  calendar year, for example, CVE-YYYY-NNNN and if needed
  CVE-YYYY-NNNNN, CVE-YYYY-NNNNNNN, and so on. This also means there
  will be no changes needed to previously assigned CVE-IDs, which all include 4 digits.

I thought the year is always reflected in the CVE code. What happened in this case? Is this a common occurance?

It's because the vulnerability was actually first discovered in 2010 (even if it wasn't reported as a security issue back then, just as a bug), and rediscovered again in 2014 by Ted Unangst after heartbleed became the straw that broke the camel back, and this time correctly identified as an issue with security implications.

Original bug report : https://rt.openssl.org/Ticket/Display.html?id=2167&user=guest&pass=guest


Is HMAC required when using TLS communication? We have SSL  communication between our mobile app and our servers.

The request from mobile is creating a hash on all the request fields  - based on a secret key which is "stored" on the app.

So it sends json with all the fields data, plus a signature value which is :

hash = hashBasedOnKey ( all request data fields)

Later, the server does the same thing. It reads the fields and run hash on those fields ( server also has the secret key) and if the hash are the same  , then it means that the data was not altered.

But

Is it really needed when using SSL communication ?

A MITM can't alter the data , except for SSL stripping.
But again, the mobile app uses SSL communication.
IMHO - ssl stripping is when non ssl "thinks" it connects to ssl  , without noticing, where the MITM does the SSL by itself to the destination, and strip the https data , and return the http data.

Question:

Is hashing the data in the client, crucial? or is it useless?

TLS protects the communication between client and server.
It is unclear, what specific attack vector this hash is trying to mitigate since not much is known about the application. But if it tries to only mitigate tampering between data between client and server by some malicious attacker then it is not needed with TLS.

It might though that the hash is trying to mitigate manipulation  by a "friendly" man in the middle, i.e. one which is explicitly trusted to intercept and manipulate the TLS connection by having its CA imported as trusted in the device. In this case it might make sense to make it more complicate to successfully tamper with the traffic by having some application specific secret to protect the data in addition to TLS.


Bypass file_exists[rfi,lfi] in my code, is it possible? I've got the following piece of code in my web application:

$data = "dir/files/".$_GET['f'].".pdf";

Couple of lines down I got:

if(file_exists($data)){
include($data);

Could an attacker bypass that to exploit an RFI on my system? Or is it LFI only?

Best to whitelist (not blacklist) characters allowed in $_GET['f'].

if (preg_match("[^A-Za-z0-9_-]", $_GET['f'])) {
  fail();
} else {
  // your logic here
}

Notice that I didn't put "." or "/" in the whitelist. That was intentional.


Phone Privacy for Small Business I'm a small business operator and I'm looking for ways to provide security and reasonable privacy for my own business communications and communications of customers.  All these businesses operate outside the U.S. and have no need to export their data to U.S. servers.

All the smartphones I've seen seem awful.  Before somebody says "let me google that for you", remember, we're talking a business with a size of 1-25.  "Enterprise" servers with dedicated admins, thousands of dollars in licensing are not reasonable just to be able to keep your own data private on your own phone.

Here are some criteria I put together, maybe there's something I'm missing.  The features below can be provided natively (ideally) or through reasonably priced, well supported and fully functional 3rd party software.

Confidentiality

Absolutely must not sync contacts with remote non-company owned servers or otherwise flagrantly violate privacy.
Must support escrow-free device encryption, if there's escrow, it must be for the business owner to control, not the provider
Must allow for also encrypting SD cards
Must support wipe on too many failed access attempts
Bonus: Mobile Device Management software without setting up new servers or requiring a specialized administrator.

Availability

Must allow for offline access to email, calendaring and contacts.
Must support ActiveSync for at least one Exchange system, including calendaring and contacts.
Must support open standards for calendaring, scheduling and contacts.  E.g., caldav, carddav.
Must support multiple IMAP and POP3 accounts.

Integrity

Must not alter contacts or calendar (merging, editing, "fixing" etc) unless explicitly told to do so
Must allow for multiple calendars to be "layered" without importing or syncing.

Results of my own research

Android 2.x: No device encryption short of directory-based LUKS
Android 4: cannot use without Google account.  Very difficult, or impossible(?) to use without sending your contact info to Google.
Android 4 (customized): May work... not a packaged or supported solution.
iPhone:  seems to want an Apple ID, but not entirely sure what it's used for.
Windows Phone 8: can't encrypt without Exchange ActiveSync profile, requires "enterprise" CAL, etc.
Blackberry(BES5): requires special data plan to sync, ships data overseas.  Requires special server software, etc.
Blackberry(BES10): ... maybe?  costs extra to sync to Exchange.

Are there other criteria I should consider?

Sounds like you want dynamic security policies. A custom OS build may be the only way to  achieve this. Since Android is open source, it's been researched/hacked pretty extensively with this in mind. iOS has one or two projects going, too. Never seen any for Windows/Blackberry.

FlaskDroid, for example, is a child of Security Enhance Linux (SELinux). A good research paper written on it is here, but to surmise they implement a user-space security server which all API requests for sensitive data (SMS, Contacts, GPS, etc..) run through. (Alternatives are MockDroid, AppFence, and Taming Information Stealing Smartphone Applications (TISSA).. all very similar but I think FlaskDroid is the best).

This security server implements policies chosen by the user. As a bonus, they also protect against root level MAC queries, so if your device becomes infected by malware running as root, it cannot get to your data without an appropriate policy.

Obviously, this has a couple of drawbacks:

Kernel was hacked, so it must be installed on your device ad-hoc as rooting is required.
Trusting SELinux

Alternatively, the applications themselves can be hacked for increased security. Because it's Java, and in turn just a series of bytecodes, apps can be modified with instrumentation. Research has been done on this with Redexer, but that's written in OCaml, and nobody wants to do that.

One of my current projects is to implement instrumentation using Java, so that we can tie down any application with dynamic permissions. All the developer has to do is write what Java code they want to execute when contacts are accessed, for example, and my tool will go in and instrument the application to behave in that way. So, in this way, I've implemented dynamic permission policies... users can grant or revoke any permission to any application after installation. They can also be activated/deactivated depending on geophysical location, so at work the camera is shut off from all applications. Paper is pending review. No rooting of the phone is required.

In this way, you could block network access to all but a few "allowed" domains, such as your company's calendar syncing servers, disallow access to calendar unless the user clicks on a pop-up.. etc. As for encrypting the SD card, Android natively supports that now.

iOS project for dynamic security policies: Protect My Privacy. (Paper). Requires jailbreaking.

EDIT: To clarify, SELinux prevents any actors from performing actions they have not specifically been granted. It boils down to Mandatory Access Control (MAC) vs. Discretionary Access Control (DAC). DAC doesn't protect against rouge users/processes running as root. MAC does protect against malware running as root, assuming the malware wasn't specifically given full access privileges (which should never happen; the idea is that nothing is ever given more permission than is absolutely necessary).


Bypass frontend ampersand encoding and perform XSS I just started learning something about web app pentesting and I was trying my hand on a website (which I'm allowed to test on). I found this potential stored XSS:

hello

Here, the div content (which is retrieved from a back end request) is copy-pasted to the title attribute of the div itself. When I try to change the div content via back end request to something like

">

it won't pop the XSS. Upon further investigation, I found that when I copied the HTML from the developer console (on Chrome, don't know if it matters) I'll then paste something like this:

">"&gt;&lt;img src=x onerror='alert(1)'&gt;

Now, since the content comes from a backend response exactly as I wrote it (image below), the escaping must come from the frontend then.

Is there any way to bypass this kind of encoding?

The frontend should be implemented using Preact. Is it automatically escaping strings?
Please let me know if I should provide more details

EDIT: clarifications

tl/dr: Most likely there is no exploit here.  The behavior of the backend (passing down unescaped data) is perfectly normal and
  acceptable, as escaping has to happen on the frontend.  Moreover,
  escaping on the frontend most likely is happening, but the behavior
  of the Inspect Element tool in Chrome can confuse that issue.

Overview of examples

Both these issues can be quite complicated so I'm going to show a number of examples to demonstrate what is happening.  To have some useful examples you need both a backend and frontend.  However, I'm not actually going to have a backend so that you can easily reproduce it yourself.  Instead I'm just going to have some static files that act like a backend, and I'm going to use some simple JavaScript to both demonstrate proper frontend security and how Chrome can confuse the issue if you aren't familiar with some key details.  The following examples make actual HTTP requests so you'll have to have these files hosted by an webserver - if you try doing this with local files (aka File -> Open) Chrome will complain about CORS issues that you can't fix.

Safely setting HTML attributes

Anyway we're going to start with an example that is not vulnerable to XSS.  Here's an HTML file with some javascript:

index.html:

Test: Secure

response.json is just a plain text file in the same folder as the above HTML file and contains:

{"name": "\">"}

Therefore when the page loads it makes an HTTP request for some JSON (which includes your payload), parses it, and then sets its contents as the title of our span.  Despite a valid XSS payload no alert will fire.  If you hover over the span you'll see your payload, and if you inspect element you'll see this:

">Secure

Which looks like it should have worked, but it clearly didn't.  That's just because of the way Chrome shows such content though.  If you right click the span in the "Inspect Element" window and click "Edit as HTML" it will change to:

">Secure

Which you can see is perfectly secure.  There was no vulnerability.  Chrome confused the issue because in the "Inspect Element" window it showed the &quot as an actual ".  The reason it is secure is because, in essence, there are many "safe" methods available in JavaScript that leave no room for XSS.  For these methods Chrome itself automatically applies the proper "escaping".  Using these safe methods is the equivalent of using prepared queries with SQL, and as long as this is what the frontend is doing, you have no hopes of an XSS vulnerability (or at least if you did find an XSS vulnerability for one of these safe methods you would have a high-value browser 0-day and could get tens of thousands of dollars from Google for it).

When you don't understand what Chrome is doing though it can be very confusing, because in the inspect element tool it looks like your exploit worked.  It didn't of course, the inspect element tool just shows the escaped characters as their replacements because... well... that's just how it is made.

A note about React, Angular, et al....

Further, note that modern frontend frameworks like React and Angular know which methods are safe and which methods aren't and use the safe methods exclusively.  As a result the risk of XSS vulnerabilities are effectively zero when using modern frontend frameworks "properly".

A note about escaping on the backend

Note that this is also why it's important not to escape on the backend.  Imagine there is no payload, a user used an actual quote in the data, and we escaped it when we sent it down.  As a result we'll change our response to:

{"name": "&quot;Awesome!&quot;"}

When we hover we'll see a title of &quot;Awesome!&quot; and if we inspect element and then Edit as HTML to see what the browser is actually doing we'll see:

Secure

AKA the browser escaped our already escaped data, leading to double escaping and a really weird result for users.  This is not what we want, and would be the equivalent of adding slashes to user input before using prepared queries - it creates more of a mess and is unnecessary.

This is why it's not a problem that the response with your payload looks unescaped - it should be.  Otherwise the application would end up with double escaped data and that would confuse people.

Safely setting tag content

So what would vulnerable code look like?  Let's change our code to show another safe method, except instead of changing the title let's change the actual tag contents, so we'll change our index.html to:

Test: Secure

And our response.json to:

{"name": ""}

When the page loads you'll see:

Test:

With no alert.

Insecurely changing tag contents

Now let's live dangerously.  Change just one line of javascript:

test_element.innerHTML = response.name;

Then reload the page and you will see your alert.  XSS Success!

The difference is that the innerHTML method isn't safe.  It takes the content and renders it as actual HTML, which means that any HTML in the content will actually render/execute as HTML.  In this case you would want to escape your data on the backend before sending it down if it isn't supposed to be HTML.  Of course that would be a dangerous proposition because if your backend forgot to escape the data then you would end up with an XSS vulnerability.  It's much safer to use safe methods exclusively.

Summary

I realize that this is quite a long answer :)  My goal here is to give some understanding about what is happening "under the hood" so you can both understand why Chrome is giving confusing results, and also understand when an application may or may not be vulnerable.  That's quite simple: as long as the application is using "safe" methods to update the DOM then you won't manage an XSS attack anymore than you could execute an SQL payload on a site using prepared queries.  Of course the hard part is determining how the application is handling input and therefore whether or not there is a vulnerability.  Theoretically the JavaScript is available to you so you could always read it and find out, although in practice that is rarely easy...


Session ID in the very First Client Hello Is it normal to have Session ID in the first Client Hello, and then the server picks it up and accepts the same Session ID and uses it in all further TLS traffic. That is the "Client or Browser" tells what Session ID to use and "Server" accepts it.
This is a behavior with my websites.

Why does it do so?

Is it normal?

Does it have any security risks?

Session ID in the first Client Hello, .... That is the "Client or Browser" tells what Session ID to use and "Server" accepts it.

It is not that the client just comes up with a new session id and the server accepts it. The TLS session id and also the TLS session ticket which serves a similar purpose are first send by the server to the client.

If later the client sends the previously received session id or session ticket within a new TLS handshake and the server still has or can derive the information for this existing session, then the session can be resumed and only an abbreviated handshake will be done.

If instead the clients sends a session id or session ticket which the server cannot handle (i.e. invalid, expired...) then it will be ignored by the server and a full TLS handshake will be done.


Are there types of malware that are so time-intensive to detect that AV vendors simply choose to not detect them? I've been reading a lot about how AVs use different heuristic methods to detect obfuscated malware and it seems like some of these methods are very time/processor intensive. For example, to detect encrypted malware AVs will sometimes emulate their execution and examine its memory after it has fully decrypted itself. I imagine it would be untenable to do this on every executable in a system and a malware with an especially long decryption process might be troublesome.

My question is, are AV companies equipped to defend against more-or-less any type of known malware out there or are there types of known malware that AV vendors simply choose for their products to not even try to detect because there is no efficient method to do so?

...that they simply choose to not even try to detect because there is no efficient method to do so?

AV does not specifically choose to not analyze some malware since it is too hard. If it would know up-front that this is malware but too hard to analyze than it could simply block it based on this knowledge.

AV simply has limited capabilities and therefore cannot find every malware. These capabilities are limited because the signatures and heuristics are based on knowledge of existing malware. They are limited because the user expects a quick response so that amount of time an AV can spend for analysis is short. They are limited because malware might show its malicious behavior only in specific environments and AV cannot simulate every possible environment. They are limited because it is not always clear if a specific behavior is just unusual or actually malicious - and the user does not like it if the AV blocks innocent software.

But AV or the programs calling AV (like inside a firewall) do usually choose to not analyze files which are unlikely to contain malware in the first place. These might be files of specific types, i.e. something which looks like an image although an attacker might fool the analysis system using polyglots. Or it might be files which are too large, although attackers can exploit this limitation by specifically hiding their malware in large files.


How do I get the thumbprint of an SSH2 public key on windows? I have a SSH2 public key with a .PUB extension and when viewed in notepad it has this header:

 ---- BEGIN SSH2 PUBLIC KEY ----

How do I view the thumbprint of this key?

I've attempted ssh-keygen -lf key.pub but that returns: "Is not a valid key file".  (I got the binaries for ssh-keygen from github's standard shell.

I'm a bit new to SSH/SSH2 and not sure what the difference is, or if I'm using the wrong version of a tool for the wrong version of a public key.

It looks like you made your key with the PuTTY Key Generator (PuTTYgen).  To get the OpenSSH pubkey format, edit it with PuTTYgen (right click on the .ppk file and click on "edit").

At the top of the window, you'll see the "Public key for pasting into OpenSSH authorized_keys file" text box.  The text should start with ssh-rsa AAA (assuming an RSA key).  Copy that text and save it as your public key.  This is what you need.  You'll also find your key fingerprint in here.

Here's a screen shot of what I'm describing:


Link(s) between subnet mask, IP address and subnet ID I am studying CompTIA Security+ material and am struggling to understand the link(s) between a subnet mask, an IPv4 address and a subnet ID.

The question that I'm working on is as follows:

  Your network uses the subnet mask 255.255.255.224.  Which of the following IPv4 addresses are able to communicate with each other?

  10.36.36.158
  10.36.36.166 and 10.36.36.184
  10.36.36.224
  10.36.36.126

The correct answer is 10.36.36.166 and 10.36.36.184, the second option.

An explanation is given below the answer.  It reads:

  The hosts using the IP addresses 10.36.36.166 and 10.36.36.184 would be able to communicate with each other because they are on the same subnet (known as subnet ID 5).

  All of the other answer choices’ IP addresses are on different subnets, so they would not be able to communicate with each other (or with the IP addresses of the correct answers), by default.

Following this is a table (I have not included it because I am not sure how to format it properly) which provides the complete list of subnets and their ranges for this particular subnetted network.

The explanation also includes the following statement:

  It is noteworthy that the answer 10.36.36.224 is not even usable because it is the first IP of one of the subnets.

My struggles/questions

How could I have known that the IP addresses 10.36.36.166 and 10.36.36.184 are on the same subnet (known as subnet ID 5)?
How could I have known that the other answer choices' IP addresses are on different subnets?
How could I have known that 10.36.36.224 is the first IP address of one of the subnets?
I think this question summarises the three above.  How can I determine the various subnet IDs and their corresponding IP ranges, given the subnet mask?

NB: I have done some research, to try and help answer my questions.  In particular, I came across this; however, I didn't see how (if at all) it could help to answer my questions.

I would greatly appreciate help with this.

You have take each address, and calculate it's subnet ID (network address) using the subnet mask. If two hosts have the same subnet ID (network address), they can communicate between each other without the use of an router.

You can do this using a subnet calculator like this one:
http://www.subnet-calculator.com/subnet.php?net_class=A

Or you can do it manually as explained in this post:
https://stackoverflow.com/questions/12918644/calculating-range-of-ips-from-subnet-mask


Closed source binary blobs in chipsets - privacy threat? I wanted to buy a Librem Purism 13 because I care about my privacy and generally wanted a laptop to test Linux on.

However, I was advised against it because it uses Intel i5 processors which contain binary blobs. From what I understand binary blobs are parts of code which cannot be read, and you are not really sure what they do. They could for example extract what you are doing on your computer and send this information somewhere.

Is this possible and if so how much of a risk is this? Wouldn't almost all recent computers be compromised? Is there any laptop that is completely open source with no binary blobs in it?

Summary:

There's probably some BS marketing going on, but on the whole they probably are making the more privacy-respecting laptop they can. Other answers mention other brands of privacy-focused laptops that avoid Intel chips in favour of 100% libre hardware, but you take a big performance and cost hit for doing it, because, well, Intel is the market leader for a reason.

Who do you trust?

Unless you go out into the woods with a hatchet and build yourself a life, you've got to place trust in somebody. Based on the descriptions on their page, the company Purism seems like a reasonably good group to place trust in (which you seem comfortable with if you're already considering buying their laptop). They clearly put a lot of scrutiny on their component suppliers with regards to privacy. Assuming of course that it's not all B***S***t marketing, which I have no way to know for sure. (See the "Additional Thought" at the bottom for more on this.)

Intel

As for binary blobs and Intel, this is actually a deeper question than you realize. "Binary Blobs" refers to software that's provided to you in binary (executable) form, but you have no access to the source code, or any good way to inspect it. Intel is a hardware manufacturer, so while they may have some binary blobs of software, what about hardware that's provided to you in chip form with no access to the designs? Do you think Intel allowed Purism to inspect the blueprints for all of the chips on an i5 board? Of course not, that's billions of dollars worth of intellectual property!

This debate around Intel, privacy and black-box hardware is currently a hot-topic with Intel's RdRand instruction - an assembly instruction for retrieving a random number from an Intel hardware-RNG chip on the motherboard. I was recently at a crypto conference and overheard one of the designers of the RdRand chip having a discussion with another attendee that went something like this:

  Attendee: "RdRand is a blackbox chip. Will you release the source designs for security audit?"

  Intel engineer: "No, of course not, that's protected intellectual property."

  Attendee: "Intel is in American company, how do we know the American government hasn't forced you to include backdoors?"

  Intel engineer: "Well, I guess I can't prove it to you, but I designed it and I can assure you that there aren't any."

  Attendee: "Forgive me if that's not good enough. I'm going to continue doing random numbers in software."

  Intel engineer: "Your loss, I guess."

So, should we trust them?

At the end of the day, unless you live in the woods, you have to trust somebody. I personally think the Intel corporation is very security-aware - having attended multiple crypto conferences with them, and while they are under American law (I'm not American BTW), I think they are at least as trustworthy as any other closed-source hardware vendor. Ken Thompson's 1984 paper "Reflections on Trusting Trust" showed that trojans can be injected at the compiler level in a way that's almost impossible to detect, so even inspected open source code is not guaranteed to be trojan-free.

At the end of the day, you're got to trust the people, not the code. Do you trust Intel? Do you trust Purism to be scrutinizing their suppliers as well as they are able to? Nothing will ever be 100% provably secure, but Purism's products are certainly better than your standard laptop from Best Buy.

Additional thought:

The Purism Librem product pages say:

  Welcome to the beautiful laptop that was designed chip-by-chip, line-by-line, to respect your rights to privacy, security, and freedom.

"Line-by-line" .... right, sure. The linux kernel itself is about 16 million lines. The Librem ships with either their Debian-based PureOS, or Qubes OS, which will both contain tens of millions more lines, plus bootloaders and firmware, plus all the apps in the Debian repositories. You want me to believe that Purism's 6 developers have personally inspected every single line of code for insidious, hard-to-catch backdoors? And have also inspected all the compilers used looking for self-replicating trojans? Please. Over-zealous marketing.

That said, if you take Ken Thompson's "Trust the authors, not the code" philosophy, and we decide that we trust the Debian devs, and the Intel engineers (I have decided to trust them out of convenience), and we trust Purism to apply the "Trust the people, not the code" philosophy appropriately, then we're probably OK.


Are these port secured on my AP? I'm doing a project for my high-school and I'm trying to get the best security for my network.

I've made almost everything in my access-point configuration and I have only 3 tcp/ports open on my AP: (Let me show you the nmap scan:)

22/tcp   open  ssh

53/tcp   open  domain

8081/tcp open  blackice-icecap

So, let's focus just on ports 8081 (for remote access to my AP) and 53 (for a DNS Server).

I'm wondering if there is anything in those services/ports that can be unsecured ? Or is there any chances of getting into my machine through these ports ?

Also... I'd like to know if there's any way to secure port 53 from an auxiliary/spoof/dns attack like this one: http://www.pax-pentest.net/exploitation/metasploitable-2-port-53-isc-bind-9-4-2-domain-name-server-cache-poisoning/

Closing unnecessary ports is a good first step, but the software running behind the ones that are open is just as important.  For instance, SSH is generally considered a secure protocol, but it's still one of the most popular ways attackers try to exploit servers. It remains a popular avenue of attack not because it's inherently insecure, but because many admins get lazy - they don't bother to update the SSH server software to the latest version, ensure that all users have strong passwords, disable login from root, use certificates, create a lockout policy, etc. etc.

So as you can see, there are about a zillion things you can do just to secure SSH alone, and each one provides one extra layer of security.  If you use all these measures, the chance that someone could still get in will be drastically reduced, but it will never be 0%.  There's no such thing as a 100% secure system.

My point is, knowing which ports are open isn't really enough to definitively say whether your AP is secure or not.  Your configuration details matter a lot, and there a ton of ways you can further increase the security of the services running on the AP.  You have to find a balance - secure enough to (reasonably) be sure that no attacker would be able to get in, but not so secure that it greatly impacts usability.

Also, you seem to be focused on securing the access point itself, but what about the network that the access point is creating and the clients connected to the network?  For example, you might want to implement WPA2-Enterprise or at least WPA2-Personal, enable client isolation, add a filter/IDS to prevent users from downloading malware, block P2P protocols and file sharing, add a usage agreement if this is a public network, block access to certain domains, log client traffic...things of that nature.


How does PGP differ from S/MIME? Is S/MIME an abstracted system for general MIME type encryption, whereas PGP is more for email?  Why would I want to choose one over the other, or can I use both at the same time?

Summary: S/MIME and PGP both provide "secure emailing" but use distinct encodings, formats, user tools, and key distribution models.

S/MIME builds over MIME and CMS. MIME is a standard way of putting arbitrary data into emails, with a "type" (an explicit indication of what the data is supposed to mean) and gazillions of encoding rules and other interoperability details. CMS means "Cryptographic Message Syntax": it is a binary format for encrypting and signing data. CMS relies on X.509 certificates for public key distribution. X.509 was designed to support top-down hierarchical PKI: a small number of "root certification authorities" issue (i.e. sign) certificates for many users (or possibly intermediate CA); a user certificate contains his name (in an email context, his email address) and his public key, and is signed by a CA. Someone wanting to send an email to Bob will use Bob's certificate to get his public key (needed to encrypt the email, so that only Bob will be able to read it); verifying the signature on Bob's certificate is a way to make sure that the binding is genuine, i.e. this is really Bob's public key, not someone else's public key.

PGP is actually an implementation of the OpenPGP standard (historically, OpenPGP was defined as a way to standardize what the pre-existing PGP software did, but there now are other implementations, in particular the free opensource GnuPG). OpenPGP defines its own encryption methods (similar in functionality to CMS) and encoding formats, in particular an encoding layer called "ASCII Armor" which allows binary data to travel unscathed in emails (but you can also mix MIME and OpenPGP). For public key distribution, OpenPGP relies on Web of Trust: you can view that as a decentralized PKI where everybody is a potential CA. The security foundation of WoT is redundancy: you can trust a public key because it has been signed by many people (the idea being that if an attacker "cannot fool everybody for a long time").

Theoretically, in an enterprise context, WoT does not work well; the X.509 hierarchical PKI is more appropriate, because it can be made to match the decisional structure of the envisioned companies, whereas WoT relies on employees making their own security policy decisions.

In practice, although most emailing softwares already implement S/MIME (even Outlook Express has implemented S/MIME for about one decade), the certificate enrollment process is complex with interactions with external entities, and requires some manual interventions. OpenPGP support usually requires adding a plugin, but that plugin comes with all that is needed to manage keys. The Web of Trust is not really used: people exchange their public keys and ensure binding over another medium (e.g. spelling out the "key fingerprint" -- a hash value of the key -- over the phone). Then people keep a copy of the public keys of the people they usually exchange emails with (in the PGP "keyring"), which ensures appropriate security and no hassle. When I need to exchange secure emails with customers, I use PGP that way.

OpenPGP is also used, as a signature format, for other non-email tasks, such as digitally signing software packages in some Linux distributions (at least Debian and Ubuntu do that).


Is it possible for an SSH MITM to attack only if the key isn't in the known_hosts? I was trying to connect a server using a different port when the network seemed too slow. It gives an ECDSA key, while the previous key in the known_hosts is RSA. I refused to continue the connection and tried more times using both ports, and never got a warning. Finally I connected to the server using the original port, and found that the server doesn't have any ECDSA keys.

It may just be some sort of DNS error or gateway error. But is it possible to be used in an attack? Some careless new users may get their servers compromised, and other users with the key already in known_hosts may never notice the attack has happened.

And if it is used in an attack, would it be safer to use public key authentication instead of a password?

Here is my theory for the attack:

The attacker firstly scans the server to make sure it doesn't have an ECDSA key. If a client tries to connect without specifying the algorithm, it says it only has the ECDSA key. If instead the client choose to use RSA, the attacker can redirect the connection to the real server without being noticed.

If the redirection is impossible, the attacker may try to make the network apparently very unstable, and finally disconnects before sending the key. Since it never sent a fake key, the user never get the warning that the server key is changed.

They may also set a small probability to just let the user connect to the real server, so they are unlikely to investigate this problem. And they can add the ECDSA key to the real server if the attack is successful, to pretend that the attack never happened.

More specifically, is the algorithm selection part done before verifying the server key, and does it work in a way that may leak the known_hosts status without a warning?

An alternative theory would be an attacker is only intercepting the traffic on specific port. But I'll be able to confirm only if this problem appears again later.

Edit: It turned out to be some very weird server configuration. (The virtual machine get cloned by someone with the privilege, and one of them has upgraded to have an ECDSA key. It was swapped with another when I connect.)

First of all, the answer depends on your SSH client. Let's assume you are using latest OpenSSH client.
The SSH2 protocol starts like this:

Client -> Server: Initiate connection, send client software version + SSH version
Server -> Client: Server software version and SSH version
Client -> Server: Client supported algorhitms
Server -> Client: Server supported algorhitms
Client -> Server: Diffie-Hellmann key exchange init
Server -> Client: Diffie-Hellmann parameters and server key!

Let's say known_hosts contains the known good RSA key, but the server sent an ECDSA key. OpenSSH detects a key change!

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
78:16:03:b0:88:c3:9b:a7:7d:34:87:a5:8b:36:f1:4f.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending RSA key in /root/.ssh/known_hosts:1
ECDSA host key for 127.0.0.1 has changed and you have requested strict checking.
Host key verification failed.

Now the question is: Is StrictHostKeyChecking set to yes in your SSH config?

And last but not least, if you are worried about being hacked by an SSH MiTM, I suggest you authenticate with SSH keys instead of using passwords. It is much more secure, and your password is safe (as long as you don't use the password for sudo :) or something else).


Using /usr/bin/passwd as login shell I have a requirement to set up a SSH tunnel between two hosts. SSH server runs on a Linux host, and the SSH client (PuTTY) runs on a Windows host.

I have set up a separate user account (say 'tunnel') on the Linux machine to allow this. This user is not supposed to execute any commands but will only keep the SSH connection for tunneling when logged in from PuTTY. For that particular reason, I have set /usr/bin/passwd as the login shell for this user.

My question is,
Is this a good practice in terms of security when it comes to a SSH tunnel?
I couldn't find much information on the Internet about this setup but read that this shell can be used on a file sharing server.

In general, we set the shell to /bin/false and provide the -N option when creating the tunnel, something like;

ssh -D 4444 -N -i ~/keys/user_id_rsa user@remote.com

The -N switch tells ssh not to execute any commands upon connection, without it your connection will immediately close due to the /bin/false shell.

You could use /bin/rbash to provide some basic functionality, but if you only want to be able to tunnel, I would advise against it.


Is the MAC address encapsulated in the Internet packets? This might be a stupid question, but what is the range of the MAC addresses? Are these somehow leaking to the Internet with packets that a user sends (so they know where to return)?

Wikipedia is awesome: it contains a lot of useful information. In this case, the following schema:

So there are basically 46 bits for global unicast MAC addresses, for 246 possible addresses.

MAC addresses do not leak beyond your local link (machines on the same LAN as you see your MAC address, other people do not). IP addresses are used for global addressing, not MAC addresses. Exception: if you use IPv6, your machine may obtain an automatically allocated IPv6 address, and the scheme for creating such addresses uses MAC addresses, as described here. In that case, your MAC address can be inferred from the source address in the IP packets your machine emits.


Data deleted after encryption - recoverable? My device (Android 8.0) is encrypted with the default encryption (no startup password). As far as I know, when I have data on my phone and factory-reset the phone, the data is unrecoverable, since a new key for the encryption is being created and the old one is getting deleted. (Am I correct?)

Now, what happens when I delete data on that same phone AND THEN factory-reset the phone - can the deleted data be recovered?

The data can be recoverable.

The factory reset should delete all data, accounts, passwords and content from your Android device. The problem is, this is only partially true.

Cambridge University researchers tested a range of Android devices running Android and found that in all cases they were able to recover account tokens – which are used to authenticate the 1st time you enter a password (Google, Facebook and WhatsApp). In 80% of cases, they were able to recover the master token, which practically is the main key to the device. Once the master token is recovered, the user’s credential file can be restored and all your data re-synced to the device: that means e-mails, cloud-stored photos, contacts and calendars. So you just offered access to everything!

Devices with built-in encryption are not safe from such a problem because they don't provide the required software to fully correctly wipe flash storage.

Also, it is possible to create an image of your phone’s internal memory and the mount it and dig into it as long as you want.

What you can actually do:

encrypt your phone with a strong password that contains a mixture of upper/lower-case letters, numbers, symbols and is long enough
after reset, fill the device with useless data to overwrite anything sensitive like the tokens and crypto keys left in flash storage and you should do it without re-registering with Google. You can do this fill by copying something or just by recording a video for as long as you can, at the highest possible resolution, until all your available space is full.
finally, reset again


testing for 'Dangling Cursor' While reading the updated Top 25 exploits in the Common Weakness Enumeration I came across an exploit that I was not familiar with. It is numbered CWE-619: Dangling Database Cursor.

I was wondering if there are any tools, similar to a Sql Injection fuzzer, that I could use to test my server for possible exploits. I am running Windows Server 08 with Oracle 10g on IIS 7. FOSS would be great, but I would pay some for a solid testing suite that can check for this exploit.

I'm not aware of any publicly available toolsets for this at the moment, but there's been a couple of interesting white-papers and postings recently on the general security dangers of cursors

Two from David Litchfield here and here

and an interesting blog posting from Pete Finnigan here


Secure endpoint for root domain only, no subdomains I have an existing endpoint, for example https://api.example.com/ ... I have an existing CORS policy enabled which only allows access from origin example.com.

However, when I visit the endpoint URL directly (ie. https://api.example.com/api/login in my browser, I am able to access the API endpoints directly from there.

Is there a way or best practice to make your API inaccessible from the api.example.com subdomain directly and only accessible from example.com?

I understand they are of the same origin ... in this case, example.com but is there anything I can do?

I have some functions which are supposed to be anonymously accessible, the rest require a JWT token.  I'd like to protect these anonymous endpoints so they can only be accessed from my own example.com servers.

Would appreciate any feedback as I'm convinced I'm really missing something obvious.

Unfortunately what you are trying to do is effectively impossible because HTTP simply was not intended for this use case.  I think there are a few misunderstandings that are confusing the issue for you.  Running through things:

There is nothing special about browsers.  Browsers are just a fancy HTTP client that can send HTTP requests to an HTTP server.  However, they are not the only HTTP clients that can send requests to a server.  If you have ever made HTTP requests from your own server, you are already aware of this.  Similarly tools like postman, curl, etc, are also HTTP clients and can make HTTP requests to your server, except they are not "running" on a domain anywhere.
In fact the whole question of "what domain is making this request?" is a concept that doesn't exist in HTTP.  It's easy to misunderstand this fact because of how CORS works, but CORS is something that is baked into browsers - not HTTP.  CORS is only meant to protect HTTP requests made by javascript on a webpage inside a browser (again, it's not strictly part of HTTP).  As a result if you put up a completely restrictive CORS policy banning access from everywhere except your main domain, that CORS policy would do absolutely nothing if someone visited your API endpoint from literally any other HTTP client - which is what you just discovered.  Anyone using postman, curl, etc would still be able to access your API endpoints without issue, regardless of what CORS says, because CORS only matters for browsers.
Blocking by domain is impossible because HTTP doesn't know anything about domains.  When a client makes an HTTP request it first uses a DNS service (if needed) to convert the domain name of the destination into an IP address.  The client then sends its HTTP request to that IP address.  The only thing the server knows is the IP address of the client.  All other information is provided by the client and can therefore be easily spoofed by an attacker.  I say this because while some browsers may attach information to the HTTP request stating what domain the javascript that made the request is running on, a non-browser client can easily do the same and lie, claiming to be javascript running on your domain.

In short the only thing the server knows is the IP address of the client (technically that can be spoofed to, but it is substantially more difficult).  All other information about the request is provided by the client and therefore cannot be trusted for security purposes.

It may help to brush up on the basics of HTTP.  The details in that link break things down well.  The link also happens to focus on browsers as the HTTP client, which we know is not exclusively true.  Ironically articles like that one are why misconceptions like yours are common :)  Still, with a proper understanding that HTTP clients can be anything, that link should be helpful.

This doesn't answer how to secure your endpoints.  I can't give you an answer there without more details, which would basically make this a new question (aka you'd be better off asking a new question than editing this one, I think).  In general there are lots of strategies, but the short of it is that you can't have an anonymous endpoint and also selectively block users, except by IP address (which isn't possible for endpoints that are supposed to be accessed from a browser).  As a result there is only one general answer: you need to put some kind of authentication on the endpoint, even if it doesn't specifically require a login.


Is this some sort of hacker attack? I'm using a tool on my website that detects any error and sends me an email when a code error happens. Recently, I've received some requests not allowed on my IP - not url - where only GET is allowed.

The requests all come from the IP 173.187.177.22 and, besides happening once a minute or two, have a strange input. Here's a few examples of the input passed on three different requests:

array(1) {
  ["QqIKyIubMeV_mOiW6N7CL6c1rCSY9W1cSlveqfTb9P9cpfwTTOL1sOUdhvIphPNeVGdeKl9lhHf7ADk9gLNgePAZdO/ygtxofmT/sfbFyrBKzGvrWRVL6kT2zbkVrV1dOXIQkhDuUUpacUnKuaPkB78z85jmqjY1l7hXnLIONUtctt679mbW9KPHoq1ozFK6Ki1hfN9WnwnaN14akSGWZkDfoVDFdrneVf4JDOlfY3r78Gp39bueUaHn6aMEAGys3MEEjr4ghbHe0T6MURgQyHZHoV1olgRiAo5xRjChrhjD7w/pYaaNi0_6DKHMJBS7H9_bw8I/qaOoFy/EeO4G3QFiIlpcutIEf62YOwlk53MzuuLM5eje9I_TUXc9XmC/kU9EX2QDYYT9wGmg3w/7YJSOIIgi"]=>
  NULL
}
array(1) {
  ["RfZWlNmbZ3O21/tLFs9AFHaO5zr9g/FArn8djhJGYhqs32THrVCnqDI/xUAJcg0DGKi6a/FEz7PzB7GWu72B7uA3ZvdKfNUhSCZR39If6oOCATHN9VYgzYJQfDaPrcqJh3IBaHPcJSgUXsv_amGKAd6AJ675AtCvMfdYUQk5V/Pc1X2LR2M7uDfEW1Mv2S9mHSZSLYV_cDAJFOavCtxfyLQms3kOudm_arsbkn2kQbh1LvaC0iP0aDSfmmEmtFIX_rmMwSGFghPV1mZtELD6NEjuorMwix70CvGi/g27CRmU0qtuVwwlhf67Qi7cZBNCOzAb_mFMfUnp1E4kWhbvIpNyo_c0TuwM_BNRKm9UQc8rdWPk8CmN"]=>
  NULL
}
array(1) {
  ["RfFelN_ZbKsBnezpI20p0My0Rd7Gzx4bNeu9iTNNiizOsqFE_uCyvsWkg_zvep1KlWlp9fTNSImM9hitT/Zrs/UvxMgTp1llGwg1a3WinrqPXZSySmQkaU7WXXHHf/_sWk1OcEp6PfFXczId60vlvr9X7OTVlNDLW7oET38xmCV0Q7sL_s/iLlilTAHIh7ICTxqOTzO2ONFFpcqy/wD6Hw4TEFiS1g6APil_/aJkbd/My6ESB4jXehj3HhEbLUWVRsQlJa6cCVKJpwieEAiZCi/N2EgaEd3jxRdKrIA75VgVPteDdqaSnPUljHXerCMic2UzVfLqWvK4w8beTnoKnQacmJf8c6ANr8l3fU2pQn7zmqdzO/LL6MNsbVF0B0G9iFm0x9fO0cuN8MUW5IlI289ILTvpLpJL2Qg6QQ"]=>
  string(1) "="
}

Any suggestions on what I should put in place to prevent this kind of behavior? In the past I've blocked the IPs responsible for this from .htaccess, but ideally I don't want to continue blocking IPs manually since if it is some sort of attack it could bypass IP

The standard way to address unexpected and invalid inputs from web clients is to install a WAF (web application firewall). There are free and paid versions.

In this firewall, you configure the types of valid inputs and you can drop/reject/correct invalid inputs. Not only can this help with bots/hackers testing your app for weaknesses, but it can address things like SQLi, XSS, etc.

While a WAF can get complex fast (you can define valid inputs for each one of your functions, which is something to consider), you can also provide "broad stroke" protection and define that POSTs are invalid, for instance.


Dangers of using the web applications provided by password managers The password manager bitwarden requires the user to log in to their account on their web site to allow them to enable 2FA, import passwords and manage other account related details, as that functionality is not available on the desktop or mobile applications. Could a supposed attacker that has gained control of a self hosted instance inject malicious JavaScript code into the web page front end to steal the user's password? What are the options for an attacker to steal the keys to the password database when the user uses the web vault? Could such an attack be avoided by using an application that does not pull logic from the server?

If someone gained access to a self-hosted instance, that would certainly be possible. But if an attacker were able to get the user's passwords, they would need to send them to a remote server or login back into the instance to get the data.
With a self-hosted instance, I would be more concerned with how data is transferred between the server and the client. Do you have a valid SSL certificate installed with strong encryption parameters? Using a self-signed one isn't safe and poses a larger risk than a malicious Javascaript file because it would be harder to detect a network sniffer rather than hack into a server. You could also be susceptible to a man-in-the-middle attack where an attacker forwards you to a server under their control where they can intercept the network traffic and decrypt the data.
https://www.computerworld.com/article/2569788/sniffing-out-network-sniffers.html
https://www.thesslstore.com/blog/risks-of-using-self-signed-certificates/
What are the risks of self signing a certificate for SSL
https://www.rapid7.com/fundamentals/man-in-the-middle-attacks/
Either way, once an attacker has that level of access to a system where they can manipulate the software like that, they'll probably be able to access the passwords in multiple different ways. The best way to prevent unauthorized access to a self-hosted password manager like the one you're describing is to limit who has access to the server.

It shouldn't be publicly accessible on the internet
A firewall should be installed which blocks all ports except the one that is required to be open
A network firewall rule should also block all ports except the required ones and also grant access to computers that need access.
Is Javascript needed in the Bitwarden admin interface? You could install an extension called "No Script" which blocks javascript files from loading on certain websites.

LastPass has a setting that you have to enable where it requires you to enter your password every time before viewing a password in the password manager.
https://bitwarden.com/help/article/security-faqs/


Is server public key and Diffie Hellman public are the same? I am trying to understand the working of TLS. I understand that there are various way to generate the master secret used to encrypting the data. Such as DH (Ephemeral DHE) and RSA. I understand that, when using RSA, the client generated pre-master key is encrypted by server's public key and is sent back to server for the computation of the master secret. But what about the process when using DHE?

I see that DH public keys of both client and server is used to compute the Master secret? But, is the DH public key the same as the Server's public key?

In Layman's term, is the RSA public key considered as the server's public key?

CloudFlare explains that Diffie-Hellman and RSA, both used in key exchange mechanisms, have advantages. Keyless SSL: The Nitty Gritty Technical Details
.

The RSA and DH handshakes both have their advantages and disadvantages. The RSA handshake only uses one public key algorithm operation, RSA. A DH handshake with an RSA certificate requires the same RSA operation, but with an additional DH operation. Given that the certificate is RSA, the RSA handshake is faster to compute. Public key algorithms like RSA and DH use a lot of CPU and are the slowest part of the TLS handshake. A laptop can only perform a couple hundred RSA encryptions a second versus around ten million per second of the symmetric cipher AES.
The DH handshake requires two algorithms to run, but the advantage it brings is that it allows key establishment to happen independently of the server’s private key. This gives the connection forward secrecy, a useful property that protects conversations from being decrypted after the fact if the private key is somehow exposed. The DH version of the handshake also opens up the possibility of using non-RSA certificates that can improve performance, including ECDSA keys. Elliptic curves provide the same security with less computational overhead. A DH handshake with and elliptic curve DSA certificate and elliptic curve Diffie-Hellman key agreement can be faster than a one-operation RSA handshake.

I believe Diffie-Hellman and its TLS/SSL usage will further explain.
Presuming the "server's public key" is used for authentication, then no. The DH public key and the server public key, are not the same. However, I have seen very much mixed opinions on this matter. TLS 1.2 appears to use DH and RSA for the key exchange mechanism.
DH is used to produce the symmetric key for a symmetric algorithm. DH in itself is not a data encryption algorithm necessarily, but a way to agree on a secret key via a public network.


RBAC and assertions, which authorization flow is better? I'd like to ask which authorization flow is considered better or standard.

First approach (has role AND assertion is valid):

if (!isGranted(roles, permission) {
    return false;
}

if (hasAssertion(permission)) {
    return assert(getAssertion(permission), context);
}

return true;

Second approach (has role OR assertion is valid)

if (isGranted(roles, permission) {
    return true;
}

if (hasAssertion(permission)) {
    return assert(getAssertion(permission), context);
}

return false;

Edit: I'm designing the chat application, with users having different permissions in different chat rooms.

You're suffering from the lack of richness in RBAC. What you really want to consider is attribute-based access control. For instance in this case, you could define rules such as:

a user can post in a room he/she is assigned to
a user with the role moderator can edit messages in a room he/she is a moderator in
a user can edit their own messages...

All these are examples of attribute-based policies / rules.

NIST has had an ongoing project on attribute-based access control. You can read more on this model here.

You can also check this YouTube video for the basics of attribute-based access control.

To implement ABAC, have a look at XACML, the eXtensible Access Control Markup Language defined by OASIS.


Erasing Lastpass Preminum from mobile phone This morning I dropped my LG G4 (android 6 Marshmallow) phone and shattered the display. I plan to buy a new shiny phone and sell the old one cheap.
I use Lastpass Premium to to store all my passwords,and since I´m a IT consultant I have hundreds of VPN and server logins stored. 2-factor authentication is not enabled neither for Lastpass master login or for the majority of the stored credentials so I really need to make sure that there is no way for an attacker to gain access to my vault.
What steps can I take to make sure my data is safe? As I understand each device with Lastpass keeps a cached copy. So even If I change my master password an attacker might be able to restore that file from the file system and, given he has full access to the phone, find the (old but still valid) password written to disk by some obscure driver deep down in Android.
If the risks involved by selling my old phone is deemed to high, I am willing to crush it with a hammer ( if that is secure enough will be a follow-up question :-)
Preemptive EDIT: I enabled 2-factor authentication for Lastpass master login.
EDIT: I will of course do a phone reset and wipe/remove files before I sell the phone.
EDIT2: I believe my question is not a duplicate because it is not made by Nexus (resetting procedure prob. different), Android version differs, and I am particularly concerned about Lastpass which is not mentioned in the other question.

Another thing you can do is to remove it from "Trusted devices". You can achieve this with the following steps:

Login to LastPass
View your vault
Click on Account Settings (near the bottom left of the screen)
Click the third tab in the popup window named "Trusted Devices"
Disable or Delete the broken phone


At what point is a Bitlocker drive unlocked and how does additional pre boot pin add to security? If I enable Bitlocker on a regular Windows 10 machine, how does the unlocking process work? I presume I put in my Windows password and at that point it starts the unlock process. Why is there an additional pre boot option and how does this add to security?

No, thats not how BitLocker works. BitLocker has an additional partition thats stores information about the encryption/decryption process together with some metadata. It holds the cipher used, block mode, keysize, number of used slots and authentication method (amongst other things).

With enough information from this partition the decryption process can begin. The user is asked for his passphrase or private key file (in case of USB) and can decrypt the modules, driver and bootstrap executables in order to load the kernel.

The disk is not decrypted at boot, but instead Windows makes use of an additional IO layer. This layer hooks between the file system driver and the disk driver and decrypts the information on retrieval (and encrypts on write). As long as the operating systems runs, the secret is stored in protected (kernel) memory. Therefore it is important you shutdown the computer gracefully and give Windows the time to nullify the memory. The same is true for other systems.


Which parameters can I use to analyse my cipher? I have made a new methodology for a symmetric key cryptography in which I have used matrix operations, a boolean function and ASCII conversion. Please suggest me the possible parameters to judge my algorithm.

Now please suggest me the possible parameters to judge my algorithm.

The most important parameters at the current development stage of your algorithm are probably:

your understanding of other algorithms
your ability to break other algorithms, or at least to fully understand how others manage to break them
your knowledge of number theory
your relationship with recognized experts in the field of cryptography

If you really have the necessary knowledge to create a new algorithm then you would not need to ask here for the important parameters to judge it. If you algorithm is good enough than you will manage to get a recognized expert to look at it. If you don't know any of the experts then I doubt that you will be able to create a good algorithm.

I also recommend to look at the nice analysis of some other homemade algorithm just to get a feeling for how easy it is to get things wrong.


Does Kali installed through WSL respect my privacy? When installing Kali from Microsoft Store, I wasn't prompted with a user agreement license.
Is Microsoft able to monitor my applications? How safe is it to use WSL in that context? (From privacy perspective)

As mentioned in the comments of this question, Windows has many telemetry features. Ones which you cannot disable, either. There are some settings you can change to reclaim some privacy but in general, you cannot remove all the tracking features. This makes it a horrible operating system as far as privacy is concerned.
Additionally, their service agreement effectively gives them control over any content you generate on their system. This is also terrible for both you and your privacy.
If you're concerned about your privacy then don't use Windows at all. It is a horrible OS in terms of privacy.


Silently Limiting Login Attempts I've seen the following login rate limiting approach used on a web site I worked on, but I can't figure out if it's a good idea:

After any failed login attempt, the site locks the user account for a fraction of a second. When the account is locked, any login attempts will fail, even attempts with correct credentials. The user is not told that their account is locked, only that their login failed.

The idea is that real users will generally take longer than the lockout time to re-enter their credentials (and will probably re-enter them more slowly the third time if they accidentally trigger the lockout). Meanwhile, hackers brute-forcing passwords would trip the lockout with high-volume login attempts.

What are the problems with this approach?

A brute-force can implement pauses to match the short lockout gap you are presenting, so this would slow down a brute-force script.  However, locking the account permanently (or forcing CAPTCHA & security question in addition to future login attempts) after x-number of consecutive failed attempts is a better way to accomplish that goal.  Your approach does have a little merit, but you would certainly want to couple it with the traditional anti-brute methods.


Can DeepCorr's correlation technique de-anonymize all Tor users? https://people.cs.umass.edu/~amir/papers/CCS18-DeepCorr.pdf

https://www.youtube.com/watch?v=_OKLtKgEn4k

I have some questions about this "Deepcorr". Does "DeepCorr" really work that good? They say that "DeepCorr’s performance does not degrade with the number of test flows", but more people are using Tor more and more people browse websites (many of those are simple websites) with similar sizes around the same time, so how can they tell the source of the traffic using size and timing alone when other flows have similar features?

They said they used 1,000 circuits to browsed 50,000 sites (the top sites on Alexa) with each circuit browsing 50 sites and they also used regular Firefox browser instead of Tor browser. Could it be the reason for why it worked so good for them? Maybe Firefox generated some extra unique traffic that Tor browser wouldn't generate because of things like ads and cookies?

Can this attack work against hidden services (version 3) as well?

Can DeepCorr's correlation technique de-anonymize all Tor users?

No, it cannot de-anonymize ALL Tor users.

(however it drastically narrows down the scope to proceed with successful de-anonymization)

Why, and what is flow correlation attack

Flow correlation attack is an attack where adversary intercepts network flows at various network locations "correlating" them using math statistics or machine learning methods (e.g. neural networks).

DeepCorr's setting consists of a network "with M ingress flows and N egress flows": DeepCorr listens to ingress flows, being closer to the group of users at the one end, and it just tries to figure out the moment when traffic starts leaving the circuit at another end. And it means "gotcha"!

Website != flow

  more and more people browse websites(many of those are simple websites) with similar sizes around the same time
  how can they tell the source of the traffic using size and timing alone when other flows have similar features?

DeepCorr does not do website fingerprinting (which is another class of attacks, as mentioned in the article), it just correlates a "flow A" to "flow B" at two different points of network.

Website similarities don't matter for successful correlation, DeepCorr operates with features of small packet sequences: sizes, times, flow direction (in/out), etc.

Still...

Correlation != de-anonymization

From the article:

  To be able to perform flow correlation, an adversary needs to observe (i.e., intercept) some fraction of flows entering and exiting the Tor network. The adversary can then de-anonymize a specific Tor connection...

I would say "but may not de-anonymize"... I mean that seems like a successful flow correlation attack doesn't automatically mean a successful de-anonymization. Correlation means "these users visited those group of sites" (but it drastically narrows down the set of users and increases de-anonymization probability).

Does Firefox generate additional patterns?

  Could it be the reason for why it worked so good for them? may be firefox generated some extra unique traffic that Tor browser wouldn't generate because of things like Ads and cookies?.

In my opinion there is no much difference between Tor and Firefox traffic flow.

Example: google.com

Firefox:
25 requests
1.31 MB / 677.67 KB transferred

Tor:
19 requests
1.39 MB / 498.30 KB transferred

Intuitively, I would say that both browsers generates some unique patterns of flows, and doesn't forget that website != flow.

Also seems like DeepCorr doesn't need too much of traffic to measure:

  "the correlated flows are 300 packets long for all the systems"...

Tor's hidden services

  Can this attack work against hidden services(version 3) as well?

I would say "why not": DeepCorr performs on traffic flows, it doesn't care whether the flow is "hidden", and hidden service is just another traffic flow. DeepCorr will correlate ingress and egress, and it is what it does.

P.S.: a few words about a possible countermeasure.

Countermeasure

As authors stated:

  "Our results suggest that (public) Tor relays should deploy a traffic obfuscation mechanism like obfs4 with IAT=1 to resist advanced flow correlation techniques like DeepCorr."

(IAT=0 doesn't help)

  "However, this is not a trivial solution due to the increased cost, increased overhead (band-width and CPU), and reduced QoS imposed by such obfuscation mechanisms... designing an obfuscation mechanism tailored to Tor that makes the right balance between performance, cost, and anonymity remains a challenging problem for future work."


From password to key Can you explain this passage from Wikipedia?

  When a password (or passphrase) is used as an encryption key, well-designed cryptosystems first run it through a key derivation function which adds a salt and compresses or expands it to the key length desired, for example by compressing a long phrase into a 128-bit value suitable for use in a block cipher.

A longer password is more secure (in terms of bruteforce attack) than a short one, isn'it?

If the password is "pass", what's the resulting key?

Cryptographic keys are usually fixed-length values. Unfortunately, humans can't remember long strings of numbers, so we use passwords instead.

For example, this might be your 256-bit key:

d4f6d068b4e8c4e924ce9b28585a6009672e56d61215e7d9251b5d36283edd5d

Not too easy to remember, is it?

However, the above was generated by computing a cryptographic hash (in this case SHA256) of the word "waffles", which is much easier to remember. A hash function takes an arbitrary length input, and computes a fixed length output.

In reality, we need key-derivation functions (KDFs) to have special properties. One desirable property is that it should be computationally infeasible to compute m from h, where h = KDF(m), i.e. it's difficult to compute the input of the function if you only know the output. Another desirable property is that the function is computationally expensive (slow) enough to make computing millions of keys infeasible, without degrading performance for legitimate uses. As such, special KDF schemes such as PBKDF2 and bcrypt are usually used to compute these cryptographic keys from easily remembered passwords.

The only practical way to break a key generated by an ideal strong key-derivation function is to guess likely passwords. If your password is "password", it's likely to be broken. If you password is a string of 20 random letters and numbers, it's much less likely to be guessed.

To address the question you ask at the end:

  If the password is "pass", what's the resulting key?

This isn't really a question that makes much sense. The result could be anything. There are lots of different hash functions (MD5, SHA1, SHA256, SHA512, Whirlpool, RIPEMD160, etc) and many different key-derivation functions (PBKDF2, bcrypt, scrypt), which can use salts or HMAC. The possibilities are endless!


URL shortener who does nothing according to the owner I talk in a security forum, and sometimes a moderator share links to sources about things he talk about, but when I hover on these links, the link is different the the source it self. It is actually a URL shortener that he himself built which associated with his website. I thought it is self profit.
I asked him why he does that

What personal gain are you talking about? Do you see an advertisement
when you click on the link? You get 301 from the server, there is not
even a BODY for response from the server.

And then he also added:

Think about how it can benefit someone who is in charge of providing
resources in almost every one of his posts.
I'm the only one who can create shortcuts under this domain.
A. I do not see IP addresses in the UI. B. I see countries of
origin. C. I see a referrer if the browser has not filtered (so I
can theoretically know from which forum post they came).  D. I
have nginx level logs where I can see an IP address. I only access
this log if I have to worry about problems and even then I do not care
about the addresses unless it is an attack.
Although I have log systems, the logs are not sent there, because this
information really does not interest me. The answer obtained is 301
without content. No advertisements, so no personal gain.

What can it be? is it sounds like something malicious? I have clicked on his links.

This does not sound like anything malicious or even special. It is not that hard to have personal URL shorteners which do just what the name suggest: provide a short URL. These are much easier to share with others than a long URL. There is no need to have extra functionality on top of this when all one wants to do is to provide a short URL.
Also, if somebody wants to share a malicious link they can do just this. It is not clear from a link what is behind it, i.e. not clear if it is malicious or innocent. A URL shortener does not add any layer of obfuscation here since it is not clear from beginning.
This is different with public URL shorteners though: a established and kind of trusted public URL shortener can be used to hide links to malicious resources behind a trusted site. But this is not the case here - the private URL shortener has no more trust than the long URL it points too.


Is a wireless receiver a security weak point? I have bought the Logitech Wireless Presenter R400, and it includes a Wireless receiver that it should be plugged in to the computer in order for the remote send signals to the computer.

I would like to know if that receiver is a weak point that can give an attacker the ability to breach into the computer? I would like to know if you know about any attack against wireless receivers.

I guess that the Wireless reviecer is just like any Wireless card (maybe with less features) hence it isn't a good idea for me to use it with the computer.

My security needs are at the highest level, so is this device appropriate?

It's wireless, so you might be able to sniff it if it doesn't use encryption by monitoring the connection.

However since it probably closed source you will not know if the program driver supplied is safe. Does it use RSA or AES encryption ? Even if they use these protocols, might they be extracted from either remote or receiver ?

Can someone else send signals with their remote (maybe by analyzing their remote and apply some homebrew that hasn't been published yet) ?

Wireless devices are per definition often less secure than their wired equivalents. If you want complete security, don't use it.


What are the differences between an encryption seed and salt? Today I had a hard time explaining the difference to a friend.

I know seeds are used when generating "random" strings. And salts are used when providing different outcomes to a hash.

What is a better way of describing these concepts and their possible differences.

Seed:

Encryption is powered by random numbers, but how do you generate a truly random number? The current millisecond? The number of processor threads in use? You need a starting point. This is called a seed: it kicks off a random number.

Salt:

When you hash a string, it will always end up with the same hash.

foo = acbd18db4cc2f85cedef654fccc4a4d8 every time.

This is a problem when you want to store things that you want to keep truly hidden (like passwords). If you see acbd18db4cc2f85cedef654fccc4a4d8 you always know that it is foo. So, you simply add a "salt" to the original string to make sure that it is unique.

foo + asdf = e967c9fead712d976ed6fb3d3544ee6a

foo + zxcv = a6fa8477827b2d1a4c4824e66703daa9

So 'salt' makes a 'hash' better by obscuring the original text.