Embedding hidden data inside files I need to embed a unique ID hash string in many types of files, and then verify the hash string inside the files later on remotely.

Is there a best practice for doing this?

You can't simply embed a hash inside file types if the file type is not designed for that. By doing so, you will probably break the file and it cannot be used until you have undone this change.

However, you can put the hash codes into a separate file, e.g. a CSV file. Put the (relative) file name first, then the hash. Transfer all files to the target PC and check against the hash codes of the CSV file (or whatever your use case is).

If you want the hashes to be invisible for a user, place the CSV somewhere where it's not obvious and remove access rights. Note that someone with administrator rights can still take ownership of that file and modify or delete it.

Another idea: you can try putting it into an alternate data stream (ADS) if you're using the NTFS file system. However, note that ADS are removed when copying to different file system. Also note that someone who is aware of ADS can still reveal those streams, modify the content and delete them.

All above options are not secure. If you want a secure solution, your hashing approach needs to be combined with some sort of encryption.


How does sync.com provide zero knowledge for secure links? I tried to use sync.com for it's advertised zero knowledge. But I'm skeptical. If I create a link without a password and share it with a text message, my friend who gets this link is able to download the document and view the content. However my friend doesn't know my password. Therefore, i conclude that once i create a link, it means sync.com creates an unencrypted copy of my document on their cloud (COMPLETELY UNENCRYPTED). Therefore creating links (without passwords) essentially defeats the purpose of zero knowledge. Is this correct? So sync.com cannot claim zero knowledge for links and should explicitly state so

I've only looked at this briefly, but a sync link looks like this:

https://ln2.sync.com/dl/84d6f6440#4m2d2kjd-5gvmbx6i-zb4ersxn-d585kpiw
                                 ^

The characters after the hash (the fragment) are not sent to the server. I expect the server uses the ID in the path to fetch the encrypted file, and the fragment is used as a key for client-side decryption.


Public WiFi policies I'm the admin for my company and unfortunately, the majority of the company is tech-skills limited. I need to impress upon them the need and reasoning for updating publicly WiFi hot-spots at our locations so that the passwords change weekly.

Does anyone know of any good white papers or articles that discuss the dangers associated with keeping the same password for extended periods of time?

To explain further, the wifi is at restaurants which have been plagued by homeless that "squat" in there without purchase, others using the free wifi to download porn and torrents, and other physical security issues. The wifi is offered free to customers but needs limitations and uses the same modem that the point of sale operates on (in the DMZ though). Security (both physical and virtual) is limited so I update the passwords weekly to help improve our protection. But explaining how leaving a simple WiFi password on an publicly visible and accessible hotspot opens the door to penetration and exposure is difficult to explain to non-security minded persons.

Changing the password regularly won't stop some of your problems (ex.: downloading porn or illegal stuff), as the users will still be anonymous and/or unidentified and/or non-customers.

To prevent that, you could change the way the login at your Wifi is made.

A common technique is to have a public Wifi that redirects to a login page. In that page, your customers will provide some information (ID? Name? Facebook login? A specific code delivered together with their order?). Once that information is provided, they'll be able to access the internet.

And yes, you can setup a proxy / firewall rule blocking some sites, some downloads, etc.

For example: http://www.dd-wrt.com/wiki/index.php/Chillispot


Securing session storage and whether appropriate for Open Banking I'm currently building a web application that utilises Open Banking through Plaid. This means that it pulls a users banking details through a generated 'access token'.
I've been toying with the concept of how to persist this user data. My reasoning for this is that the Plaid API gets pulled on every web page that requires it, and so it causes a several second 'loading' to process - which if you're navigating round my app is frustrating.
This is a poor user experience in my opinion, and so I'd prefer to somehow persist this data without having to make a server call.
To do this, I've initially gone for session storage. I know many people say this is vulnerable to things such as XSS etc, but it's convenient and works well.
I'm a little uneasy with storing the results of a server call locally though, for obvious reasons.
Currently, the data which is pulled and therefore stored locally is:

Firebase user ID
Account id
Balance
Type of account
Last four digits of account number
Account provider
Consent expiration time
Transactions
Database ID

And a bunch of other status codes.
The actual data itself isn't personally identifiable, or usable for anything malicious to my knowledge. No passwords are stored locally, the access token is only ever exchanged via my server, and it is encrypted so not publicly visible as plain text should my database ever get hacked.
So I guess my question is, how secure is this? Is it actually a security problem considering the data can't be explicitly used for malicious purposes? The only time it would be a problem (in my opinion) would be if my server / database was accessed with the encryption key.
Other alternatives are..

Encrypt the data that is stored in session storage, but is this pointless?
Not use session storage at all

Or can anybody suggest any other alternatives?
I know people on here will be much more experienced than me with this - so open to any suggestions. Please let me know, it'd be appreciated.

Summary
You're storing potentially sensitive user data in the browser, client-side, and from time to time referencing the data. I would store the information using an authenticated symmetric cipher, which (depending on how your key management works) gives a strong guarantee of confidentiality as well as integrity. You use data by:

sending the ciphertext to a separate (maybe 3rd-party) web service
or, sending the ciphertext back to the application server as part of the http protocol exchange
or, decrypting the ciphertext and reviewing the data in the client browser to make some sort of decision

In the first two scenarios, you never have the requirement to decrypt on the client-side - you're fundamentally relying on the client to store session data reliably. I'll assume you're not in the first scenario, as you would be making a service call to obtain the Plaid data (basically what you're trying to avoid!). I'll also assume the key-management strategy code can't be interfered with (... which is a loaded assumption if you plan to do decryption on the client side... more on this later).
Discussion
I would propose that you create input key-material for each client also, for example, vested in the cookie. (A cookie could be a good choice because the user may have stricter rules around cookie destruction.) Another choice would be to store the session key material on the http server or in the data store. I wouldn't store it with the encrypted session data. The client provides the encrypted session data from local-storage, as well as any input_key_material it holds, and the server would then derive key material as needed.
You would be using an authenticated symmetric cipher: Authenticated Encryption with Associated Data. Preferably something like X/ChaCha20Poly1305 or AES-GCM will be up to the task, however, you may need to consult any governance or legislative constraint (eg. some standards restrict your choice to AES-GCM and SHA2).
Generally speaking, this cipher follows the definition: AE( key , nonce , plain_text , assoc_data ), where plain_text is the data you want encrypted, and assoc_data is additional clear-text data that won't be encrypted, but must be authenticated.
It is of critical importance that if plain_text or assoc_data changes then so too must the nonce and/ or the key. If the code results in key + nonce re-use for two different plain_text values, the XOR of the two ciphertexts will be the same as the XOR of the two plaintexts. This may lead to data leakage, particularly if the format is known.
A common way to guard against nonce re-use is to use a counter if the nonce is smaller than 16-bytes, or use a random value if it is 16-bytes or greater (TODO ref). This will depend on what cipher you use for AE. In the case of the former, one solution I've used in the past is to produce a client-session-specific prefix of 8-bytes and then grab 4-bytes from the epoch time. The client holds input_key_material including the 4-byte timer value, while the prefix (as well as the key) are computed on the server as needed, and disposed of immediately after use. The choice of the timer is a relatively safe one, because any adversary will capture packet timing anyway. (Once you've considered all this, you might ask separately about a potential solution.)
Decrypting client-side
The fundamental problem here is delivering code and key to the client securely. If you search on this site, there's plenty of discussion weighing up pros and cons. There is a recent WebCrypto API that will limit you to AES-GCM and SHA2. You'll need a 'good way' to get key material to the browser.
Personally (at time of writing), I don't have strong opinions either way. You use the tools available and accept the risk. I would use the built-in browser API over a 3rd-party Javascript implementation (eg. sodium.js), because I work on the assumption that an implementation within the browser, that can't be surreptitiously replaced by other javascript code, would be less-malleable.


proxy servers and restricted work computers I have a work-issued computer that I have limited access to the Internet due to the security protocols in place on the device. I want to use this machine at home, for work. I want to be able to hide my IP address as I move frequently for my spouse's work as he moves around the world. I understand there are proxy servers and VPNs, but my work computer has been secured and we do not have access to the internet to freely sign into these services or install software on them.

Is there a way to hide every IP address in a home? Is there a way to get every device in the house to be proxied with one sign in from one device, or is that dreaming?

I would really love to have the flexibility to work from home so I may keep my job. Any suggestions would be greatly appreciated.

(My employer allows us to work from home in the U.S. and Canada - but my spouse moves to other places and we do not want to try and maintain two households as this is extremely costly)

So if I understand correctly you can work from home, and that IP address is OK. You need to setup a VPN or SSH tunnel at home, through which you can connect to your work network. You probably need to buy a router or cheap server (older laptop) that can do this.

Can you set VPN on your work laptop? If so, you can connect to your home VPN and work from there. If you cannot setup VPN, you can setup a router that handles this, to which your work laptop connects. You should buy a separate router for this, connect only your laptop to it, so no other devices connect to your home VPN - which will resulting in a slow connection.

For work, do you use VPN? Then your laptop should setup the VPN connection to work, automatically using home VPN and possibly abroad VPN.

That means you have to handle two or even three VPN connections. I have no idea how that works, if that works, if the connection is stable and fast enough. Your home VPN should be very stable, ADSL or cable very fast, upload and download.

You may have to get professional support for this.


Windows 10 User Profile name - is it ever visible outside network or on internet? Taking this to the extreme just to make it clear. What if I named a Local Windows 10 user name the user's social security number, or full name? Not concerned about local threats, just regular network usage, internet browsing, sharing folders locally on the local network. Is there any situation where the local Windows user name is exposed on the Internet or network?

I have searched and searched and cannot find an answer to this question. I have noticed that a Music Share on the local network does show the full user name on the other computers. Does this also reveal on the internet under any circumstances?

Again, no hacking, just normal usage.

Any decent programming language can get your windows username. Examples:

ASP

ASP can also use Membership.GetUser().UserName

PHP ca use  AUTH_USER request variable and get that even if you don't login to a website.

So the answer is yes, internet browsing can reveal your Windows username at any time.


What is the current best practice to secure an executive's laptop? What is the current best practice to secure an executive's laptop?

The exec will be processing highly sensitive documents (high-value bids, merger & acquisition info, technical specs). As such they are a potential victim for a targeted attack or APT. They will primarily use web, email, and office. And they need to be able to work offline.

I am aware the minimum best practice is:

Use a firewall
Use anti-virus software
Update all software
Encrypt the laptop

However, these precautions do not guarantee that the laptop will resist an APT. I have seen various ideas for creating a more secure environment (e.g. Qubes). However, these appear to be fairly experimental and aimed at a techie rather than an exec. So what practical steps can I take today to secure a highly sensitive laptop?

The biggest thing you can do is user training.  The majority of targeted compromises are a result of stupid users.  It doesn't matter how secure you can make the system when your PHB (pointy haired bastard) follows the link spoofed from their buddies e-mail address to some custom malware infested porn site and clicks ok to every dialog they see.

If you can't get awareness of security and what are appropriate uses of the computer and get the executive's buy in on that, then no amount of additional effort on your part will make a bit of difference.  If you can get their buy in and investment in keeping the system secure, then most of what you described is fine.

Another alternative is to give it an always on internet connection and use it like a dumb terminal for a virtual machine hosted within the company's network.  That's a bit more pricey and a bit more of a nuisance, but it is even more secure as you don't have to worry about whether the laptop may be able to be hacked if lost because there won't be anything on the laptop itself worth stealing.


Possible issues when one or more cookie not HttpOnly I have a question related to HttpOnly cookie. Tracking other threads wasn't of much help, hence I am posting my query here to learn if you can foresee any issues with my understanding.

There is a website, let’s say www.example.com which sets cookie at 2 stages.

Connection between Load Balancer and Client -- LB_Cookie -- encrypted
Connection between Client and Web Server -- ASP.NET_Session_Cookie -- encrypted & HttpOnly

In the above example, the ASP.NET_Session_Cookie is HttpOnly (secure from XSS attacks) - this is the cookie containing user’s session information. However, for LB_Cookie the HttpOnly flag is not set. I wonder if this could be an issue. Based on the information I obtained through resources on the internet - “all” cookies should be set to HttpOnly. However, they fail to explain what could go wrong if one of the cookies (Load Balancer cookie in my case) is not HttpOnly.

The purpose of LB_Cookie is such that the load balancer can remember, which web server it needs to send the incoming client requests to. There is no user specific data stored on this cookie. Is there anything wrong if it is not HttpOnly? I understand that it may be possible to steal LB_Cookie but even if this cookie is stolen, nothing much could go wrong because the attacker will not be able to take over user’s session. This is my understanding, and I am not able to imagine a scenario which could lead to trouble when LB_Cookie is not HttpOnly. Hence, I post these thoughts here for your opinion.

The HttpOnly flag only serves to protect sensitive cookies from scripts. Assuming the load balancing cookie is only concerned with routing through to a specific server and cannot identify a client, there's no harm in  this cookie being exposed. A XSS attack will only identify which server the browser is connecting to, and not anything specific to the client that an attacker couldn't figure out anyways.


How to encrypt data in email body sent by (offline) app and decrypt on server I've build an (offline)app (HTML/JS). The app allows the user to write a report (event when he is offline). The data from the report is sent via the body of an email to the companies special email address. In the company I collect the emails via an access database that holds the emails inbox. Then the data is read by a python analysis app. The data (collected via a form in the app) is in a human readable format (JSON).

The email might be intercepted when an insecure connection is used (e.g. in an hotel). When this happens I don't want that the interceptor can read the data, therefore I want to have it encrypted.

This form-data-web setup is temporarily, for a test. I am unable to sent the form data back to the server via ssl. I realise this is not water tight and very secure.
I can make a ssl connection when the users download the form.

My questions:

How can I encrypt the data that is sent in the body of a mail ?
How can I decrypt the data when I read the emails in my automated python email reader?

Short Answer:

Use GNUPG to encrypt and decrypt messages.

Long Answer:

Basically, you want to encrypt the data to avoid get stolen if some security flow, as I understood, come along. Nowadays, the best encryption for such purposes is to use PGP encryption (GNUGP as free implementation). It can be used in Python.
(find python lib here, here) If you work on Ubuntu base system then you probably have it preinstalled, else check the GNU website for more info

The philosophy behind this encryptions is that it uses RSA encryption.

You will create two accounts. One for your machine and one for the server.
The message can be encrypt with the public key of your company's account and decrypt with the same private key.

So you'll create a messsage, encrypt it with the public key of your server account, send it and decrypt it with the private key of the server account.

With that way if you get in a situation, like man-in-the-middle attack, the attacker can not decrypt your data. But just to point out, if you want a better security check, you have the possibility to verify the messages every time that get to the server just in case someone change your message.

To  sum up, I won't tell you more, cause cryptoography is a hole class in universities and IT and would get us pages and time to understand it. I advise you to give a try in google, searching about PGP encryption and ask someone who knows about cryptography.


Security of Linux/Unix user information Linux (and Unix) users can store in /etc/passwd not only the usual parameters (username, home directory, default shell, ...) but also: their names and surnames, addresses, phone numbers, etc.. In some Linux distributions, finger user1 can provide all this information to user1, and also to the other users in the same system and this is as expected.

As regards attackers, instead: who can read the /etc/passwd file can read this information; also, who can gain a user1 shell can run finger for any user.

1) Are there other undesirable ways to read those items?

2) What is the recommended way to (hopefully) confidentially and securely store this information?

1) The file itself is commonly read access to all in one form or another across distros. So I would always assume information in that file is public.

2) The better option is to store data in LDAP etc. If you do not want this information to be accessed for all to read.


Does KRACK break TLS? Apologies if this is already answered in the whitepaper, I'm not going to get chance to read it for a few days due to a hectic schedule, but I am already fielding questions from non-techies reading non-technical media news stories making them believe that we should unplug everything and go back to trading gold.

What I understand (and please correct me if I'm wrong) is that this essentially allows attackers to set up a MITM attack by forcing a new handshake between devices (yes, that's dumbed down), and that this is a flaw in the basic implementation of the encryption protocol, so it will require a firmware update to fix (yay for helping elderly family and neighbours update the firmware on their routers).

I don't see how this would also invalidate the encryption used as part of TLS, but I'm far from an expert on this.

KRACK is on the Network layer of the OSI model, while TLS is on the Session layer. So no, they do not influence each other, provided that the client can not be tricked into using a non-TLS connection (SSLstrip).

The basic threat from KRACK is that it allows an attacker to decrypt all packages on the network layer that the victim sends / receives. This includes all cleartext communication (e.g. that which many email programs still employ, local network device connections, etc.).

This means that if you display the network key and an attack is seeing all your traffic they can simply make a full connection to your network and wreak havoc on it any way they see fit.

If there are other vulnerabilities in the implementation (e.g., what happens in Android 6), then the attacker can even manipulate packages in transit to the victim. (both encrypted and cleartext can be manipulated). However the attacker can not read its contents if the packets themselves are encrypted by a session layer protocol (e.g. TLS). This opens up the possibility to change key values or redirect the victim to an attackers site for infection.

So while it is a serious breach and must be solved as soon as possible, it should not compromise properly secured traffic. So use a VPN, HSTS, HPKP and ssh, to protect yourself and/or your users.


Certificate authorities for a PKI Some people think the certificate authorities for a PKI should be the government, but others think certificate authorities should be private entities, such as banks, corporations, or schools. What are the advantages and disadvantages of each approach?

As discussed on the original version on stackoverflow:

It all comes down to who you trust. Some organisations will trust government, while some definitely won't. Some will trust a bank in this role, but would a competitor trust them? I have seen many banks set up their own PKIs or use a PKI vendor - and the physical security requirements around root CA generation and storage are very James Bond!

For your specific situation, look at your needs, trust requirements and risk. What PKI provider is most likely to match your needs? How is their disaster recovery and business coninuity plan structured - does this match your requirements? How do they prevent compromise of the root CA?


Security Risk of Stolen Session ID vs Authentication Token I was intrigued by the discussion of this SO question as well as the accompanying blog post.  I'm trying to better understand the mechanics of the two systems, and one of the questions I came up with is how much worse is it to have a token stolen vs. a session ID?

Here's what I understand so far, and please do correct me if I'm wrong:

A session ID is an opaque reference to actual session data stored on the server.  It is safe insofar as it is random enough to not be guessed easily, and the data is safe because it is not directly accessible by or beholden to the front-end.  The session ID is stored in a cookie to simplify authenticated requests.

An authentication token is a plaintext segment of JSON user data with a cryptographic signature that verifies the data's integrity.  It is tamper-proof because of the signature, so no one can simply come up with their own token.  The data it grants access to is safe on the server, except of course what is present in the token (which even then can be encrypted if need be).  The token is also often stored in a cookie to simplify authenticated requests.

So here is what I do not understand.  The way I see it currently, it seems just as likely that a token be stolen as a session ID, e.g. anyone breaking past my SSL and viewing my token would be able to view a session ID as well.  Either event gives the attacker complete access to my account and all associated authorization.  So in terms of the event likelihood and the resulting damage, is an authentication token really any worse than a session ID, as the article claims?

The one thing I could see potentially being worse for tokens is if the signing secret were somehow found out, in which case the attacker can do anything with anyone's account, rather than just mine.  However I almost want to relegate this to the reasonable unlikelihood of someone first breaking RSA, in which case they can get past SSL, and then what good is a session ID anyway?

I'm the author of the blog post you referenced, as well as the answer to the SO question you linked. Here are the answers you are looking for.

  A session ID is an opaque reference to actual session data stored on
  the server. It is safe insofar as it is random enough to not be
  guessed easily, and the data is safe because it is not directly
  accessible by or beholden to the front-end. The session ID is stored
  in a cookie to simplify authenticated requests.

Kinda. When a session ID is stored in an httpOnly cookie, the cookie itself is cryptographically signed (and can also be encrypted). JavaScript code can never access an httpOnly cookie (the httpOnly flag makes it impossible for JS code to view the cookie).

  An authentication token is a plaintext segment of JSON user data with
  a cryptographic signature that verifies the data's integrity. It is
  tamper-proof because of the signature, so no one can simply come up
  with their own token. The data it grants access to is safe on the
  server, except of course what is present in the token (which even then
  can be encrypted if need be). The token is also often stored in a
  cookie to simplify authenticated requests.

Kinda correct, again. Most tokens are stored in HTML5 LocalStorage (in JavaScript) because they are simply too large to fit inside of an httpOnly cookie. Cookies have a maximum data storage size of 4kb. If your token is larger than 4kb (which most are, since people use them to carry user information), then you must store them elsewhere. And the simplest way to store them outside of cookies is... you guessed it, LocalStorage!

Unfortunately, this has serious side effects.

  So here is what I do not understand. The way I see it currently, it
  seems just as likely that a token be stolen as a session ID, e.g.
  anyone breaking past my SSL and viewing my token would be able to view
  a session ID as well. Either event gives the attacker complete access
  to my account and all associated authorization. So in terms of the
  event likelihood and the resulting damage, is an authentication token
  really any worse than a session ID, as the article claims?

The likelihood of someone stealing a token from LocalStorage is far higher than that of a secure httpOnly cookie being stolen. And it's also substantially easier for a stolen token to cause mayhem because:

A stolen token can be used by an attacker to impersonate the user from anywhere (the attacker's network, proxies, etc.)
If an attacker is able to inject JS code onto your website, this won't allow them to access cookies, however, so that means the attacker would only be able to run JS code to 'impersonate' a user while the user is still on the website. Because once the user closes the tab in their browser, the JS code the attacker was running will no longer run.

There are vastly different abuse scenarios here.

  The one thing I could see potentially being worse for tokens is if the
  signing secret were somehow found out, in which case the attacker can
  do anything with anyone's account, rather than just mine. However I
  almost want to relegate this to the reasonable unlikelihood of someone
  first breaking RSA, in which case they can get past SSL, and then what
  good is a session ID anyway?

You're right that if an attacker can figure out the signing key, then they can tamper with an existing token (or create their own fake ones). But, this is highly unlikely because signing keys must be kept server-side. If you accidentally leak your signing key, for example, that's essentially the same thing as sharing your sever password with someone: obviously you're going to have a bad time.

The main difference here is in how the abuse can unfold. The article I linked to above is another post I wrote which details this in much more explicit ways. Hope this helps!


Is visiting HTTPS websites on a public hotspot secure? It's often said that HTTPS SSL/TLS connections are encrypted and said to be secure because the communication between the server and me is encrypted (also provides server authentication) so if someone sniffs my packets, they will need zillions of years to decrypt if using brute force in theory.

Let's assume I'm on a public wifi and there is a malicious user on the same wifi who sniffs every packet. Now let's assume I'm trying to access my gmail account using this wifi. My browser does a SSL/TLS handshake with the server and gets the keys to use for encryption and decryption.

If that malicious user sniffed all my incoming and outgoing packets. Can he calculate the same keys and read my encrypted traffic too or even send encrypted messages to the server in my name?

HTTPS is secure over public hotspots. Only a public key and encrypted messages are transmitted (and these too are signed by root certificates) during the setup of TLS, the security layer used by HTTPS. The client uses the public key to encrypt a master secret, which the server then decrypts with its private key. All data is encrypted with a function that uses the master secret and pseudo-random numbers generated by each side.

Thus,

the data is secure because it is signed by the master secret and pseudo-random numbers
the master secret and pseudo-random numbers are secure because it uses public-private key encryption when the TLS handshake occurs
the public-private key encryption is secure because:

the private keys are kept secret
public-private key encryption is designed to be useless without the private key
the public keys are known to be legitimate because they are signed by root certificates, which either
came with your computer
or were specifically authorized by you (pay attention to browser warnings!)

Thus, your HTTPS connections and data are safe as long as:

you trust the certificates that come with your computer,
you take care to only authorize certificates that you trust.


Is it safe to access HTTP sites from Tor? Somewhere I read that you should only open HTTPS links on Tor because otherwise your ISP for example could read the webpages you visit.

I searched on the subject and somewhere else I read that the Tor network itself provides enough built-in encryption.

So which of those is true - is it safe to open normal http sites on Tor?

Also what about .onion ending links?

No, it is not safe. But the reasoning your read is wrong.

When you use Tor, the connection between you and the Tor network is encrypted, so your ISP can not eavesdrop. But when you access a normal HTTP website with Tor, the connection between the exit node and the target website is unencrypted. That means the exit node can eavesdrop and manipulate the whole connection. You don't know if the exit node (and its ISP) is trustworthy, so this can be very dangerous.

This does not apply to hidden services (.onion websites). In that case the encryption is end-to-end and another HTTPS layer is redundant (and counter-productive because one purpose of HTTPS is to de-anonymize the server).


Is it safe to run XCode project in iOS simulator? I am reviewing an iOS test project by a job candidate. While I don't doubt their best intentions, I'd still like to know what kinds of risks I face when I:

Open the project in XCode.
Build the project in XCode (this comes to mind).
Run the project in the iOS simulator.

Running code from an unknown source (even in a Simulator) is risky.
If you suspect foul play first do a code audit.

Before you do a code audit with XCode however, first make sure the code base does not have any 'XCode modules' in them that might be automatically triggered. The easiest way to do this is to do a rough audit with a plain editor and if all seems ok, open it in XCode.

Use your common sense. Check first, with the least amount of 'helper tools' than slowly after you gain some confidence in the codebase add helper tools to help you in your task.


How do I hide files inside an image without using any steganography tools? I want to hide files inside a picture. The files may be music or video. Is it technically possible to do this? If so, how?

I searched on Google to find methods.  Please suggest some methods for beginners. I don't know where to start, so please guide me.

Important note: Modifying the size of an image up to a certain extent e.g.,
before hiding image size: 1MB and after hiding image size can be up to 4MB.

I referred to the following URLs:

  martinolivier.com/open/stegoverview.pdf

  www.garykessler.net/library/steganography.html

  www.jjtc.com/ihws98/jjgmu.html

  pcplus.techradar.com/.../secrets-of-steganography/ - United Kingdom

These are some examples, sir.

It is possible to hide files in other files. For pictures you can use the least significant bits of a RGB pixel definition.

A pixel has 3 bytes defining its color. Light Sea Green is defined by: 32,178,170 (R,G,B)

This translates to binary: 00100000,10101100,10101010

When we change the last bit of these, the color in an image does not change significantly. Therefor we can use the Least Significant bit of every color value of the pixel. This gives us 3 bits per pixel we can use.

So take a text, convert it to its binary representation and then write an algorithm that changes the LSB of every R,G and B value in the picture to the bit of that text. If you have a text of 128 bits long, you will need 128/3 pixels to hide that text.

Lets say I have a text who's binary representation is:

01001000 01100101 01101100 01101100 01101111 00100000 01010111 01101111 01110010 01101100 01100100 00100001 00100000

This text is 13 bytes long, meaning there are 13*8=104 bits. We know we can hide up to 3 bits in a pixel, so 104/3=  34.666, so we need 35 pixels.

So if we have a picture we'll use the first 35 pixels. To show you how it works, I'll give an example with two pixels. We can hide 6 bits in there, the first six bits of our text is 010010

Our pixels are:

pixel1,R: 00010101
pixel1,G: 01011111
pixel1,B: 10111100

pixel 2,R: 10010001
pixel 2,G: 00010101
pixel 2,B: 11011100

Now we can just change the last bit for every color value to the representative bit of the text:

pixel1,R: 00010101 ---> 00010100 (changes to 0)
pixel1,G: 01011111 ---> 01011111 (remains the same)
pixel1,B: 10111100 ---> 10111100 (remains the same)

pixel 2,R: 10010001 ---> 10010000 (changes to 0)
pixel 2,G: 00010101 ---> 00010101 (remains the same)
pixel 2,B: 11011100 ---> 11011100 (remains the same)

If we want to extract the text from the image, we just look at the LSB of the new pixels, we get:

P1 R: 0
P1 G: 1
p1 B: 0

P2 R: 0
P2 G: 1
P2 B: 0

This is our row: 010010


Should hard drives be encrypted prior to an operating system installation? When employing full disk encryption, should hard drives be encrypted prior or post the installation of an operating system?

If the former, is this supported by operating systems such as Microsoft Windows and Linux?

Does this or can this improve the security of the device? If yes, how?

Is there a particular method of encryption that should be considered?

In principle, it can be done both ways, just one is more complicated.
Namely, directly:

Wiping if there was sensitive data before (eg. with dd on a spinning HDD, or the builtin Erase feature of SSDs)
Installing the OS and choosing to encrypt the partitions there
Done

or

Installing the OS
Making a full backup to another medium
Using a LiveCD etc. to wipe the first hard disk
Create encrypted partitions there
copy the files back to the new encrypted partitions
Fix bootloader etc.
Wipe the second hard disk (the one that was used temporarly for storing the backup)

And it depends on the specific software that is used.

LUKS on Linux can be used during the installation already (depending on the distribution at least)
(not sure about Bitlocker on Windows right now)
Veracrypt (I don't recommend it for such things): neither Windows nor Linux support it out of the box, and of course it's not supported in their installer either. Still, encrypting the OS partition manually later appears to be possible now (at least for cases that are not too complicated), with some third-party tools.
...

For "method of encryption", the default settings of LUKS etc. are fine (nowadays it's AES-XTS and so on).

And for the benefits on hard disk encryption, there are probably more complete answers out there, but in short: If the laptop is stolen and turned off, nobody can see your secret files. It does not help if the laptop is turned on. And if it was stolen and you get it back, you can't trust it even if it was encrypted.


Generate new key - ECC vs RSA I intend to start using GnuPG again. I haven't used it for the last 2 years and was surprised that there is now the option for RSA and ECC keys.

After reading a bit about ECC, it seems to me there is quite a bit uncertainty about where it is going and what curves should be used. There were for example some discussions about whether or not the NIST curves are compromised or not. GnuPG 2.1.11 and libgcrypt 1.6.5 could only choose between NIST- and Brainpool-Curves (Which ECC to choose with GPG?) and this was only 8 month ago. Now we can choose the 25519-Curve too (GnuPG 2.1.18).

My questions are is it safe start using ECC or should one stick with RSA for at least a few more years? I guess I would use the 25519-Curve. But is this curve compatible to older GnuPG versions and other systems or are there some problems? Will this be something we can use for the next few years or should I expect some constant changing in terms of some curves being standardized and staying for a long time (like RSA) and supported by all systems, but some curves might disappear because they're not trustworthy? I also came across a paper where the NSA recommends keep using RSA and wait for Post-Quantum-Cryptography instead of using ECC.

I'm just an average GnuPG-user but it seems to me there is some sort of uncertainty about the way cryptography will develop within the next few years.

It's fine to stick with RSA. ECC is more space-efficient, but it is not supported everywhere.

  My questions are is it safe start using ECC or should one stick with RSA for at least a few more years?

When using curve25519, ECC is considered more secure. It is fast and immune to a variety of side-channel attacks by design. RSA is no less secure though in practical terms, and is also considered unbreakable by modern technology. It is sufficiently fast for use by GnuPG.

  But is this Curve compatible to older GnuPG-Version and other systems or are there some problems?

It is incompatible with older systems. It is necessary for all parties to support the same algorithm. You can, however, have multiple subkeys. You can have a single newer subkey with ECC, and an older one with regular RSA which could later be revoked once ECC support is ubiquitous.

  Also will this be something we can use for the next few years or should I expect some constant changing in terms of some curves will be standardized and stay for a long time (like RSA) and supported by all systems and some curves might be disappear because they're not trustworthy?

ECC is old. Not as old as RSA, but it is still old and well-studied. It is unlikely that curve25519 will disappear due to trustworthyness as it uses nothing-up-my-sleeve numbers. It is a safe curve. Curve25519 uses modulo p = 2255 - 19 and y2 = x3 + 486662x2 + x. Compare this with a standard NIST curve like P-256 where these values are... unexplained at best, leading people to speculate that they were designed intentionally to weaken them to classes of attacks known only to the NSA (NOBUS). The only reason it would fall out of favor is if a major attack on this class of curves is found.

  I also came across a paper where the NSA recommends keep using RSA and wait for Post-Quantum-Cryptography instead of using ECC.

This is in part because ECC requires a smaller key size. For classical security, this is absolutely fine, and a 256-bit ECC key can be stronger than a 2048-bit classical key. Both of these types of keys can be broken by functioning cryptoanalytic quantum computers. For a quantum computer to function, it needs a number of qubits (the quantum equivalent of transistors). It is very difficult to get a large amount of qubits to work together due to a phenomenon known as quantum decoherence, so the number of may be limited for some time. It is possible that a cryptoanalytic quantum computer will have enough qubits to break a 256-bit ECC key, but not a 2048-bit RSA key. It may be better to wait for post-quantum cryptography like SIDH, NTRU, or NewHope which resist all these attacks.

  I'm just an average GnuPG-user but it seems to me there is some sort of uncertainty about the way cryptography develops within the next few years.

It is perfectly acceptable to keep using RSA. Once ECC is better supported, you can migrate to it in the form of a new subkey. ECC keys and signatures are much smaller, so if this is a priority for you, you may want to start using ECC. RSA keys and signatures are large and can be quite unwieldy.


How ARP forging prevents the victim from accessing the router? In ARP spoofing, the victim broadcasts to MAC ff:ff:ff:ff:ff:ff asking for MAC address of router IP. The attacker can respond with his own MAC, but the router responds with its MAC!

If I try "man in the middle", my MAC (attacker) is always accepted, which means the router MAC was rejected. Why?

My guess is that the attacker response is faster. If true or false, how or why?

Not about faster, the attacker machine floods ARP responses even if no one requested one. When machines receive these packets, they update their ARP tables. The attacker wins simply because it is constantly telling everyone it is the router every second.

The phrase you are looking for is "gratuitous ARP".


Some tags I'm worried about when parsing html doc for xxs I'm building a web app where users can make post which consist of an html doc. An user can change the document via the dev tool for example. So the document consists of literally any user input. I'm worried about XSS since I'm not experienced in this area. To prevent XSS injections, I'm using jsoup to parse the content. I made a custom white list but I'm not sure (well I doubt) I thought about everything.

I save the content like this :

public void setContent(String content){
    content = Jsoup.clean(content, WhiteList4jsoup.getWhiteList());
    this.content = content;
}

My jsoup whitelist is like this :

public static Whitelist getWhiteList() {
        Whitelist whiteList = Whitelist.basic();

        whiteList.addAttributes("h1", "style");
        whiteList.addAttributes("h2", "style");
        whiteList.addAttributes("h3", "style");
        whiteList.addAttributes("h4", "style");
        whiteList.addAttributes("h5", "style");
        whiteList.addAttributes("h6", "style");
        whiteList.addAttributes("h7", "style");

        whiteList.addAttributes("a", "href");
        whiteList.addAttributes("img", "src", "style");
        whiteList.addAttributes("div", "style", "aria-label");

        whiteList.addAttributes("table", "style", "rules", "border");
        whiteList.addAttributes("thead", "style");
        whiteList.addAttributes("th", "style");
        whiteList.addAttributes("tr", "style");
        whiteList.addAttributes("td", "style");

        // Those are customs tags that I insert in the document when user
        // clicks on a button. I Let them in so when I display the message content I can grab them tags with javascript and do some business with it.
        whiteList.addAttributes("customContainer", "type", "title", "measured");
        whiteList.addAttributes("columnCustom", "title", "value");
        return whiteList;
    }

Is any of this potentially dangerous ?

It's actually a wysiwyg editor in a iframe that I build myself so I've control over it. Since user can create charts, tables and such the result is quite messy with a mark up of my own. That's why I wanted a wysiwyg. However if it's too dangerous I'll go the same route as stackoverflow and do a preview at the bottom. I already finished my editor but I think the preview wouldn't take much effort.

If that is the case I don't intend to use any already available markup such as bbcode because my content is too much custom (images, links, charts from google api, tables). Is there anything I should watch out for if I'm building one ?

What you are trying to do is inherently pretty dangerous. I would strongly recommend using something like BBCode or Markdown, as these are specifically designed to allow fairly rich content without script injection risks (although bugs in them are sometimes found).

With that said, there's only two really obvious scripting risks I see in what you've posted here.

Click here! will create something that looks like a "normal" hyperlink but will execute code within your site's origin (like an XSS) when clicked. You may notice that this doesn't work on StackExchange (which uses Markdown).
You can embed scripting behavior in CSS. Very old versions of IE allowed the expression value in styles, which is just flat-out embedded script, but there's also a thing called "CSS Behavior` that allows attaching externally-specified scripts to elements. This is, in effect, the same as embedding script tags in the page.

Beyond that, though, allowing CSS in general is dangerous. Using CSS, a malicious user can completely overlay the page, changing or hiding certain content or even making the page look like something totally different from what it is.


How do I encrypt the source and destination IP address, along with various parts of an email? If the subject makes no sense to you, that's fine, it makes no sense to me.

I've been tasked with securing emails sent from some devices, and I'm looking for advice on intelligent questions to ask to clarify some requirements.  Apparently the source and destination ip addresses need to be encrypted, along with the username used to log in, and the email message itself.

In order to encrypt the source and destination IP addresses of a conversation, it looks like I'd need to use something like IPSec, correct?  And that would be done at the OS level, not just as part of an application when sending an email, correct?

For encrypting the username, I have no clue what that means.  Seems like if I encrypt the credentials when attempting to log in, I won't be able to log in unless the server can decrypt them somehow.

For encrypting the email itself, if I use something like PGP, I would need to set up keys on the device sending the email, and the receiver's machine, correct?

I've done some research on the requirements, and the above is what I've come up with.  Looking for some intelligent questions to ask, and validation of my assumptions above.

thanks,
Mark

To protect packet destinations, you need to abstract the network layer entirely - which usually means some form of encrypted VPN. This would mean no hardware on the local network would know what packets are being transmitted, where to or what they contain.

Unfortunately, this doesn't solve the real problem, just moves it upstream. Your VPN/encrypted link has to connect to the real network at some point and as soon as it does, you'll be forced to use correct routing information. You could mitigate this by moving IP blocks every so often / having multiple connections to the 'net but this could be complex to maintain.

An improved approach might be to use TOR to mask routing from your network. It's not perfect but it's another layer of defense.

So perhaps an SSL SMTP connection over your encrypted vpn to your mail server and encrypted email over TOR to the recipient(s) mail servers. (SSL on top of your VPN encryption to protect against other machines on the VPN. You may want to consider client certificates to guarantee the source of the email)

Edit: Having just spotted your use case in comments, and focusing purely on protecting the connection to the smtp server, I think it'll depend on how easy it is to uniquely configure the sensors.

If it's cheap, use a unique SSL client cert with each sensor. This will both secure the connection and confirm the ID of both parties - no spoofed sensors.

If it's costly to configure, use something PSK based - You still get the encryption but if one device is compromised, they all are [at least to anyone inside the VPN].


how Cookie tracking threat works? as explained here and lots of other cases , what is this tracking story ? browser vendors say we have same origin policy and for example google.com can only read cookies saved by google.com or read cookies that saved by google.com, if its true so how this tracking by google and advertising companies and other agencies works ?

Edit: please describe an example (java html etc) code to do a tracking

The contents of a Web page do not necessarily come from a single server. Web page from www.example.com contains a link  which your browser will dutifully follow. That secondary server stores a cookie in your browser stating "I have been through www.example.com".

Later, you visit www.sample.org which contains a link . Your browser also follows that link, and since it is for the same server than previously (ad.server.elsewhere.com), the browser sends the previously stored cookie. Boom ! You've been tracked.

Happens every day. Happens right now. Happy Web surfing !


Find matching phone numbers without actually knowing them We have a mobile app that, given two users, needs to let them see what common contacts they have based on their phone numbers. How can we do this in a cryptographically secure way and respecting the users' privacy (i.e. without sharing the numbers in plain-text between them or with a server)?

Our current solution is:

(On phone A) Generate a single random salt.
(On phone A) Take all phone numbers from phone A and generate a SHA512 hash with multiple rounds for each phone number using the salt generated from step 1. Something like sha512(sha512(sha512(phonenumber + salt) + phonenumber + salt) + phonenumber + salt).
(On phone A) Send these hashes along with the salt to phone B (via a server).
(On phone B) Repeat step 2 to generate hashes for its own phone numbers using the same salt generated on phone A.
(On phone B) Compare the two list of hashes - a matching hash means a matching phone number, and therefore a common contact.

Is this a flawed approach, prone to rainbow-tables/brute-force attacks, and if so is there any other solution that is more suitable? Maybe using bcrypt with a given salt is better than doing multiple rounds of sha512?

bcrypt would be a somewhat better approach because it is designed to be (programmably) slow.

Using a large enough salt and a reasonable complexityFactor, bcrypt(salt + number, complexityFactor) should yield a viable hash and you avoid "rolling your own cryptography", which could possibly turn out to be a difficult sell. To increase security you just crank up complexityFactor.

An attacker would now have to generate the bcrypt not only of every 10-digit phone number (which could be feasible: there are only 1010 numbers after all), but of every possible salted sequence. With a 10-character base64 salt (60 bits of entropy), the complexity increases of twenty orders of magnitude.

Brute forcing

Suppose you have 1,000 contacts . The CPU of your average phone seems to be two orders of magnitude slower than a server core array. I think it's reasonable to say that it will be three orders of magnitude slower than a semi-dedicated GPU implementation of bcrypt, which is said not to be so efficient.

So we tune bcrypt to take 100 milliseconds for each encoding. This means that we need 1 minute 40 seconds to generate our 1,000 hashes, which is a reasonable time for one thousand contacts (a progress bar seems in order). If the user only has 100 contacts, he'll be done in 10 seconds.

The attacker, given the salt of one number, has to generate perhaps 108 numbers to reasonably cover the mobile number space (the first number, and possibly the first two, aren't really 10 or 100 -- I count them as 1). It will take three orders of magnitude less than 108 times 100  milliseconds, i.e. than 107 seconds. This is down to 104 seconds, or around two hours and a half (or a whole day if the GPU optimization thingy turns out not to work).

In less than four months, the whole 1,000 contacts will have been decrypted - using one optimized server. Use ten such servers, and the attacker will be done in two weeks.

The problem, as pointed out by Ángel's answer and Neil Smithline's comments, is that the key space is small.

In practice user A will produce something (a hash block, or whatever) to be made available somehow to B. User B must have a method that works like

matches = (boolean|NumberArray) function(SomethingFromA, NumberFromB)

(little changes if the second parameter is a set of N numbers, since UserB can build a set using one true number and N-1 numbers known to be fake or not interesting. It can lengthen attack time by a factor of N).

This function works in a time T... actually this function must work in a time T short enough that user B, in a commercial real world application, is satisfied.

Therefore one bound we can't easily dodge is that M numbers must be checked in an acceptable time on an average smartphone. Another bound we can't reasonably dodge is that User B can supply fake numbers to the algorithm (i.e. people that aren't really contacts, and possibly do not even exist).

Both bounds also are enforced if the checker is on a third server; this only assures a lower execution time limit that can thwart some scenarios, such as "decrypt all UserA's numbers", but not others such as "verify who has this number", as in drewbenn's answer).

From these two bounds arise the fact that using a smartphone (or a third party server with minimum execution time enforcement), cycling through all 108 reasonable numbers takes about 108 smartphoneTime time, or on the order of one thousand months.

Attack strategies to decrease this time are distributing the attack between several verifiers, or running it on a non-throttled and faster server (this requires the algorithm being available, but assuming the contrary is security through obscurity), and they look both feasible and affordable.

A loophole?

One possibility could be to introduce a small probability of false positives. I.e., the above oracle function will occasionally (say once every ten thousand contacts), and deterministically on UserA's input, return true to one of UserB's numbers.

This means that the brute force attack on 108 numbers will yield UserA's contacts mingled with 104 other numbers. Determinism on UserA's input means that two successive checks on these 104 found items won't further whittle them. Unless UserB's can grab a different copy of UserA's input, which will yield a different set of false positives and allow filtering the true contacts as the intersection of the two sets, this may make the bruteforced answer less appealing. This comes at a cost - honest UserBs will have to get the occasional false hit.

We really can't win

If UserB must be able to answer the question "Is number X among UserA's contacts?" in a reasonable time with certainty, the time expenditure is linear, because the system cannot prevent two such requests from being made against numbers X1 and X2, and time for request X2 will be the same for request X1. Therefore, solving two numbers will require double that reasonable time; by induction, solving for N numbers will entail N times that reasonable time (not, say, N2).

The difference between a legitimate request and an attack is that the attack will work on a space ten to a hundred thousand times larger. Being linear, it will require a time up to one hundred thousand times longer... but it also may run on a machine or group of machines one hundred to one thousand times faster.

Therefore, our attacker will always be able to decrypt all of UserA's contacts in a "still not unreasonable" time. The only serious check to this would be for the checks to be run on a third, trusted machine with rate limiting and the means of detecting a likely attack.

To thwart an attacker we need something bad to increase with the increase of N, and since it can't be running time (which doesn't increase enough), I think the only resort left is the probability of false positives. The attacker will still get the answer, but we might still succeed in making a bruteforced answer less usable.

One simplistic implementation (poor man's Bloom filter)

To answer Mindwin's comment, the local algorithm can't work by hiding information - the information must be missing in the first place, otherwise we'd be still be doing security through obscurity.

One method would be for UserA (Alice) to send over the bcrypt salt for her (say) 1000 contacts, followed by 1000 incomplete bcrypt hashes. If the hashes are truncated at the i-th byte, there will be pseudo-random collisions. Among UserB (Bob)'s contacts, which are few, collisions will be very rare (unless i is really small). Among the attacker(Eve)'s whole number space, collisions will be significant.

Note that phone number distribution is not flat, so Eve can have ways of whittling those collisions by removing, say, unused numbering sequences.

If every contact hash has a probability of collision of one in a thousand, Bob, checking his one thousand contacts, has a probability of (1 - 1/1000)1000 of having no collisions at all - that's 70%, not so good. If collision probability is 1/10000, Bob with one thousand contacts will have 90% chances of not getting even one collision. On a hundred contacts only, no-coll probabilities for Bob are 90% and 99% respectively.

Eve, verifying 108 numbers, even with p = 1/10000, will always get ten thousand collisions no matter what.

Sending two or more hashes with higher collision probability does not change things much for either Bob or Eve, in comparison to sending a single hash with collision probability equal to the product of the separate hashes.

For example instead of 1 round with p = 1/10000, use two rounds with p = 1/100, since 1/100*1/100 = 1/10000.

So Alice sends two sets of unordered incomplete hashes, with different seeds, and higher collision probability of 1%; Bob will test his 1000 contacts and get positive matches for the 100 contacts he has in common; the remaining 900 shouldn't match, but since the hash is incomplete, 1% of them will, that means 9 spurious contacts, and Bob will end up with 109 likely candidates after running 1000 tests. He now has to test those 109 with the second hash, which also has 1% probability. The 100 true intersections will still match. Of the remaining 9, likely none will pass. The chance of a contact passing two such rounds is 1% of 1%, i.e. 1 in 10000, and the chance of having not even one false positive on 1000 nonmatching contacts is (1-1/10000)1000, or 90.48%, exactly as before.

With the same numbers, Eve will get one million false positives on her first round, and will have to run one million extra tests. 1% of those will match the second round, leaving Eve with ten thousand false positives mixed up with the one thousand contacts from Alice.

Eve has had to run 101 million tests instead of 100, and Bob had to run 1109 tests instead of 1000. In proportion, the double-hash scheme impacts Bob harder than Eve. It would be better to use a single hash with higher complexity.

The privacy problem of answering the question "Does Alice know number N?" will remain unaddressed - the time to answer that is the same for Bob and Eve.


XSS inside a javascript Can an XSS be craft inside the following JS.

$(function () {
            $("#panel").find(".form").each(function (index) {
                var that = this;

                $(that).overload();
            });
            $("#panel").find(".form").find("[name=link]").each(function (index) {
                var that = this;

                $(that).on("click", function (event) {
                    $(that).select();
                });
            });
            $("#panel").find(".form").find("[href=#show]").each(function (index) {
                var that = this;

                $(that).on("click", function (event) {
                    prompt("HardcodedText", $(that).text());
                });
            });
        });
    </script>

The page url is something like so https://www.mylabtest.com#show
I tried the following but neither worked

https://www.mylabtest.com#show]");+alert(1);//

https://www.mylabtest.com#show]");<script>alert(1);</script>

It would have helped if you would have provided with the HTML code as well. However, i think the reason why it does not work is because the value of the hash anchor is not being utilized in the JavaScript.

It would have been exploited as DOM based XSS if this value was being used in JavaScript somewhere. Here's is an example of code vulnerable to DOM based XSS:

URL: http://www.example.com/page.html?default=French

Select your language:
<select><script>
document.write("<OPTION value=1>"+document.location.href.substring(document.location.href.indexOf("default=")+8)+"</OPTION>");
document.write("<OPTION value=2>English</OPTION>");
</script></select>


Do password policies make passwords weaker? Password policies have certain requirements for creating a password on a service.

My question is, do password policies make passwords weaker, therefore counterproductive?

Let's give an example:

I'll be using letters to represent charsets:

 L = abcdefghijklmnopqrstuvwxyz

U = ABCDEFGHIJKLMNOPQRSTUVWXYZ

D = 0123456789

S = «space»!"#$%&'()*+,-./:;<=>?@[\]^_`{|}~

A = L and U and D and S combined

Ok, so a password policy says minimum is 8 characters.
Now, using this information, a bruteforcer limits attempts to length >= 8, vastly reducing attack space.

Another common policy is passwords must have at least one upper case letter, one number, and one symbol.

Assuming the password is 8 characters, instead of the password being 8 As,we now know the password is 5 As, 1 D, 1 U, and 1 S. Now instead of (A^8), it is (A^5xDxUxS) possible combinations.

If the policy asks for one lower case letter, we reduce the attack space even further.

If the password policies significantly reduce the attack space, what's the purpose of implementing a policy that extends beyond a minimum length requirement? Wouldn't it be safer to implement a simple policy like minimum length of 10 or something?

By adding required charsets like digits and symbols, we give hackers more information about the contents of the passwords.

I wrote about password policy impacts on password space a few years ago and it includes more of the math that you didn't find in the similar question Xander linked.  I can expand on that here if you have additional questions.  Essentially my answer there is that eliminating the risk of the weaker passwords is more beneficial than the risks of the attackers only having to crack conforming passwords.

Regarding your comment about a known minimum password length 'vastly reducing attack space', that's not really true.  The number of 8 character passwords (not to mention those greater than 8 characters) dwarfs all 1-7 character password possibilities combined.  While you do lose those possibilities you also eliminate the riskiest shorter passwords by setting a minimum length.  In practice, cracking anything shorter than 8 characters using a brute force attack against fast hashes takes almost no time at all.

Also, as far as the policy requirements leading people to choose predictable character patterns that is true, but not quite as risky as you expected.  When observing these patterns in real corporate password choices they do show up, but it isn't a straightforward choice by every single user.  Certainly more users do this than most of us would prefer, but it is challenging to eliminate these patterns without causing a lot of usability problems in the process.


How is the exchange of tls on email servers? Do all email servers (also different providers) that implement tls, use tls to encrypt the messages and headers?

Could the missing of tls-encryption be a sign of ssl-downgrading and how to find out if a server does implement tls?

Do all email servers (also different providers) that implement tls, use tls to encrypt the messages and headers?

Usage of TLS in transporting email does not encrypt the email itself the same as use of TLS in HTTP does not encrypt the request and the response specifically. Instead the underlying connection is encrypted, either from start (smtps, port 465) or after a STARTTLS command (smtp, port 25). By encrypting the underlying connections everything inside this connections gets protected, which include in case of SMTP the mail but also the SMTP commands for authorization, specification of sender and receiver etc.

  ... and how to find out if a server does implement tls?

You can connect to the server and speak the SMTP protocol, issue a EHLO request and check if the response contains the information that the server supports the STARTTLS command:

$ telnet aspmx.l.google.com 25
220 mx.google.com ESMTP b48si10559063wrb.307 - gsmtp
ehlo myhost
250-mx.google.com at your service
...
250-STARTTLS

But note that contrary to the use of TLS for HTTP (i.e. HTTPS) TLS in SMTP does not provide an end-to-end encryption from sender to recipient but only a hop-by-hop encryption between the mail transfer agents (MTA). Thus you only find out from this that a specific MTA supports TLS and not that all the hops on the way to a specific recipient do it. Also each hop has the mail in clear text, i.e. only the transport between the hops is protected with TLS.

  Could the missing of tls-encryption be a sign of ssl-downgrading ...

There are some firewalls which strip STARTTLS from the response and thus cause the client to not use TLS.


Is this accidental incident considered hacking(illegal)? I was doing research for a college research paper and I got bored and opened up CMD.  I don't really know more than the next guy about computers, so i figured id just play around.  I googled the commands for the command prompt and started trying some out. (I was connected to a college wifi network)  I typed net statistics and then server and it brought up a server window.  Then it said that receiving data is blocked by a remote location.  I think I just ran into a security wall and thus am ok.  I was just playing around, Again I don't really know a lot about computers so yeah. I was just wondering if i did something illegal by typing in net statistics and then server.  I'm kinda worried so a quick and simple response would be nice.  Thanks a lot.

Legal matters depend a lot of jurisdiction, so it is quite hard to come up with a single answer. However, in most jurisdictions:

Intent matters. It is hacking if you are willingly trying to bypass security measures or obtain access rights that you know you should not have.
A college with a WiFi access point to which you are connected should have a usage policy to which you more or less explicitly agreed to comply when you connected. These rules should be the first document you should have a look at, because they will tell you what the access point owner considers to be acceptable usage and what is not. This does not necessarily matches what is allowed by Law, but it may tell you what may trigger retaliatory action from the owner.

net statistics on Windows systems is a pretty basic tool which cannot reveal really confidential data, but, just like any other tool, it may help in pursuing nefarious goals. Knifes are not illegal, but can help in killing people; so if you have a knife and wave it around threateningly then security guards may find it fit to shoot you. Similarly, a simple net statistics attempt should not be enough to incriminate you; however, really paranoid sysadmins may take it as a hint that your are up to something nasty, and come down on you. You would probably not be ultimately declared guilty by a court of law (I make no promise here, but that's really improbable), but in the short term this might degrade the state of your relationship with the college sysadmin team, and thus hinder your research efforts. If in doubt, abstain.

In practice I doubt anybody actually noticed the effect of your command.


Symmetry meaning in cryptographic algorithms When we refer to symmetry in cryptographic algorithms such as symmetric or assymetric does the symmetry refers only to the equality or not of the keys, or does it also refer to the symmetry of encryption and decryption operations?

Also does symmetry when refering to keys means they are equal? Is there any symmetry between a private and public key? They might be different but they are linked in a way,in rsa for example.

It only refers to the symmetry of the keys.

There are a number of block ciphers and modes (symmetric crypto) that have slightly different encrypt and decrypt routines. Yet they are still symmetric crypto. AES for example uses a number of building blocks for which there are inverse operations used to decrypt.


How can I detect if someone is using an ssh tunnel as a proxy to connect to a VPN? I've got an SSH server setup in a remote location, which I use to tunnel traffic from an android tablet. On the tablet, I have the Cisco AnyConnect app to connect to my company's VPN. We want to be able to detect that a proxy is being used by the tablet. Any ideas as to how I could go about doing it?

A VPN is just routing with protection. In your case, the "proxy" ensures that traffic goes first from the tablet to some server S, from which it then goes to "the Internet", e.g. to the entry point for the company's VPN. The "proxy" uses SSH but that's just between the tablet and server S; you cannot see it from the company.

What you will see, though, from the company, is the IP address of S. A relatively invasive strategy is to use OS fingerprinting on that machine (basically, scanning who is connecting) to try to guess whether S is indeed an Android system, or some other kind of OS. If you detect that "who connects" does not use Android directly, then you have shown that some intermediate system, a "proxy", is in use.

(Whether scanning machines who connect is legal is a complex subject which depends a lot on jurisdictions. Don't deploy that without taking some legal counsel.)

Now, of course, in all generality, there is no such thing as a "proxy / no proxy" dichotomy. A basic tablet user will connect over WiFi when he can, connecting to an access point which will use NAT, and that qualifies as a kind of "proxy". This already prevents the reverse-scanning explained above from really working (i.e. most of the time, the scan will see the access point, not the tablet itself).

The whole point of using a VPN like Cisco AnyConnect is to make the proxy question irrelevant: the VPN uses cryptographic protection exactly so that the paths used by data packets have no impact whatsoever on security. You should not have to ask yourself whether some SSH or NAT or whatever is in place. Thus, your question is kind of weird.


Blacklisting of a block of IP addresses - Why? I have discovered that one of the IP addresses my company's domain names has been assigned to has blacklisted. It's a new domain and address for us. There's no website attached to it, but very often email using that address is getting filtered out.

Further investigation showed that the whole IP address block is blacklisted e.g. 123.456.789.x

Why would a whole block be blacklisted?

It's probably because of a couple of reasons:

The IP block was earlier assigned to someone who used it to spam or spread malware.
The IP Block belongs to a country that the site/company doesn't want connections from - generally done for countries that have a very high quantity of malicious traffic originating from them.


Is Facebook allowed to sell/give your information away to anyone willing to buy it? Is Facebook allowed to sell information about their users to other companies?
For example selling name, address and IP information on a specific geographic location could be very valuable information for competitive ISP's trying to win customers from each other.
According to Facebook's privacy help page it sais:

While you are allowing us to use the information we receive about you, you always own all of your information. Your trust is important to us, which is why we don't share information we receive about you with others unless we have:

received your permission;
given you notice, such as by telling you about it in this policy; or
removed your name or any other personally identifying information from it.

By registering at Facebook, have I already given my permission?

There is a classic phrase:

  "If you are not paying for it, you're not the customer; you're the
  product being sold"

In case of companies' liquidation, they openly sell their user databases on the internet as one of the liquidated assets.

Well, think this way. If Microsoft bought , say, Skype, had Skype sold its user database and what is the sense/value of Skype, or Facebook, without their user database?

Besides, online service companies, like Facebook, are functioning on the basis of license (terms of service, etc.) agreements with users not contracts.
That means that if one of the sides breaks it, this would constitute violation of copyright law not contract law.

Update:
Here is an excerpt from

Hundreds of websites share usernames sans permission.
Photobucket, Wall Street Journal, Home Depot take liberties with your personal info
http://www.theregister.co.uk/2011/10/11/websites_share_usernames/

"Home Depot, The Wall Street Journal, Photobucket, and
hundreds of other websites share visitor's names, usernames, or other
personal information with advertisers or other third parties, often
without disclosing the practice in privacy policies, academic
researchers said.

Sixty-one percent of websites tested by researchers from Stanford Law
School's Center for Internet and Society leaked the personal
information, sometimes to dozens of third-party partners. Home Depot,
for example, disclosed the first names and email addresses of visitors
who clicked on an ad to 13 companies. The Wall Street Journal divulged
to seven of its partners the email address of users who enter the
wrong password. And Photobucket handed over the usernames of those who
use the site to share images with their friends."

Your phone company is selling your personal data (CNN, Nov 1, 2011)

"Verizon (VZ, Fortune 500) is the first mobile provider to publicly confirm that it is actually selling information gleaned from its customers directly to businesses. But it's hardly alone in using data about its subscribers to make extra cash"
Facebook is blurting out your private information
no date but comments start on Oct, 2010, and the author regularly tweet this article (Nov, 2011)

"... the moment you land into one of their [Facebook's] “trusted partners” sites, your personal information has just been given away"

I could not resist from visualizing the comment by Hendrik Brummermann from this answer here pointing to this image found on the web:

as well as to answer that answer by quote of "Privacy Zuckering" definition:

"The act of creating deliberately confusing jargon and user-interfaces which trick your users into sharing more info about themselves than they really want to."
(As defined by the EFF).

The term "Zuckering" was suggested in an EFF article by Tim Jones on Facebook's "Evil Interfaces". It is, of course, named after Facebook CEO Mark Zuckerberg


What do these credit security alerts mean? A bank where I have an auto loan has a credit reporting feature. The feature shows that I have several "Dark Web Alerts" for "Compromised Email Address". The alerts list the breached sites, for example schmevite.com and schmafepress.com (and others). This doesn't make sense. How was my email address breached at a website for party invitations and blogging?

I haven't used either of those site in a long time. I assume my username is my email address. However, my email account not been breached (right?). The recommended action is to change my email password, but my email has not been breached, so why would I do that? Am I expected to change my email password every time some remote site that I've barely used is breached? Shouldn't it be telling me to change my schmevite and schmafepress passwords?

NOTE: I have a different, and reasonably complex password for each site. The point being if someone has breached my scmevite or schmafepress password, which uses my email as the userid, why do I need to change my email password?

But then I have another of the Dark Web Alerts which says "Compromised Email Address", but does not list a compromised website. Instead it says "Password: Exposed". Now I'm really concerned. If someone gets into my email account, they can find all of my other passwords (including to financial sites) by requesting password changes.

But that alert was exposed on 4/18/20 and I haven't lost my money yet. Should I be concerned about this? What do I do? (P.S. "Should I be concerned about this" is rhetorical -- I am!).

Thanks for helping me understand.

Your email account is likely not compromised, especially if you use unique passwords for all of your accounts and use a major email provider.

For the alerts that name sites, this is likely just reporting that your credentials were part of a data breach related to that site.  You should treat your password on the named site as public knowledge and change it, both there and anywhere else you've used the same or a similar password.  Just because a set of credentials was stolen from schmevite.com that does not mean that attackers won't try to use those same credentials elsewhere, since many people re-use the same or similar password for multiple accounts.  If you use unique passwords for every account then you have no need to worry about this attack vector, and only need to change your password on the breached site.

For the alerts that don't name a particular site it's likely that your username/email address and a password were found by researchers as part of some unattributed database of accounts.  It's not uncommon for password lists to be sold with no indication of where they came from.  Often they're collections, combined from multiple breaches such that it's very difficult to determine where exactly the leak came from.  If your username is found in one of these collections it's a good idea to change any passwords that are older than when the collection was discovered.  There are tools such as Have I Been Pwned's password checker that you can use to determine if a specific password has been found (at least, in any of the databases that particular tool knows about), but if you're using a password manager with unique, randomly-generated passwords it's likely faster and easier to just change them all.


Random numbers used in TLS I found in the RFC about TLS v1.2 that master_secret is computed this way:

master_secret = PRF(pre_master_secret, "master secret",
                          ClientHello.random + ServerHello.random)

while, subsequently, the needed key blocks composing the key material are generated through

  key_block = PRF(SecurityParameters.master_secret,
                  "key expansion",
                  SecurityParameters.server_random +
                  SecurityParameters.client_random);

And here it is my question: is there any difference between SecurityParameters.server_random and ServerHello.random or between the corresponding client's random numbers? And if yes, what is this difference?

My opinion: I think SecurityParameters.master_secret is the one computed with the first PRF shown above: so - supposing this "asymmetry" of notation - maybe, also the random numbers in the second PRF are the same used in the first? But, if so, why this different notation?

The master-to-working key derivation is defined as part of the Record Protocol in section 6, and therefore uses only the 'parameters' passed through a theoretical API from the Handshake Protocol in section 7.3 and 7.4 (and 8) which can directly process the handshake messages including both Hello's and the KeyExchange(s) and/or Certificate(s) contents. I suspect this thinking may have come at least in part from IPSec where the data-level 'bearer' processing is largely isolated from the setup/management processing. In practice no SSL/TLS implementation I have looked at enforces this separation; there are normally code blocks (methods etc) for the two protocol levels that are separately usable (and need to be) but share session/connection/crypto state.

Also, it's not clear at all from the notation, but the premaster-to-master happens only when a full handshake (key exchange) is done, while the master-to-working is repeated if and each time a session is resumed using an abbreviated handshake, using the new nonces from the new abbreviated handshake not the ones from the original full handshake; see F.1.4.


Reasons why different antivirus engines detect same malware differently I think I understand how does signature-based detection work (calculate hash -> compare it with the database of hashes), but I can't understand why some AV engines find the same virus as different.

As you can see VirusTotal show me that malware I used for researching is Trojan-Gen, WannaCry or Worm. Why different AV engines find the same malware as different.

Those results are what each vendor has chosen to call the malware internally. There is no standard form of naming a malware type.

Because of the different ways that vendors seek out and classify malware (and no, it is not always signatures), there will be differences in the ways that a vendor classifies the malware. If it can positively identify it as a certain malware (like Wannacry), then it can give it that label. If it is only classifying what it does, then it will give it a label based on its behaviour, like "ransomware", "trojan", etc.

I see one in that list where it looks like it just reported how it determined that it was likely malware without classifying it at all.


What are the disadvantages of Google Safe Browsing? I'm currently undertaking my thesis regarding phishing detection. I understand that Google Safe Browsing relies on a constantly updated blacklist in order to classify webpages. Their blacklist does not suffer from the drawback of being unable able to detect zero-hour phishing attacks. After all, the blacklist is generated by a machine learning algorithm, trained daily with tens of millions of data (assuming the "blacklist" they refer to in the paper is indeed the one used by Safe Browsing).

My question is, would there be any reason not to rely on Safe Browsing?

Conversely, given the popularity of Chrome (and Firefox, which maintains their own blacklist; also queries Safe Browsing in case the URL doesn't contain an entry in their list), would there be any reason to opt using a browser extension instead? (like SpoofGuard and Netcraft)

Additionally, why would a company invest in phishing solutions (not enough rep points, see the solutions provided by: Entrust, PhishMe, LookingGlassCyber) when they can just use Safe Browsing?

While Google Safebrowsing is today mostly an offline check against some local database they still require that the browser queries google directly before presenting the phishing warning to the user. This is done to reduce the chance of false positives because the online check has the most up-to-date information. But it still might be considered a privacy problem in some environments.

Apart from that relying only on Google Safebrowsing might not be sufficient. From reading the paper it looks like that they get their input mainly from links to gmail users and a few information reported by the users. This means that the input is biased in a way that an attacker has a good chance of late detection if not targeting gmail users. Thus it might be useful to additionally get other sources which don't have this but another bias.

Also according to their paper they target a recall of 90% to keep the false positive rate at a low 0.1%. This means that one in 10 phishing pages will not be classified as such. Increasing the recall would increase the false positive rate so that they classify too much safe pages as malicious. But there are environments where one rather has a higher recall even if the false positive rate gets larger, i.e. better safe than sorry. Note that these are not arguments against using Google Safebrowsing at all but only arguments against relying too much only on Google Safebrowsing.


How do shared folders work with Lastpass I was wondering how the concept of shared folders work with Lastpass. As I understand from their site, Lastpass has a master password, which acts as the encryption key (say MK) for all data stored in Lastpass. However this key is only available on the client side. In addition the users can generate their own key pair (PKI). What is the relationship between the MK and the PKI? When a folder is shared by a user, I am wondering how the recipient would be able to decrypt the data that is being shared as the MK is not available for the recipient. Any thoughts?

From https://lastpass.com/support.php?cmd=showfaq&id=2456:

  Every LastPass user generates a public/private key pair once (client side). The public key is sent to the server, the private key is encrypted (with their standard local encryption key) and sent to the server.  Roles and shared folders are implemented a little different, but they both follow the same general model -- When you want to share data with someone else, you pull their public key and use that to encrypt the data. The other person is the only one that can decrypt it (using their private key).  All this ensures that users can securely access the information stored in Shared Folders.


Can a local root certificate make a user more susceptible to phishing? In order to scan encrypted network traffic, security software usually installs root certificates on the user's machine. Sometimes on websites with standard digital certificates, the local installed root certificate is shown instead of the actual one.

I have for a while been a bit weary of this, not for snooping reasons, but for phishing reasons. The Punycode PoC phishing site contains a digital certificate, and with other phishing sites being issued certificates too (source), it is possible that checking the certificate on a suspeted site might just reveal a the local root certificate of the security software.

This makes me wonder whether this raises security concerns, as I normally check the digital certificate on pages where I am sending sensitive data to check that everything is ok. If however I am given a local root certificate, I don't have the same degree of certainty.

So essentially how can you know whether a personal root certificate is trusting a genuine site with a digital certificate, or just any site with a digital certificate?

Nowadays, any phishing operator can set-up a phishing site with a valid SSL/TLS certificate for free. This happens a lot with Let'sEncrypt, but happened in the past with other CA's as well. And phishing site operators do use SSL/TLS more and more frequently.

The main issue here is that most Internet user believes HTTPS means the website is safe to visit, it is secure. Which is not true. People don't understand that HTTPS means basically only that the communication between the browser and webserver is secured.

So if you are concerned about users being phished via SSL/TLS sites, invest energy in education, test users with phishing sites and teach them when they failed how they could have avoided/spotted the phishing site.

Root certificates in the trusted root certificates can increase the risks at different areas, but phishing is ain't the priority here.


Can a country block your website for using SSL Is it realistic that certain countries like China, Iran, North Korea etc. block your website because it is using SSL?

I realized for my own website that whenever I switch to https, why website can't be opened and falls into infinite loading. I am not sure if it's me or them because the rest of the world can open my site with ssl enabled.

Last but not least, is there any solution to use SSL and not being blocked?

Countries like China, Iran or North Korea are known for their strict control of the internet. The ISP are controlled by the state and techniques like deep packet inspection are used to control what gets transferred. With TLS only the meta information like domain and target IP address are visible and traffic control can only be done based on this. While thus the actual payload is protected it also means that the chance of overblocking is higher since thed ISP cannot be sure that they content of the site if harmless from the perspective of the government and because of this might block when in doubt.

  Last but not least, is there any solution to use SSL and not being blocked?

It is unknown why your specific site is blocked. It might be because the domain name suggests illegal content. It might be because the IP address is shared with other sites which are blocked because of their content. It might be because you use a CDN which supports domain fronting to bypass censorship. It might be because your site is too small to be considered for explicit white-listing and since the actual content is unknown it is blocked to be on the safe site. As long as you don't know why the site is blocked you likely cannot adapt your hosting so that it does not get blocked anymore.