Storing encrypted tokens in LocalStorage I am building a JavaScript application that will run in a web browser but also as a pseudo-native mobile application via Apache Cordova. It communicates via API to a separate backend service.

The app requires that the user be prompted for some kind of identifying information whenever it is launched, but for ease of use this need not be their full username and password. Password entry in particular (and especially on mobile devices) will be too cumbersome to make this feasible. Therefore, we are considering a once-off login procedure where the full credentials are supplied, followed by a “setup” step where the user creates a PIN for future access. This could, in future, be extended to allow a fingerprint/face scan to also “unlock” the app on supported devices.

We are also hoping to avoid the use of cookies. Doing so subsequently avoids CSRF concerns but also, support for cookies in Cordova applications appears to be either non-existent or at least unreliable.

My initial thoughts on implementation are:

The user submits a valid username/password combination to a login/ endpoint of the API and receives an “ID token” in response.
During the “setup” phase, the PIN chosen by the user is used to encrypt the ID token.
The encrypted ID token is stored in LocalStorage.
A secondary request is made to an authorise/ endpoint of the API, including the plaintext ID token. Assuming the token validates, a second token is issued to the app.
This second token is what is used in all subsequent requests to the API to prove the user is trusted, has a relatively short expiry, and is not stored in any persistent manner by the application.
Upon returning to the app at a later date, the user need only provide their chosen PIN.
It can be used to decrypt the stored ID token, which is then used in the authorise/ request to generate and return a new short-lived session token.

The internet abounds with articles advising against the use of LocalStorage for anything sensitive, due to its exposure in the event of XSS attacks. The threat is that a token in LocalStorage could be stolen when the same token in an httpOnly cookie could not. It is worth noting that in both cases, a malicious script running within the app could successfully issue fraudulent requests to the backend API.

I believe the XSS threat of the ID token being stolen is mitigated by it being encrypted under the user’s PIN, and neither the decrypted value nor the PIN itself being stored or used beyond the authorise/ request.

The session token is also vulnerable to being stolen by XSS. It is only stored in memory, but is obviously still accessible to JavaScript and thus to a malicious script. These tokens would be given short expiry times to mitigate this threat. Not to mention we would do our best to harden against XSS in the first place.

I think the above sounds like a secure way to implement our requirements, but I am no security expert. Am I missing any obvious weaknesses here? Does this actually sound secure?

Storing information in localStorage is reasonably secure, but:

It does not expire. Data in localStorage remains there forever, which increases the period that it can be leaked or obtained. For session tokens this generally doesn't matter, since you can expire them server-side.
Values are not encrypted on disk. Chrome encrypts cookie values, but doesn't encrypt localStorage values. In Firefox there's no difference.

  During the “setup” phase, the PIN chosen by the user is used to encrypt the ID token.

If the PIN is numeric and short, the encrypted token would be easy to brute force. So this doesn't protect access when someone has the encrypted token but not the PIN. You can mitigate this a little by using a slow key derivation function.

  The threat is that a token in LocalStorage could be stolen when the same token in an httpOnly cookie could not.

I agree with you that once an attacker has XSS, he doesn't need your token anymore. However, you can get the best of both worlds by using both a token in localStorage, and a token in a HttpOnly cookie. If every request needs both, that protects both against CSRF and stolen session tokens through XSS.

  but is obviously still accessible to JavaScript and thus to a malicious script

I don't know for sure whether that's true. The application could have a variable with a limited scope that is usable but not easily readable by any other JavaScript.

  but also as a pseudo-native mobile application

On mobile, you should definitely try to store your token in the keystore of the device. This is by far the most secure, and protected by the OS and hardware of the phone.


Is it secure to not expire keys in symmetric encryption? Note that this question describe hypothetical case, that is never meant to be used in real world.

Server communicates with clients with message structure: client_id, initialization_vector, encrypted body. Each client each day exchange with server 1-5KB messages average 100 times. Messages "occasionally" may leak out, due to insecure network (e.g. DNS spoofing).

Generated keys are distributed securely to clients by another system. When a key gets compromised, the client can issue another one, but currently the key has no expire time (even after few years). I want to avoid mixing RSA and other asymmetric stuff to keep this simple. Message protocol may change in the future, but previously issued key will be used for stronger encryption without requiring re-issue.

Is this kind of system secure when used with e.g AES/CBC + padding? Can I firmly go forward with this basic approach for years?

Edit 1:

Message initialization_vector is random (AES/CBC) at each message and encrypted_body has internal (encrypted with body) integrity checks (MAC and digest). What makes it insecure despite that? Is option to compromise AES encryption over time really viable in that case?

Edit 2:

Here is pseudo-code of message encryption. When message MAC is not valid, error response is not encrypted (to avoid active attack). System will drop old messages when timestamp is older than T (to avoid reply attack).

init_vector := secure_random (); // for AES/CBC or increment init_vector for AES/CTR
mac = hash (client_id + timestamp + init_vector + text); // MD5 or SHA-1
body = encrypt (mac + text); // AES/CBC
message = client_id + timestamp + init_vector + body;

No, although the reason I see is independent of most of your post.

CBC mode is malleable; you should use a MAC too.


Mission Impossible like defence application project I have a Attack and Defence security project for school and I dont know how to protect it since all classic ways are forbidden by rules ,so

Assume the following project :

A web application with the following functionality:

account registration.
Database connection where all information is stored.
Presentation of this information according to input from user.
The web app will be pentested on LAN level

Rules:

No firewalls allowed.
No fail2ban like applications.
No WAF.
No xss library can be used.
No mitm to inject javascript to add defence layers. (The project will be pentested from within the network.)
No https

Any help is appreciated.

I‘m not sure, why you think you might need any of those things that are forbidden.

What you need is protection against the OWASP Top10, especially

input validation,
prepared statements to counter SQLi,
output encoding,
CSRF-Token,
proper header settings.

All of those things can be learned from the owasp project.


Reversing an entry card - How to find out what type of RFID hardware I need to read the chip? I have an acccess/entry card chip I want to copy for demonstrational purposes. However I am not sure how I can find out what type of RFID reader I need to get a hold of.

Does anyone have a suggestion how I can figure out what type of chip it is and thus what type of reader I need to be able to copy it?

Possible use cases:

Social engineering the business who owns the card or the card issuer (ex. G4S) and try find out the manufacturer is.
Oscilloscope - Read the frequency and get a reader with the same scope.
Dissolving the card (ex. with nail polish remover) and try find out who the manufacturer is by looking for clues on the chip or on the plastic.

You only need one RFID device, its the Proxmark3.  There are many protocols and frequencies used by RFID and the Proxmark3 tries to support all of them.  It is open source hardware and software and breaks every commercial RFID card I know of.  The real problem with RFID is that you have a very limited power usage so you are forced to use weak crypto systems.   Often times they rely upon security though obscurity, and the Proxmark3 is designed to overcome this.


Meterpreter and staged payloads So starting with the absolute basics - an exploit is the means used to gain access to a vulnerable system and a payload is the actual program/shellcode used to fulfill attacker's intentions

A staged payload creates a connection to a victim's machine using a stager - which is a small initial payload that creates a connection to the victim (creating a stager socket) and then passes execution to the next stage which will be the main payload - in this case meterpreter.

In this context, meterpreter is a payload that will be loaded through the stager socket and will allow dlls to be injected to victim machines (meterpreter server) memory...

I've done some research and for me to understand things I attempt to put them in my own words and terms as much as possible.. This is my basic understanding of how staged payloads and meterpreter works, so can you please clarify that my understanding is actually correct?

Yeah basically you need a vulnerability to exploit in order to direct code execution to your shellcode or payload, which can be anything from popping calc to a meterpreter or command shell. This link is a great reference for metasploit in general and specifically about some of the points about payloads it sounds like you are interested in.

http://www.offensive-security.com/metasploit-unleashed/Payloads


Capture Handshake with WPS disabled I just got into exploring network cracking. Honestly, just to learn how the process works.

I am not curious about cracking the handshake as much as capturing it.

It seems when I set up a test router with WPS disabled i cant crack it for the life of me.

I am very new. Should I be running deauth set to infinity and let Airodump-ng listen for a few hours?

Also if someone could be so kind to give me a timeframe as to how long it takes to capture a handshake? My second test router I can capture the handshake in a minute.

thank you all for your help, I did run a search and was unable to locate an answer.

Apologizes if I am offending experts.

WPS - Wifi Protected Setup. Technology used to provide connection by 8-digit PIN code. When you are try to connect with pin code, router will check first 4 digits (10^4). If it is not right, you will receive a disconnect after M4 packet. If it's right - we will know a half of PIN. Last half it 3 digit (3^10) + 1 digit (hash sum). It's fastest way to crack the router but not always. Some routers can block wps if it can see brutforce. And signal must be strong.

WPA - you need a handshake to crack a router. But you need to use password list for brutforce.

WEP - I don't remember, it seems, that it very easy to crack and you dont need a password list for that.

For your question - to crack wpa you need:
 1. Enable monitor mode with airmon-ng
 2. Start airodump-ng
 3. Start aireplay-ng in another terminal, read help and send deauth packects to router
 4. After that you will see "Handshake found!!" in airodump terminal.
 5. Save them to file
 6. Start Aircrack-ng with password list and hope, that needed password will be in your password list.


How does Anti-CSRF token get delivered? I was reading an article describing how CSRF works. The article did a pretty good job but it started to talk about how to protect against CSRF and one of the methods that the article has mentioned is using Anti-CSRF tokens. I'll quote the section below:

Use Anti-CSRF Tokens
Tokens (also known as synchronizer token patterns) are a server-side protection where the server provides a user's browser with a unique, randomly generated token and checks each request to see if the browser sends it back before carrying out a request.

This token is sent via a hidden field and should be a non-predictable, random number which expires after a short time and cannot be reused.

Depending on the sensitivity of the page, different tokens can be used for each request, or simply for different forms. The tokens should be compared in a safe way (such as by comparing hashes) and should not be sent in an HTTP get request so they are not a part of the URL and cannot leak via the Referrer header.

In the third paragraph it says the token should not be sent in an HTTP get request, which I understand (otherwise the token can be leaked). But If the anti-csrf token isn't delivered to the browser via the get request or any of the REST requests (PUT, GET, POST etc), what would be the method to deliver the token such that it cannot be leaked?
The full article can be found here: https://www.freecodecamp.org/news/what-is-cross-site-request-forgery/

I think you are misunderstanding some things. GET, POST, PUT etc. are HTTP request methods, used to send data to the server from a client. They are not used to send data to the client, nor do they affect how it is done.

This token is sent via a hidden field

Your quote describes one way a token may be sent to the browser, in a hidden HTML input field that will be submitted with the form. There are also methods that involve sending it to the browser in a cookie in addition to the form field, as in the stateless "double submit" method. I suggest you see the OWASP cheat sheet for CSRF to see more details.
Usually, CSRF protection isn't needed on GET requests not because it's a security risk itself, but because there isn't any CSRF risk in a GET request if it doesn't change state.


Home "datacenter" security, where and what to look for? This is a question to learn more about security management and physical security.

I'm running a small serverroom in the basement at home, mainly as testbed for attacks I dont want to try on live hosts and for development. I'm more of a learning by doing person, so I want to maximise the security of my basement room and if possible certify it.

Whats already there:

Keypad/Security door
CCTV
Strong Firewall

Now I'd like to document this and implement some recurring checks. Where can I find some documents/helpers to read on security policies and physical security that are flexible enough to be applied to this situation?

EDIT: To clarify a bit, this is about HOW and what to document concerning the security policy. And in a second step I want my documentation to adhere to some standard, so I could possibly get someone to certify it (in theory). I know how to lock a door already ;-)

If it was me I would create a spreadsheet with 2 columns in it with the first one defining the piece of security Ex. •Keypad/Security door •CCTV •Strong Firewall and in the second column back up why the items listed in the first column are considered secure.  For example CCTV | The CCTV system records footage locally and also sends real time alerts to X number of email addresses and one of those is on my personal smartphone so I would be notified immediately. Secondly if power was cut to the device it is powered by a battery backup device that will suport up to XX:XX of recording time on battery only power. Third the system has two different connections to the internet through two seperate networks one hardwired and the second one through a seperate 4G or Neighbors WiFi (with permission).

The possibilities are endless but when I try to sell a solution to a client it's very easy to organize a 2 column spreadsheet outlining the benefits.(Think Cause and Effect) Item A provides this solution, item B provides that benefit, etc. As for certification, I don't know where to point you to, however there is a loophole to this. Certification just means that a third party of some sort states that your configuration is what you claim it is. You could find and or create an entity that would do this and create some type of certificate to show off to your friends or clients. You may want to consider consulting with an attorney if this is the path that you want to take. If you have prepaid legal / Legal Shield you can call them for free consultation under title 1 of your benefits and they would be able to tell you the legality of the "certification" process.


What does this activity record of gmail mean, when it says an authorized application with IP from India? There is a record in my Gmail's activity:

Access Type :
    Authorized Application (860033281504.apps.googleusercontent.com) Hide details
    "name: Yahoo Mail Client"
    "vendor: Yahoo"
    "version: 1.0 1458656085"
    OAuth Domain Name:
    860033281504.apps.googleusercontent.com
    Manage Account Access

Location (IP address)
    India (74.6.109.229)

Date/Time
    5:36 pm (0 minutes ago)

I have never been to India, and have been in US. But https://whatismyipaddress.com/ip/74.6.109.229 shows the IP is from US. Should I worry about my gmail account being hacked?

What does the record mean?

I am using yahoo mail app on android to access my gmail account, besides using gmail's webmail to access gmail.

Thanks.

The accessor claimed to be "Yahoo Mail Client", so either it had to do with you using the Yahoo Mail Client, or coincidentally an attacker also used the Yahoo Mail Client while accessing your account.

The IP address shown (74.6.109.229) seems to be owned by Yahoo: https://db-ip.com/all/74.6.109. It's really unlikely that it is an attacker accessing your account (unless they're coincidentally doing it through a Yahoo server).

Another geo-IP database shows the IP as being in California (https://www.ultratools.com/tools/geoIpResult), so it's probably safe to disregard the detail in the message from Google claiming that the access was from India. Chances are that Gmail is just operating with an old geo-IP database. (Though even if it is from India, it seems to be from an IP block owned by Yahoo, so it would still likely be an Indian Yahoo server.)


Why I recived user-set on my Nmap analyze? I executed this command:

nmap -sn -n --scan-delay 1s --max-retries 0 -Pn --packet-trace --reason <IP>

And I received this response:

  Host is up, received user-set.

It seems that Nmap thinks that inserted IP address is my native PC's IP address. However, it is not.

I am using Nmap on my native Windows 10, ZenMap, against a Windows 7 virtual machine.

How can I change this situation?

The user-set reason is shown if the reason is set to ER_USER. (This is stored in an enum in portreasons.cc of the nmap github repository.

This mapping is set in portreasons.cc:

reason_map_type::reason_map_type(){
reason_map[ER_RESETPEER] = reason_string("reset","resets");
reason_map[ER_UNKNOWN] = reason_string("unknown-response","unknown-responses");
reason_map[ER_USER] = reason_string("user-set","user-sets");

There is only a single point in the NMAP project when the ER_USER reason is set, and that is in this piece of code:

...
        if (pingtype == PINGTYPE_NONE && !arpping_done)
          hs->hostbatch[i]->reason.reason_id = ER_USER;
        else
          hs->hostbatch[i]->reason.reason_id = ER_LOCALHOST;
...

Your Pn flag indicates that there should be no ping used, so the above pingtype == PINGTYPE_NONE, is set by this flag, which validates the first part of the conditional.

Now, there's only the !arpping_done left, which appears to be "false" in your result, as the reason ER_USER is printed in the end.

The flag is initialized as false
And the only code that sets it to true is:

  /* First I'll do the ARP ping if all of the machines in the group are
     directly connected over ethernet.  I may need the MAC addresses
     later anyway. */
  if (hs->hostbatch[0]->ifType() == devt_ethernet &&
      hs->hostbatch[0]->af() == AF_INET &&
      hs->hostbatch[0]->directlyConnected() &&
      o.sendpref != PACKET_SEND_IP_STRONG &&
      (pingtype == PINGTYPE_ARP || o.implicitARPPing)) {
    arpping(hs->hostbatch, hs->current_batch_sz);
    arpping_done = true;
  }

/* No other interface types are supported by ND ping except devt_ethernet
     at the moment. */
  if (hs->hostbatch[0]->ifType() == devt_ethernet &&
      hs->hostbatch[0]->af() == AF_INET6 &&
      hs->hostbatch[0]->directlyConnected() &&
      o.sendpref != PACKET_SEND_IP_STRONG &&
      (pingtype == PINGTYPE_ARP || o.implicitARPPing)) {
    arpping(hs->hostbatch, hs->current_batch_sz);
    arpping_done = true;
}

Which might seem confusing, but is explained in the comment:

  I'll do the ARP ping if all of the machines in the group are
       directly connected over ethernet.

Source

So ARP Scanning will only be done if you're targeting a machine on the local network, which i assume isn't the case.

Also from the docs, to explain the code above a little better than i did:

  For machines on a local ethernet network, ARP scanning will still be performed (unless --disable-arp-ping or --send-ip is specified) because Nmap needs MAC addresses to further scan target hosts. In previous versions of Nmap, -Pn was -P0 and -PN.

As to why no further results are shown:

-Sn (No port scan)

  This option tells Nmap not to do a port scan after host discovery, and only print out the available hosts that responded to the host
  discovery probes. This is often known as a “ping scan”, but you can
  also request that traceroute and NSE host scripts be run. This is by
  default one step more intrusive than the list scan, and can often be
  used for the same purposes. It allows light reconnaissance of a target
  network without attracting much attention. Knowing how many hosts are
  up is more valuable to attackers than the list provided by list scan
  of every single IP and host name.

So, a short conclusion:
Pn causes you to get a true pingtype == PINGTYPE_NONE, the reason that ARP Ping is interpreted as false is likely that the target device is not in yoru LAN, or isn't responding to ARP queries. sn tells nmap NOT to scan ports.


Comparison of signature algorithms HMACSHA1 and RSASHA1 Compare and contrast the signature algorithms HMACSHA1 and RSASHA1.

Assume that the aim here is to make it infeasible to generate valid message+sig pairs without knowing a certain private token/key (but of course, not sending said key over the wire, even though both parties are trusted).

Would there be a reason to choose one method over the other? I would probably prefer public-key-based RSASHA1, but is that necessary, or even advantageous?

HMAC-SHA1 is a message authentication code (MAC) algorithm, RSA-SHA1 is a signature algorithm. Though MACs are sometimes incorrectly called signatures, they are fundamentally different.

With a MAC, anyone knowing the secret key can both create and verify MACs. With signatures on the other hand, anyone with the public key can verify a signature, but only someone with the private key can create a signature.

Signatures are used when it is desired that the party verifying the signature not be able to create signatures. PGP uses them to verify message authorship, TLS use them to verify certificate chains.

MACs are used when all parties involved simply want to know that the message came unaltered from another valid party. TLS uses them to verify that messages are unaltered between the client and server.

MACs are generally significantly faster than signatures. A signature where both parties know the public and private keys could be used as a MAC, but performance would be much worse.

Note that SHA1 is being deprecated in most places due to collision attack. The collision attack doesn't affect HMAC-SHA1, but it may be desirable to use HMAC-SHA256 instead if only to avoid unneeded questions. SHA1 should be avoided with RSA signatures if the attacker has any control over what you're signing, and since it may not always be clear whether or not this is the case (or could be the case in the future due to changes), it's best to just use SHA256.


If my private key is password protected, then how is it used without asking me for it? Relating to TLS and SSH. If my private key is password / passphrase protected, how is this then used automatically during TLS or SSH communication without asking me for the password?

For SSL/TLS, you usually do not have or use a private key, unless you are the server. If you are the server, or are using client certificates (TLS mutual authentication), then the private key will need to be unlocked (if password-protected) before use. The details are implementation-specific.

A web browser like Firefox might ask you for a key's password once and then cache that until the browser is closed.
Browsers or servers (like IE/Edge/Chrome or IIS) that use Windows' key store will either get a password prompt when the key is used, or will have only needed the password when the key was added to the key store and will then have encrypted it using a key protected by your Windows login credentials such that you don't need to re-enter the password but nobody who doesn't know your Windows password can use the key.
Macs can store keys in the Keychain, which works similarly to Windows' key store and is used by Safari and Chrome.
Software that does not use platform-provided key management or prompt the user for a password will need to have the password supplied on the command line when the program starts, stored somewhere (preferably in an environment variable or a file, but some people insist on hard-coding it into the source). This is very common for server applications that need to access e.g. a Java key store and its private keys, and yes, it's a security risk if an attacker gains the ability to read local files.

For SSH, the most common approach is the ssh-agent program (included with openssh, or you can use an alternative one). ssh-agent needs your key's password when it is launched, but then retains the unlocked key until the program closes. ssh-agent doesn't actually reveal the key to anybody; it instead acts as a service that will sign data with that key. The program's IPC endpoint is only reachable by programs running as the same user (or with super-user privileges), so while untrustworthy software running in your account could effectively use the key to SSH into any machine, once you've reached the point of malicious software in your user session you are already in big trouble.


How does malware evade initial discovery? I've been reading a lot about polymorphic and metamorphic malware and how they evade signature-based detection once they have been discovered. These techniques seem to be utilized to evade recurrent detections by AVs and IDSs. It occurred to me that it might be a high priority goal of malware authors to prevent their malware from being ever being analyzed in the first place. Are there any analogous techniques that malware authors have employed in order to prevent their malware from being first discovered so that they never get reported/analyzed in the first place?

Today’s sandboxes are becoming the fastest and easiest way to have an overview of the threat. Ergo, Anti sandbox detection is often used to circumvent detection.  Advanced malware is engineered specifically to detect when it is running in a sandbox. When that happens, the malware will avoid taking any malicious actions and evade detection. Subsequently, when the malware has been allowed to enter the network and finds itself in a real machine, it will begin its malicious behavior.
In order to avoid detection, advanced malware can alter its signature. Signatures are created by examining the internal components of an object. Skilled malware authors modify these components while preserving the object’s functionality. There are multiple transformation techniques used by malware authors and applying any of the following procedures can alter a signature:
• Code permutation
• Register renaming
• Expanding and shrinking code
• Insertion of garbage code or other constructs


Py2exe creates a virus? So I compiled python code to an .exe file using Py2exe.

When running a virustotal scan, I recieved a detection:

https://www.virustotal.com/en/file/90fd487928c8616d9c65e2012a615479492362ca55b65ca9c4aa37ad2494b3da/analysis/

I tried removing py2exe and installing it again, and it gave me a completely different detection:

https://www.virustotal.com/en/file/5a320dfee8ee0bfeb852257aa338e106140e9682f46568837b6fdc8e837a66a1/analysis/1475851252/

I have never encountered a so-called bitcoinminer (I don't even know how to use bitcoin) and trojan.pyth so am really confused as to where these detection's are coming from.

I installed py2exe using pip...

My code using a websites API to get some statistics. Nothing more.

EDIT: MY PC is 100% CLEAN!

To detect threats AV try to compare the file with known malware. But malware changes a lot and thus it is very common that no exact match to known malware can be found. In this case AV try to detect potential malware by comparing techniques and behavior used in the binary to known malware, i.e. use of specific packers or similar.

Of course such heuristics cannot be 100% accurate. This means it can happen that malware gets marked as clean (false negative) but also that harmless files gets marked as malware (false positive) because they've found to employ techniques seen in malware. Too much false negatives mean that malware gets not blocked by the AV but too much false positives means overblocking, i.e. that harmless files gets blocked as in your case.

Unfortunately a low false positive rate usually goes together with a high false negative rate and vice versa so AV vendors need to find a balance between these two which is acceptable by the users.The exact balance depends on the AV and the specific settings but typically we see a false negative rate of 2..6% (i.e. this malware gets not detected) with only few false positives (i.e. small but still existing overblocking). See av-comparitives for detailed statistics.

In your case a single AV vendor had some signature or heuristics which probably matched existing python based malware, just because you also use python. This is a typical case of a false positive and there is not much you can do about. Once your product is important enough AV vendors might explicitly white list it in order to avoid tagging it as malware by accident.


GWT - using burp suite for injecting xss payloads I build a small website for penetration testing purposes using the Google Webtool Kit framework.

However I was able to make the application vulnerable against xss by using following code:

final HTML xssWidget = new HTML();
xssButton.addClickHandler(new ClickHandler() {

    @Override
    public void onClick(ClickEvent event) {
        xssWidget.setHTML(xssTextField.getText());
    }
});

As you can see I am using an HTML widget to display input information directly in the UI. When the user fills in some text into a text field, it will be displayed immediately after clicking on a button.

So far so good.. The problem is, I can't use burp suite to record the request I sent and use this as a base request for the Intruder or Repeater. Clicking on that button is "technically" not seen in burp, because it is not directed to the server (no interaction).

Can anyone give me an advice?
Best regards,
Nazar

Since Burp is acting as a proxy, and since your XSS exercise happens client-side only, Burp will not be of any use as far as I know (since it is not a DOM manipulator, for example).

If you want to involve Burp in your resting, and since it is acting as a proxy, you have to adapt your code so that an http request can be captured and replayed (and for which parameters can be fuzzed).

I'd recommend you to have a form that submits a request with a "payload" parameter, and to fill the content of your DOM via an event handler. By doing so, you would be able to use Burp's features, including the fuzzing of the "payload" parameter


What are the realistic, and most secure crypto for Symmetric, Asymmetric, Hash, Message Authentication Code ciphers? I'm interested in updating this two pronged question for 2011:

What cryptology is most appropriate for low-powered devices (such as a cellphone), and yet still effective?
What cryptology is most secure for a .NET developer?

In November of '08 Rasmus Faber answered this similar Stack Overflow question with this response:

  Symmetric cipher: AES-256
  Asymmetric cipher: RSA with 4096 bit key (I believe that is the
  maximum in .NET) or ECDSA with
  571 bit key (but that is only
  supported in .NET 3.5)
  Hash: SHA-512
  Message Authentication Code: HMAC    with SHA-512

  That being said, those are overkill
  for most applications, and you should
  do fine using AES-128, RSA with 2048
  bit key, SHA-256 and HMAC with
  SHA-256.

Are these recommendations still true today?

The recommendations you cite are kind of overkill. One point to take into account is that beyond a certain level (e.g. on key size or hash function output size), all functions are "unbreakable with foreseeable technology" and it is a bit delicate to compare them. Stating that SHA-512 is "more robust" than SHA-256 means that you are imagining that SHA-256 could be broken, which, as far as we can tell for now and the next 40 years, is not true (beyond 40 years, trying to envision what technology we could have is risky; 40 years ago, nobody was imagining the Internet as it is today, but most people assumed that by 2010 we would all drive flying cars).

AES-128 is already secure enough, and less expensive (AES-256 uses 14 rounds, while AES-128 uses 10 rounds).

The currently largest broken RSA key is a 768-bit modulus, and it took some huge effort (four years, and really big brains). 1024-bit keys are considered usable for short term security, although larger keys are encouraged. 2048-bit keys are appropriate. Using a key twice larger means 8 times more work for signing or decryption, so you do not want to overdo it. See this site for a survey of how RSA key length can be related to security.

ECDSA over a 256-bit curve already achieves an "unbreakable" level of security (i.e. roughly the same level than AES with a 128-bit key, or SHA-256 against collisions). Note that there are elliptic curves on prime fields, and curves on binary fields; which kind is most efficient depends on the involved hardware (for curves of similar size, a PC will prefer the curves on a prime field, but dedicated hardware will be easier to build with binary fields; the CLMUL instructions on the newer Intel and AMD processors may change that).

SHA-512 uses 64-bit operations. This is fast on a PC, not so fast on a smartcard. SHA-256 is often a better deal on small hardware (including 32-bit architectures such as home routers or smartphones).

Right now, cheap RFID systems are too low-powered to use any of the above (in other words, RFID systems which can are not as cheap as they could be). RFID systems still use custom algorithms of often questionable security. Cellphones, on the other hand, have ample enough CPU power to do proper cryptography with AES or RSA (yes, even cheap non-smart phones).


Passive fingerprinting of email client, based on email headers Are there ways to passively fingerprint (infer) the operating system or mail client that an email sender is using, based upon the headers of an email from that sender?

I'm familiar with passive network fingerprinting tools like p0f: given a trace of some packets sent from a particular machine, they try to infer the operating system that machine is using.  Are there techniques or tools for doing something analogous, with email messages?

I can think of some techniques that get some partial information in some cases, but I don't want to re-invent the wheel if this already exists or has already been studied.  For instance, I know of the X-Mailer: header, which if present will typically reveal the mail client that the sender is using.  But are there techniques that work to infer the mail client if X-Mailer: is not present, or to infer the operating system?

Are there ways to passively fingerprint (infer) the operating system or mail client that an email sender is using, based upon the headers of an email from that sender?

Yes, but they are extremely prone to errors and very easy to spoof, either intentionally or unintentionally (e.g. some high-end firewall systems will "repack" a message after removing/sanitizing attachments, modifying some information).

Apart from the X-Mailer header, you can glean some information from other fields such as the message-id and multipart boundaries, if present. Both should contain a unique sequence, and different systems generate that in different ways. Some MUA will generate a message-id of their own, other will leave the chore to the server; so you see 'DE9E2BFC.12345@gmail.com' and you know it's a GMail customer and nothing more, while o8xp315ahi3207wv6gbl5tfiedsaelntas@4ax.com is an ID produced by Forté Agent, a software which only runs on Microsoft Windows.

The old Eudora up to 6.1 had a X-Sender header which also revealed the "persona" used to send an email.

Microsoft Outlook uses, I think, boundaries of the form _NextPart_XXX_0000_HHHHHHHH.HHHHHHHH where H is a hex digit and XXX represents the inner sequence number (000 onwards), while Mozilla Thunderbird (which also adds a User-Agent header) uses a boundary of "------------0x0x0x0x0x0x0x0x0x0x0x0x" where x is a 0-9 digit.

In several cases you will see that a part of the uniqueid is actually a timestamp, which can also double as a verification of the date header.

So, some information is there -- but you'd need to build a fingerprint database. Also, as I said, it's relatively easy to modify a single header, and maybe even all of them; you'd have to take this into account and see if the strategy still fits your purpose.


Is it dangerous to allow clients to run JavaScript on a Server On a webpage I have been working on, we can archive certain webpages for a user. The user can give an address and this webpage is than visited on the server and archived. Lately, I noticed that JavaScript is turned on.

Obviously, the client can execute any JavaScript on the server. Now my question is - what vulnerabilities are exposed by allowing the client to execute arbitrary JavaScript on the Server.

The webpage is not only archived, but also all scripts are run for at most 200 milliseconds, after which a screenshot is taken.

If any of the pages you've archived on your server contain malicious code targeting webkit vulnerabilities (remember, wkhtmltopdf runs on webkit), it's theoretically possible this will result in a security breach on your server upon running the page through wkhtmltopdf.

The implication here being that malicious code that would normally target your users' client machines is now de facto attacking your server, you'll have to decide for yourself how you rate this risk.


Using random number to salt passwords in a project I have, I'm salting passwords with 3 salts at the moment...

Static salt - hard-coded into the source-code.
Randomly generated salt (using a function designed for generating password salts). This is stored in the MySQL database.
A random number that isn't stored.

When checking the hash, I generate 100 different hashes with the static salt, the salt stored in the database, and one of the possible random numbers, if one of them matches the password is correct.

I'm using sha512, by the way.

Is this a secure way to hash passwords?

Thanks!

Is this a secure way to hash passwords?

Probably, but a lot of your additional complexity isn't really adding much security value.

The idea of a salt is to ensure there is no method more efficient to recover your passwords than to brute force every single one of them from scratch. Therefore your goal is to ensure no two accounts have the same salt (ie. it is globally unique). If they did then an attacker could basically get two for the price of one by constructing a lookup table while brute forcing the first.

To achieve this you need enough entropy in your salt to ensure the probability of two accounts having the same salt is negligible.

  Randomly generated salt (using a function designed for generating password salts). This is stored in the MySQL database.

This is the primary source of entropy in your scheme. You could probably discard the rest without significantly compromising security.

However for this salt to be effective you must ensure:

The random value you're using is generated using a RNG suitable for cryptographic applications.
There are enough bits in your random value to minimise the probability of a salt collision. OWASP suggests at least 32 bits.

  Static salt - hard-coded into the source-code.

This is adding minimal cryptographic value. From a theoretical perspective it's not adding any additional entropy assuming the attacker knows the value, and from a practical perspective DB servers are usually compromised via credentials obtained from a compromised application.

  I'm using sha512, by the way.

While this is a cryptographically secure hashing algorithm, it's also a "fast" one which is a problem given that users typically use weak passwords. You should consider using either a slow hashing algorithm (eg. bcrypt) or iterate your hashing process 10k or so times. If it takes a second or so to calculate every hash then even a dictionary attack will take a very long time.

  When checking the hash, I generate 100 different hashes with the static salt, the salt stored in the database, and one of the possible random numbers, if one of them matches the password is correct.

The value of this is minimal, you're basically just adding one or two extra characters to the password then brute forcing them every time. This will slow your hashing scheme down which is good, but you'd be better off using the technique above to achieve this.


Is injecting malicious file with browser localstorage possible? Lets say, I visited a "malicioussite.com" and the server had a "malicious.js" in it whose job is to write malicious code to my browser localStorage and save it to the my computer  then execute it to infect my computer.

I don't think this is possible but after researching a little bit I found this page
 which explains how to write localStorage data to a file and save it .Then I found this page which explains how to execute bat files with javascript. I know that no browser would allow such a security breach but I still wonder if this can happen.

It is not standardized how a web browser saves the data it gets asked to store in localstorage. But it is very unlikely that it will be implemented in a way that it ends up as a valid executable file, and even when it would be, it is unlikely to be a file you or your operating system would ever execute. Security vulnerabilities in the implementation details of specific browsers are of course always possible, but the standard has no obvious ones.

The two stackoverflow questions you found are misleading.

The first one requires user interaction to intentionally save a file, and that file could come from anywhere, not just the users webstorage. Popping up a download dialog for an arbitrary file using javascript is web developer 101 knowledge (it's document.location = "http://example.com/malicious_file.exe" when you want to know) and any internet user should know better than to save and execute random executable files they get prompted to download.

The second works only on IE and only when the HTML page is loaded from the local filesystem, not from a remote webserver.


Whatsapp encryption keys Today I woke up and checked my Whatsapp and got the message that communications are encrypted end-to-end from now on.

However, how can I know whether Whatsapp can be trusted?

I did not generate my private/public keys, nor can I change them. Isn't this always a security flaw?

Could it be that the private keys were intercepted as they were being sent to users?

Could it be that Whatsapp kept the private keys, just in case the FBI gets really mad about not being able to access some account and demand cooperation?

"I did not generate my private/public keys"

You didn't, but your device did.

  "nor can I change them"

I wouldn't be surprised if they add that ability in future  (as it'd just be a case of being allowed to authenticate with your existing key and then request that it be replaced: providing only a new public key at that point)

  Could it be that the private keys were intercepted as they were being sent to users?"

The keys are generated client-side, or so they say...

  "Could it be that Whatsapp kept the private keys, just in case the FBI gets really mad about not being able to access some account and demand cooperation?"

We'll see....

Their paper gives a decent description of what's going on and includes a link to the (open source) protocol library that they use.

However, as with any system, you ultimately have to trust that they're on your side and not the bad guy's (whoever that may be) because if they control the code and the updates to it, then they still have the power to release modifications targeting specific users etc if required... However, much like the Apple vs FBI case, it's really not in the tech companies' best interest to be seen to give in to such demands.


Has my Mac been compromised? I am running NOD32 on a Mac running Leopard 10.5.8. When I visited a website, NOD32 automatically detected it as a virus. For some reason I was taken to bing.com and I got a "page not found" error. Was this attack blocked or what? Upon further investigation, I looked into the history NOD32 had collected and multiple attacks were blocked -- some of them were even Trojans.

I ran a scan of just the Firefox folder and no virus was found using NOD32.

2/26/12 9:28:29 PM Kernel access control file /Users/mycomputername/Library/Caches/Firefox/Profiles/80kcg6jj.default/Cache/A/11/405BFd01 HTML/ScrInject.B.Gen virus deleted mycomputername Event occurred during an attempt to access the file by the application: /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Support/mdworker. 2/26/12 9:25:41 PM Kernel access control file /Users/mycomputername/Library/Caches/Firefox/Profiles/80kcg6jj.default/Cache/A/11/405BFd01 HTML/ScrInject.B.Gen virus deleted - quarantined mycomputername Event occurred on a new file created by the application: /Volumes/Firefox/Firefox.app/Contents/MacOS/firefox. 2/26/12 9:25:25 PM Kernel access control file /Users/mycomputername/Library/Caches/Firefox/Profiles/80kcg6jj.default/Cache/1/DD/0E3D8d01 HTML/ScrInject.B.Gen virus deleted mycomputername Event occurred during an attempt to access the file by the application: /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Support/mdworker. 2/26/12 9:25:24 PM Kernel access control file /Users/mycomputername/Library/Caches/Firefox/Profiles/80kcg6jj.default/Cache/1/DD/0E3D8d01 HTML/ScrInject.B.Gen virus deleted - quarantined mycomputername Event occurred on a new file created by the application: /Volumes/Firefox/Firefox.app/Contents/MacOS/firefox. 2/26/12 9:25:10 PM Kernel access control file /Users/mycomputername/Library/Caches/Firefox/Profiles/80kcg6jj.default/Cache/E/91/48C25d01 HTML/ScrInject.B.Gen virus unable to clean mycomputername Event occurred during an attempt to access the file by the application: /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Support/mdworker. 2/26/12 9:25:09 PM Kernel access control file /Users/mycomputername/Library/Caches/Firefox/Profiles/80kcg6jj.default/Cache/E/91/48C25d01 HTML/ScrInject.B.Gen virus unable to clean mycomputername Event occurred on a new file created by the application: /Volumes/Firefox/Firefox.app/Contents/MacOS/firefox.

There is no evidence here that the machine was compromised.

This is your web browser accessing some pages that had exploits on, and consequently saving them to the standard browser cache. The AV caught and prevented the file storage, generating the alerts in the process.

The thing is, these alerts, and indeed the AV behaviour in general, are pretty useless:

If your browser and any web-visible plugins are up-to-date and not susceptible to the exploits in question, you weren't in any danger in the first place.
If your browser or plugins were susceptible to the exploits, you got compromised regardless of the AV blocking storage to the cache.

(Chances are that even if you were vulnerable in principle, the exploits probably only had payloads targeting Windows. There are cross-platform sploits, usually based on platform-independent plugin weaknesses, but they're not yet that common.)

So, yeah, I wouldn't re-install based only on the evidence above. But no-one can guarantee that you weren't compromised by something else that the AV didn't detect. AV is of diminishing reliability today and is wrong as often as it's right.


What precautions/training do companies have against social engineering strategies? For example, if someone were to call a cell phone provider like T-Mobile, pretending to be another person to get some information, how can T-Mobile verify if it is the actual person? I'm assuming that if someone is planning an attack, and are using social engineering then they do not know the username/password of the victim. So when the customer service representative asks for a password or pin, the attacker doesn't know it.

There are "script books" for this, either used in operator training or even kept on the operator's desk when they answer. They detail what you can say, what you must provide, and what the operator can do in any conceivable circumstance.

In this case the T-Mobile operator would ask for some kind of proof among those listed in their script book. The attacker either can supply it or he can't. I have seen such a script book for one of my country's providers, and if you asked, say, for a PIN reset or a new SIM, you'd be either directed to a point of sale where they would ask your ID, or requested to send them through fax or email.

As a routine precaution, at semi-regular intervals (I am not aware of this being done by telecom providers, but I saw it done in more sensitive customer care contexts) a fake customer would call with a two-handkerchief sob story, doing his/her damnedest to convince the operator to help him/her. If he/she succeeded, the next day the operator would have been called by management for an uncomfortable discussion on security rules.

This had two purposes: to be sure that the operators were proof against at least some attacks; and to harden them against said attacks, because even if they did not suspect it was a social engineering attack, they would still suspect it was the management testing them.

Personal story: I was in the habit, waaay back in the days, of sending employees emails with executable attachments that sounded a bullhorn WAV, displayed "SUCKER!" on screen, and sent me back confirmation of a "hit". One day, I overheard unseen a colleague asking, "I've just received an attachment called QJWFWKEK.EXE, what do I do?" - and while thinking "Oh no, he got a real one - and what a moron to ask what to do!", I heard his mate cry, "For Pete's sake do not click on it! Delete it immediately! It's surely one of those fucking traps Serni keeps sending us!"


Someone is logging into my webserver For a week someone has been logging into my webserver. Yesterday I mentioned this to the hosting company. They tell me to use an "IP blocker".

I am doing that, but today I looked for more logins. The IP logging int is 37.201.196.78 (that's not my IP). Today I searched more info about this IP with Zenmap:

I know when anyone logs into my server, because I can see it in my cPanel (linuxuse is my username, 139.162.169.45 is my server, linuxusers.net is my domain, I log in  to the server from the hosting site's portal, but it is not the IP's shown):

With this information, what can I do to frustrate more attacks?

One more thing, I think they have also to put a "thing" on my hard disk, because today I updated a page on my webserver and two minutes later, I see this in my comments moderation panel:

Can anyone explain what can I do using simple terms?

(Ich habe dies zweimal aus dem Deutschen übersetzt, um sicherzustellen, dass Sie Google Translate ohne Bedeutungsverlust verwenden können)

In simple terms, you do not have a "web server". You have an application that runs on a web server.

This application must have a so-called "access control" (or password or security feature). This is what you need to check.

An IP Blocker only prevents access from a specific IP address (or IP range), but the attacker only needs to change their IP address (there are ways to do that) and the IP Blocker is defeated ,

If you have changed the password and reinstalled the application on a clean system and the attacker still has access to the application, there may be a vulnerability in the application. It is best to contact the application developers or maintainers (not the web hosting company, since they do not know the application). It is unlikely that you can fix this yourself.


Is a vulnerable router less of an issue when placed "behind" a secure one? Assume router A, which is secure with up to date firmware, and router B, which is less secure, with no longer updated firmware.
I have one router connected to the net socket (internet source), and the other router connected to the first one via WAN. Each router has a different router IP address, and two separate wifi access points.
From the perspective of security, is there any difference which router "comes first", that is, which is the router that connects to the internet source and then "forwards" it?
Note: For the purposes of the question, assume no other difference in use. Both routers are accessed by devices I control and for similar purposes.

TL;DR: It is a bad idea to place a vulnerable router on the network in the first place. But depending on the actual vulnerability and on the trust one has into other devices in the network it might be possible to at least reduce the impact of the vulnerability.
From my understanding you are proposing the following setup:
    Internet
       |          WAN A
    ----------
    |  A     |
    ----------
    |  |  |  |    LAN A, WiFi A
       |
       |          WAN B
    ----------
    |  B     |
    ----------
    |  |  |  |    LAN B, WiFi B

Assuming that both routers do NAT from LAN/WiFi to WAN the following observations can be made:

The devices in LAN A and WiFi A are accessible from LAN B and WiFi B, unless an explicit separation is done in router A (which is not even possible with many routers).
The WAN interface of A is accessible from the internet.
The devices in LAN A and WiFi A are not accessible from the internet, unless explicit port forwarding is setup in A.
Because of [3] the WAN interface of B is not accessible from the internet.
Similar to [3] the devices in LAN B and WiFi B can not be accessed from LAN A and WiFi A due to NAT in router B (assuming no port forwarding is setup).

It is assumed that a successful exploit means that the attacker compromises a router in a way that they have access to both WAN and LAN/WiFi side systems and maybe can also modify any traffic passing through the router. Based on this:

If the router can be exploited from the WAN side then it would be a bad idea to use it as internet facing A. This way
all devices in LAN A and WiFi A might be affected and additionally
the internet facing traffic from devices in LAN B and WiFi B could be
impacted. Placing such vulnerable router inside as B prevents attacks
from the internet but still allows attacks from inside LAN A and WiFi
A.
If the router can be exploited from the LAN side or WiFi (for example by using a CSRF attack run through a browser inside LAN B) then it would be a bad idea to place it as internal router B. This way not only the devices in LAN B and WiFi B are impacted but is would also be possible to attack the devices in LAN A and WiFi A. Making such router instead internet facing as A, would still allow attacks from LAN A and WiFi A but no direct attacks against LAN B and WiFi B. But internet facing traffic from B might still be affected by a compromised router A.


For PCI compliance, does every request need to be logged regardless of how it affects system performance? Our cloud based service is currently undergoing changes with a view towards PCI compliance.

It is a high throughput service, and there are concerns that enabling the right amount of logging on our web server application will hinder performance of our system (What logs to retain for PCI-DSS? - Retain All The Logs). During performance testing there is a large performance deficit when logging is enabled. This post suggests what should be logged from a PCI perspective.

Disregarding PCI, from a security point if view I believe we will need to log every HTTP request like the httpd web server does by default because if there is any breach it would be difficult to perform forensic analysis on a system if logs are missing.

Am I correct in believing we will need to log every request and we will just need to take the hit and scale appropriately? Would it be acceptable to log to RAM disk and export the logs at regular intervals as a possible PCI complaint solution to the performance problem?

Let's try to tackle two problems at once. First of all yes you will take a performance hit, especially if you are logging onto the same machine. The idea is that you do not log everything locally but instead use an encrypted syslog connection (or similar) to log every request to a seperate logging server.

This will relieve the webserver from being busy with the logs. Normally this shouldn't be too difficult as normally you should have some sort of SIEM implemented (right?) where you can immediately log towards to. This will also allow you to write specific SIEM business rules for realtime allerting (or you can use the logs for statistics). Depending on how much money you have you can either go with Splunk or go for something more affordable like logstash with Kibana.

Log rotation and analysis in case of breach are also a lot easier when you've already imported logs into a similar database as they are extremely good at allowing fast log aggregation, correlation and searching. When you have a breach the last thing you want to be doing is spending tons of time importing logs into similar tools to analyze them.


Is it possible to determinate which functions a kernel module calls? Trusting kernel drivers is bad. Is there something we can do to have at least an idea about what it does?
For example, let's suppose an armv8a linux kernel. I'd search for all the syscalls, which according to https://stackoverflow.com/a/12951533, are the SVC commands. They should contain the number of the syscalls and I could find which functions of the kernel are being called. But this is for syscalls only.
However, a kernel module can use other symbols, which I don't know how to find.
Also, I don't know if it's possible to do this in armv8a, but couldn't the kernel module code generate a binary data in RAM and branch to it, and this block could contain a syscall by itself? This wouldn't appear in a static analysis of the kernel module, because it happens in runtime.
I'm trying to get into this world of binary analysis and I'm a little lost.

Trusting kernel drivers is bad.

Oh? Why? Almost everybody does this. Whether it is a Windows kernel driver or a Linux driver doesn't matter. Furthermore: they are an extension of the kernel, and if you don't trust device drivers, why trust the rest of the kernel?
In general, we trust the OS we get. We take some precautions to make sure it is correct (for example: we download from a trusted source, buy it from Microsoft/RedHat/Apple/... etcetera). The kernel drivers are part of this. Of course, if you need specific hardware (e.g. graphics cards), you may need to use a driver from the hardware manufacturer. If you do not trust him (f.e. you fear that there may be NSA/Chinese/Russian/... backdoors in it), don't  use that hardware.
The example you gave is, as you said, for system calls. On Linux, some additional info can  be found in man 2 syscall.
In general, it is far easier to look at the source code, if it is available, than to look at the binary. Disassembly or decompiling may seem a viable option, but (for example if you're on Windows) check your license.
The kernel drivers in general run in privileged mode. That means that almost everything is possible.


Standards for encrypting passwords in configuration files? My workplace has a standard that plaintext passwords are not allowed in application configuration files.  This makes enough sense on its face, in case someone gets access to the config files they don't automatically have access to all the privileges of that application.  In some cases it's possible and obviously preferable to have access associated with the login or otherwise avoid having a password, such as in Windows Security for SQL Server authentication, or have it configured in a third party location, such as JDBC configuration in a J2EE environment, but this is not always possible.

When I must have a password in a configuration file, what level of encryption should it carry?
How do you deal with the fact that the encryption key for the password has to be either hard coded or stored in yet another config file?
Should the encryption keys for password be human readable?

If you are running a server that needs a password for access to some remote service, then there's no good solution.  Storing the password in a configuration file stored in a suitable location is probably making the best of a set of poor choices.

The choices are: have a user enter in the password at boot time (this is bad, because if your server gets rebooted, now the server is unreachable until a person can physically walk up to the server and enter the password); hardcode the password into the source code of the server code (this is much worse than putting it in a configuration file); or store the password in a configuration file (the least bad of all options).  The main thing to watch out for with the configuration file, is to make sure it is stored outside of your web root and that its file permissions are locked down appropriately.

Encrypting the password that's stored in the configuration file doesn't help, because now where do you store the decryption key?  You've just shifted the problem around.  "It's turtles all the way down" is not an acceptable response.

On Windows, another option you might look at is storing the password in DPAPI.  This helps a little bit for desktop applications, but is not very useful for unattended servers.

For more, read the following questions on this site:
Store a password to avoid user interaction,
where to store a key for encryption,
How do open source projects handle secure artifacts?,
How can I decrypt data with Java, without hard-coding the key?,
Password in file .php,
Where do I securely store the key for a system where the source is visible?.

P.S. In principle, you could use a TPM to store the password -- but in practice, this gets you into bleeding-edge issues, so it's probably not viable for most folks.


SSL certificate for WebAPI We have a simple system with a REST service (WebAPI) that will be hosted on one machine (hosted on IIS on a custom port, port numer 3031) and with a website hosted on another machine that will be talking to the service.

We want both to use SSL, so as I understand we will need to purchase two separate SSL certificates for the production deployment on the Internet.

Does that sound right?

If so, then I don't know how do I request and purchase a certificate for the WebAPI REST service... The service will be hosted on a custom port 3031, should I purchase a normal certificate for the domain name of the machine where the service will be hosted? And then should I basically install the certificate on the IIS on that machine (like it's described here: https://docs.microsoft.com/en-us/aspnet/web-api/overview/security/working-with-ssl-in-web-api).

How will I be able to perform a verification of the domain for the purchased certificate if I'm going to use the certificate for a REST service on a custom port? (not for a regular website).

Apologies for my ignorance, I have searched the forum to find an answer to my issue, but I didn't find one, maybe it's because my very limited knowledge about certificates and security.

Your options is to:

Make self signed certificate for API-machine, add this certificate to list of trusted certificates on webapp machine;
Make worldwide-valid certificate for API-machine for free with LetsEncrypt (no ads, they're de-facto standard now).

There is no differense, which port does your service resides on. Certificate proves Common Name (CN) - and when it comes to HTTPS, it can be either server's domain name (https://example.com:3031 for certificate's CN example.com) or IP-address (https://11.22.34.56:3031 for certificate's CN 11.22.34.56)


Encryption and Deniability I have the following problem: Alice wants to send Bob a message such that Bob knows it is from Alice but at the same time he cannot prove that Alice send him this message.

The solution I came up with, using RSA, is:

Alice picks a random key K, and encrypts the message M using this key K. M'= aes(K, M)
Alice hashes K and Bob's public key to get H. H = sha(K + Bob's Public Key)
Alice signes H using her private key. S = rsa_sign(Alice's private key, H)
Alice encrypts K and S using Bob's public key. P = rsa_encprypt(Bob's public key, K + S)
Alice sends P, M' to Bob

Bob receives P, M':

Uses his private key to get K, S.
Uses Alice's public key to verify S
Uses K to decrypt M'.

Do you see any holes in this?

Thanks!

Given the step P = ras_encrypt(Bob's public key, K + S), there isn't really a way for Alice to deny that she knew K, and therefore knew (or could have known) the content of M, and therefore she can't plausibly deny that she sent the message M to Bob. Some other person who does know K could create H, and Alice could have been duped into creating S from H.  However, the step that generates P requires Alice to know K, so she can't plausibly deny being able to read M', which for all practical purposes means she knows what was in M and therefore sent M to Bob (and he has proof that she did so).

However, we can consider a variation on the proposed protocol which would mean that Bob knows Alice forwarded the message, but does not prove that Alice knew the content of the message that she forwarded.  The alternative solution, using any appropriate public key cryptosystem (PKCS), is:

Alice picks a random key K, and encrypts the message M using this key K.
    M' = AES(K, M)
Alice hashes K and Bob's public key.
    H = SHA(K + Bob's Public Key)
Alice encrypts K (plus arbitrary extra material if the key is deemed too short) using Bob's public key:
    K' = PKCS(Bob's public key, K)
Alice encrypts H using her private key.
    S = PKCS(Alice's private key, H)
Alice encrypts K' and S using Bob's public key.
    P = PKCS(Bob's public key, K' + S)
Alice sends P, M' to Bob.

When Bob receives P, M', he:

Uses his private key to decrypt P and get K', S.
Uses Alice's public key to decrypt S and get H.
Uses his private key to decrypt K' and get K.
Uses his public key and K to validate H.
Uses K to decrypt M' and get M.

Alice can now deny creating the message because she could have been duped by Mallory (the malicious) into taking M', H, and K' and producing S and then P, and sending P and M' to Bob, without actually knowing K or what's in M.  It would require some gullibility to have been deceived like that, but deniability may require the appearance of gullibility.

If Eve (the eavesdropper) intercepts P and M', she can do nothing. She cannot decrypt P because she does not have Bob's private key. Therefore, she cannot retrieve K' or S, and therefore cannot get the original K or M.

Clearly SHA and AES can be any agreed upon secure hash algorithm and symmetric (private) key algorithm.

Or have I goofed somewhere?


How are root CAs for SSL distributed? For internet explorer or whatever, I get it... It's in essence a sneakernet, you get them on the physical media from which you install your system and browser.

But what about for firefox and chrome?

And then, what about when you get a linux distribution? Isn't all "secure" SSL traffic on a linux computer theoretically insecure, if all the root certificates came pre-installed on an image that was downloaded insecurely?

I mean, unless, I suppose, they provide a checksum via SSL that you verify before you install the system, right?

When software needs to use SSL/TLS, it commonly wants to use a list of Certificate Authorities. There may be software that simply always warns for every unknown certificate, but like you said, Firefox and Chrome have a list of CAs.

Where they get this list depends on the software. You can google this, you know.

Mozilla maintains an own list of CAs (for Firefox, Thunderbird, etc.)
Chrome uses the CA list from the operating system, or at least on Windows I read.
Opera maintains an own list of CAs it seems.
Safari uses the OS's list (Apple's on OS X and Microsoft's on Windows).

Then about your question regarding how this list is obtained: You are right, if the download was not verified to be secure (in a secure way), then all communications from thereon are inherently insecure. When you are downloading a Linux distribution and I replace your download with one that has an altered CA list, then yes, I could read all your HTTPS communications. It's probably much easier to just install malware though.

Note that a checksum alone is not the ultimate solution: the checksum must be obtained over a secure connection (e.g. https), or else that too can be altered.

It's funny: if you need to obtain the checksum over https, where did your current browser (or OS) get a CA list? Somewhere you always have to trust someone or something (such as the shop you bought Windows from), besides the trust that you put in CAs.


Why does Chrome warn about "Obsolete Connection Settings" for key exchange? What do I have to change so Google Chrome won't say that I am using an obsolete key exchange?

Obsolete Connection Settings
The connection to this site uses a strong protocol (TLS 1.2), an obsolete key exchange (RSA), and a stronc cipher (AES_128_GCM).

I am using Apache 2.4.18 and OpenSSL 1.0.2g. These are my settings:
SSLOpenSSLConfCmd DHParameters    /etc/ssl/certs/dhparam.pem
SSLOpenSSLConfCmd ECDHParameters  Automatic
SSLOpenSSLConfCmd Curves          secp521r1:secp384r1:prime256v1
SSLProtocol                       all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite                    ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
SSLHonorCipherOrder               on
SSLCompression                    off
SSLSessionTickets                 off
SSLUseStapling                    on
SSLStaplingResponderTimeout       5
SSLStaplingReturnResponderErrors  off
SSLStaplingCache                  shmcb:/var/run/ocsp(128000)

These are the recommended modern settings from the Mozilla ssl-config-generator. Any ideas?

As Steffen Ullrich mentions in the comments, Google Chrome or Chromium basically lets you know there is no ECDHE ciphersuite used. This is no problem per se, but if you can permit it, use an EC key exchange.

The config you post is correct to the level that it will generate a certificate based on Elliptic Curves. However it seems like Apache is serving an RSA certificate.


Convert ECDSA keys (PEM, OpenSSH) To work with ECDSA keys I am using the python-ecdsa library. Unfortunately this library can not process keyfiles properly if they are provided in the OpenSSH format. Instead I generate them in the PEM format, which the library can handle, using the following command:

ssh-keygen -t ecdsa -b 256 -f /home/user/Documents/ECDSA/key -m pem

However, while I am able to work with the keyfiles in PEM just fine, I do need them in the OpenSSH format in the end. The following ideas come to mind:

Generate them in the OpenSSH format and convert them to the PEM format.
Generate them in the PEM format and convert them to the OpenSSH format.
Generate them in both formats in one go?

Is any of these options possible? I am aware one can convert formats when the type is RSA like so:

ssh-keygen -f id_rsa.pub -m 'PEM' -e > public.pem

However for ECDSA that is not possible:

do_convert_to_pem: unsupported key type ECDSA

What options do I have?

Which key(s) are you trying to use with that library -- private or public, which that library calls Signing and Verifying -- or both?

ssh-keygen -t ecdsa -b $n -m pem (in OpenSSH 7.8 up) with empty password generates the private key file in OpenSSL-compatible unencrypted format (with header -----BEGIN EC PRIVATE KEY-----) which that library wants; it generates the public key file in OpenSSH's own format which is completely unlike anything OpenSSL uses or that library wants. If you (mistakenly?) generate (or convert) the private key file in OpenSSH 'new' format (default since 7.8 and before that -o, with header -----BEGIN OPENSSH PRIVATE KEY----) you can convert it to OpenSSL form by 'changing' the password (possibly from empty, definitely to empty) with ssh-keygen -p -m pem [-f file] (but NOT -e). You can use -P old and -N new on the commandline if you don't want to be prompted for the passwords.

ssh-keygen -e [-m various] operates on the public key, in either OpenSSH format or several other formats. In particular -m pem for a public key means an RSA-only format defined by PKCS1 and used by OpenSSL briefly long long ago. OpenSSL in this century uses the generic format defined by X.509 "SubjectPublicKeyInfo", more conveniently available in rfc 5280 and for ECDSA specifically rfc 5480, which currently works for RSA DSA and ECDSA though not Ed25519, and which ssh-keygen bizarrely calls -m pkcs8 even though PKCS8 is actually a quite different standard for private keys. (Recent versions of OpenSSH discourage use of DSA in SSH, but as of now ssh-keygen still supports keys for it.)

Cross-similar https://superuser.com/questions/1470852/differences-between-ssh-keygen-private-keys-and-libressls and https://stackoverflow.com/questions/55733451/what-is-the-difference-between-rsa-private-key-with-headers-and-openssh-private and more


JWT or public-private keys for service to service API calls I'm looking into setting up authentication between two application services. Service A is going to call service B, and I want service B to only accept (http) calls from service A, nowhere else.

I know how JWT authentication works and could implement that. If I understand correctly (I think I do, but correct me if I'm wrong), it works like this:

service A requests a JWT from service B (or an identity server, but let's assume point-to-point)
service B responds with the JWT, signed with service B's secret
service A makes the call to service B and includes the JWT
service B inspects the JWT and can know if it was actually service A that made the call, without tampering with the JWT

But is the first call actually necessary? Couldn't I just do this:

service A signs every request with service A's private key
service B decrypts the request with service A's public key
service B now knows if the request is really from service A

I will be working over https, and have no need for claims. All I need to know is if the request originated from service A. Because only service A is allowed to call service B, but when it does, it has access to all API endpoints (so no claims necessary).

It seems simpler to use asymmetric encryption instead of JWT, but I wonder if it's as secure, correct and standard to do so.

The JWT was created to handle a wide range of situations (differentiated claims, separate identity server, many users, etc.). Your situation is fairly straight forward - you have only one client (A) that needs to communicate with one server (B).

You could handle this case with JWT if you want to, but there is no need too. It would indeed be overkill, since the JWT requires some form of authentication in the first step. And if you have to set that up, why not use it all the way through? The private-public key setup you suggest would work equally well. So unless you expect your requirements to change, I would go with the one that is simpler to implement.

Something very similar to your suggestion is actually already implemented in TLS, namely client authentication. In that setup, the client has to provide a certificate to the server for authentication. You might want to look into that.


Starting a new shell in a strcpy exploit using buffer overflow I'm learning about buffer overflows and have this vulnerable code which I'm trying to start a shell from:

#include <string.h>

void myfunction(char *arg);

int main(int argc, char **argv)
{
     myfunction(argv[1]);
     return 0;
}

void myfunction(char *arg)
{
    char stuff[8];
    strcpy(stuff, arg);
}

I used gdb to see the assembly code and I got the following info:

(gdb) disassemble main
Dump of assembler code for function main:
   0x08048434 <+0>:   push   %ebp
   0x08048435 <+1>:   mov    %esp,%ebp
   0x08048437 <+3>:   and    $0xfffffff0,%esp
   0x0804843a <+6>:   sub    $0x10,%esp
   0x0804843d <+9>:   mov    0xc(%ebp),%eax
   0x08048440 <+12>:  add    $0x4,%eax
   0x08048443 <+15>:  mov    (%eax),%eax
   0x08048445 <+17>:  mov    %eax,(%esp)
   0x08048448 <+20>:  call   0x8048454 <myfunction>
   0x0804844d <+25>:  mov    $0x0,%eax
   0x08048452 <+30>:  leave
   0x08048453 <+31>:  ret
End of assembler dump.

I'm unsure where to go from here. Any advice and walkthroughs would be very helpful.

First you need to know how program memory is organized. There are three areas:

Code section (you dumped this section)
Data section
Stack (the most interesting)

When main function calls myfunction, it pushes onto the stack in sequence return address into main and main's frame pointer. Then the space of 8 bytes size, needed for char array, is allocated on the stack.

When you copy more data into array than it's size, you first override main's frame pointer (4 bytes on 32-bit x86 architecture) and then you override return address (also 4 bytes). The fun part is overriding return address in such way that the return address will point to the beginning of the char array while filling this array with shell code. As the result, program executes array filled with your instructions.

The catch is that today's compilers adapt stack overflow protections by default. For learning purposed you can use simple tcc compiler instead of gcc. The former one doesn't protect against these kinds of overflows.

Finally, as a reference I recommend Open Security Training classes which can be found here: http://opensecuritytraining.info/Training.html. There's one called "Introduction to Software Exploits (Exploits 1)".


What should a verification email consist of? Right now I'm generating a 25 character string stored in the database that can only have a 1 time use and expires 30 minutes after user registration.

http://example.com/security/activate/ZheGgUNUFAbui4QJ48Ubs9Epd

I do a quick database lookup and the logic is as follows:

  If the account is not activated AND if the email was not verified AND the validation code is still valid, activate the account, mark the email address as verified and mark the validation code as used.

Every 72 hours for example it would flush expired and used validation codes.
This is in order to tell the user that the activation link clicked has expired for example if he look at his email the day after and try the link.

Should I include the user UUID in the url? Do I need to include something else?

I thought about making sure the IP address on the registration form match the IP address of the request when the activation link is pressed, but for me I mainly read my emails on my cellphone for this kind of stuff so it would be a pain for UX.

How are you generating the 25 character string which you include in the URL?  Is it completely random, or is it based off the current time, or the users email?  It should be random and not guessable.

You should make sure the verification page  actually renders (not just that a GET request occurred). Browsers such as chrome (and antivirus programs) often load URLs without the user explicitly clicking them as either a pre-fetch or to scan for security reasons.

That could result in a scenario where a malicious actor (Eve) wants to make an account using someone else's email (Alice).
Eve signs up, and Alice received an email. Alice opens the email because she is curious about an account she didn't request. Her browser (or antivirus) requests the URL in the background, inadvertently activating the account.

I would use JavaScript on the page to verify the page actually rendered, and also include a link in the email where users can report that they did NOT create this account.


Check photos for geotagging and remove lat/long data I like to upload photos to various internet services, but I prefer not to share my geographic location.  I understand Facebook and other services strip out the geolocation data, but they still have the data.  I want to keep that data to myself and not share geolocation.

What are some tools that can find if geolocation data exists in a photo?

Is there a way I can manually strip this data from my photos?

I have used exiftool for this kind of work. It basicly lets you review and edit any meta information in your pictures.

I used this to exploit a image service which echoed the geo details back at the user. I filled the images geo data with XSS and attacked other users viewing the picture.


Can webpages recognize that I saved my password? If you save your logins in Firefox, username and password are auto-filled-in in corresponding webpages as soon as you visit them (if you have more than 1 account saved, you'd have to select a username first).

Can webpages check with JavaScript if the login fields are not empty (without submitting the form)?

I guess usually this would be possible, I saw that for live form validation. But maybe this auto-filled-in data follows other rules than user-filled-in data?

Javascript can read password dialogs just like any other field:

document.getElementsByName("passwordentry")[0].value

so you can certainly have a piece of javascript that checks if the password field has been filled in much faster than humanly possible, as long as the user has javascript enabled..

You may want to implement a proof-of-concept to see how effective this is in practice and if there are any unforseen difficulties come up. edit A very important point by @Stephen Touset is that there are many different types of automatic password entry. It is important to be aware of them to detect them all.


How to stop app from fetching data from my website? I am running a website that contains data that our users can access if they login.

Someone else has created an Android app that lets users access that data as well. They enter their credentials, and the app then connects to another website. This website logs into and fetches the data from our website, using AJAX requests (I quess).

How can I restrict access to our website so that this app no longer works? Will Access-Conrol-Allo-Origin on Same-Origin help? Or maybe an X-Requested-With header? Perhaps domain restriction or some other mitigation?

If some server backend for the app is sending the requests

As I understand it, the requests that fetch data from your website are comming from a server that works as a backend for the offending Android app. You have a number of possibilities:

Block the IP of the server. This may end up being a cat and mouse game if they change the IP, so not the greatest of solutions.
Rate limit on IP. The server will be making loads of requests per hour, so you could probably set a limit what would not affect ordinary users.  I would say that this is the most promising solution.
Limit how many active sessions there can be for the same IP. Note that there are legitimite cases where you have more than one session on the same IP, such as multiple users logged in from the same corporate network.
You could check that the User-Agent looks like a browser. Easy to circumvent, but much like a fence does not keep a thief out it still clearly demonstrate where the property line is.
If your website is more of an API, you could use some other custom HTTP header that valid requests must use. Same limitations as the above point, though.

Access-Control-Allow-Origin and similar is of no use here, since they regulate what requests browsers are allowed to make. It's not relevant when a server is making the request.

If a browser, or something following SOP, is sending the request

The same origin policy prevents sites on one origin to read the responses from requests to another origin, unless the server the request is directed at has been explicitly configured to allow this (via CORS).

Your website is one origin, whatever the browser in the app is displaying is another origin. So this should be blocked by default.

If the app is sending the requests

If this is the case, you are in trouble. You could try the last two bullet points from above (User-Agent or custom HTTP header), but they can be easily circumvented. So you might be out of luck here.


Schneier is telling me to write my bank security password and keep it in my wallet? Is that right? Bruce Schneier Writes Down Passwords. So Can You

  ...

  But how should people deal with all of this in the real world, or on line? "Relax," he says emphatically. Surprisingly for a security professional, he has a very easy-going view on passwords.

  "I have some very secure passwords for things that matter -- like
  online banking", he says. "But then I use the same password for all
  sorts of sites that don't matter. People say you shouldn't use the
  same password. That is wrong.

  And when people say don't write your password down. Nonsense. Write it
  down on a little piece of paper and keep it with all the other small
  bits of paper you value -- in your wallet."

  He opens his wallet and pulls out a £20 note. "This has value. Your
  password has value. As a society we are good at valuing small bits of
  paper. We have cracked that problem."

  https://www.schneier.com/news/archives/2010/11/bruce_schneier_write.html

I understand where this is coming from.  It's very easy to find security "advice" that is impractically hard ("everyone should stop using Windows" :-P).  Therefore it is necessary to engage in a little critical thinking.  Otherwise, in practice you will end up skipping a more important security precaution because you are not working from the right priorities.  Or suffer excessive costs in trade-off - possibly including loss of availability due to forgetting a password.

The problem is I am very literal.  I am trying to think critically about how to safely remember the passwords for my multiple online bank accounts.  A literal interpretation of the linked article is:

Write the security password(s) for your online banking on a piece of paper, and put it in your wallet along with your debit card.

My critical thinking is extremely suspicious of this, because

My current account allows me to log in online using my debit card number.
I have been known to lose a wallet.  Or two.

My current account T&C's say that you are liable for any fraud if you "didn’t take reasonable steps to keep your payment details safe".  I suspect they would not be sympathetic to an argument that I was simply following the advice from a renowned security expert's web page :-).

It feels like an odd comparison.  The expected contents of a wallet can indeed be valuable.  But I'm not as worried about card theft, partly because it's secured by a short PIN.  And one typically only carries a limited amount of cash, compared to the amount held in a bank account.

So.  Where are the weak points in all of the above?

Why did the high reputation security expert say this, and confirm it by reposting it on their own website, without further comment?
Have I made a literal-level error in my interpretation?
Is the literal interpretation actually not a bad idea, and if so why?
Is there something particularly unusual about my own situation?
Should I consider that the "News" tab of schneier.com (distinct from the "Blog" tab) cannot be trusted in the same way as the rest of the site?  I.e. could this be Schneier re-posting a news article that favoured him, without reviewing the post for the implication of rather bad ideas?

I think it is bad advice. I want to break the answer down in two sections, namely using the same password on multiple sites as well as your original question about storing a password on a piece of paper in your wallet.

Thoughts about storing passwords on paper (and in your wallet)
As of today there are multiple good password managers which are better then the alternatives out there, such as writing a password down on paper. Troy Hunt actually made a really good blog post about this subject. In general it is considered a bad security practice to write down passwords, because of several risks involved:

You can lose the paper with your password on it, this would mean you lose access to that password but also someone else might be able to use it depending on where you lose it;
Someone might be able to use the password when he steals the piece of paper or when he can take a look at it, similar to shoulder surfing.

When you take into consideration people (including you as I can tell by your question) losing their wallet with both the password and banking details from a credit card or banking card, I would consider this a critical risk to your finance and personal data in general. A wallet is not made to secure money, it is meant as storage. The same principles should be applied to using it to secure your password.

Thoughts about using the same password on multiple sites
It is also not considered a good security practice to use the same password on multiple sites because of credential stuffing. Even if the sites are not important to you, the data the website has about you might be interesting to others. Combining personal data can also be very powerful for someone who wants to do harm to you.

I don't think Bruce Schneier means he uses the same password he uses on multiple sites for his banking account, because that would be outright ridiculous. I do however still think the above applies to 'non important websites'. You also have to take into consideration that Bruce Schneier is a security professional and is well aware of potential risks in certain services. People who are not so aware might not consider their email an important service for example, yet it most of the time holds the access to a lot of other websites because of the Forgot your password feature on a lot of websites.

The same applies to storing your password on paper. Bruce Schneier is a security professional and can take certain risks because he is aware of the potential damage and can actually make well informed choices. Writing passwords down on paper should be considered a bad security practice for most people, keeping the paper in your wallet included.

Therefor I do not agree with the advice for Bruce Schneier and to answer all of your questions:

  Where are the weak points in all of the above?

I answered this in the details above here, both storing passwords on paper as using the same passwords should be considered weak points.

  Why did the high reputation security expert say this, and confirm it
  by reposting it on their own website, without further comment?

Because not everyone has the same opinion, clearly he has a different believe when it comes to passwords. That is alright, as long as we all have the debate we're having on this question: What should be considered a good security practice today.

  Have I made a literal-level error in my interpretation?

I don't think you have.

  Is the literal interpretation actually not a bad idea, and if so why?

Just as with password managers, if writing down your password on paper is a better (but not perfect) practice then not storing on paper, by all means, go ahead. For example, if the alternative is using a weak password on every single service including your banking account, writing a secure different password on paper and storing it in your wallet might actually be a good idea. However using a password manager would be even better.

  Is there something particularly unusual about my own situation?

No, I lose my wallet all the time and being a critical thinker, especially when it comes down to security, is a good habit.

  Should I consider that the "News" tab of schneier.com (distinct from
  the "Blog" tab) cannot be trusted in the same way as the rest of the
  site? I.e. could this be Schneier re-posting a news article that
  favoured him, without reviewing the post for the implication of rather
  bad ideas?

I don't think you should necessarily, but that of course is up to you. Bruce Schneier also has good advice and he is still well known and widely respected. Re-posts on a website like this should be more trustworthy then some other sources, but always, like you did now, be criticizing articles to see if it is trustworthy. So yes, this could have been a re-post without reviewing the implications, although I do believe this is not just your job: It is the job of the re-poster, in this case Bruce Schneier.


Is it safe to reveal AES encrypted password? Please correct me if any of my statement is incorrect.

It is probably more good practice to not show any hint of the password.

However, AES encrypted passwords by itself cannot be used to decrypt the password or find the key; known-plaintext attack does not work with AES. This means that revealing the encrypted password doesn't really hurt anything.

So, is it safe to reveal AES encrypted passwords in web applications?

Main answer

In summary, you are completely right with your first assumption:

  It is probably more good practice to not show any hint of the password.

There are a few issues with the rest of your question though:

You do not want to encrypt passwords.

Usually, that is, at least.

schroeder rightfully asks in the comments

  Side question: why are passwords encrypted and not hashed?

Thing is: If you encrypt the passwords instead of hashing them, you can always decrypt them and use them. Usually, the key for decryption has to be somewhere in the application for the data to be of any use.

Hence, if someone stole your application's data - which isn't that uncommon (and the usual reason for credentials to show up on haveibeenpwned) - that someone has all passwords in clear text.

Thus, you usually want to hash passwords - there are well received Q&As here on how that works.
You do not want to use plain AES

If you use plain AES, the same password encrypts to the same ciphertext.

If someone has access to all ciphertexts, statistical analysis is likely to give away the plain text of at least one ciphertext - and all accounts with that password are automatically breached.

An example: If you know the most often used password is cucumber, you go ahead and look for the most often appearing ciphertext - the plain text is likely to be cucumber.

Also, this restricts your users' passwords to the block size. This might be not what you (or your users) want.
You do want to give away as little information as you possibly can.

Even publicly listing proper hashes of user passwords would be a pretty bad idea, as - again - schroeder already put in the comments:

  Another question: what do you mean by "safe"? It is possible to brute-force the decryption of an encrypted string.

Encrypting passwords is basically a plain text offense, according to Plain text offenders' FAQ

  But the site says they store my password securely using [something]!

  Your password is yours. It is the means by which you identify yourself to a site. If a site can tell what your password is after you gave it to them, anyone can know what your password is (hackers, disgruntled employees, people stumbling onto it by accident, etc.).

Side Note

While AES with a reasonable mode of operation is not vulnerable to known plaintext attacks (I think what you had in mind was "I know my password, I can extrapolate the key and know all passwords"), using plain AES will, as said before, increase the chances of an attacker to win in a CPA model.

Which is basically what you have, given that a user can change his/her password.


Recovering From Suspected MPEG Malware Attack Against my better judgement I foolishly opened an MPEG video emailed to me from a friend's email address because the topic in the email was something we had recently discussed.

I am fairly certain that the MPEG was malware as it only opened Media Player long enough to do some kind of exploit and then closed. Shortly afterwards the Windows Explorer window containing the file closed.

I immediately swore, switched off the PC and disconnected it from the Network and Internet. I then disconnected the SSD D: drive that the MPEG file was saved to and restarted the PC. I ran a full Windows Defender scan and cleared out the Windows temp files.

I suspect that the D: drive has been compromised by a scripting attack and perhaps been encrypted? I have not checked to see if I can access the D drive for fear of making matters worse.

Does my analysis sound correct?

How should I recover from this? Is there some way I can format the D: drive without compromising my system?

Any help will be gratefully received.

Thanks,

Mike

If you can access the D drive after booting from your boot disc (which is different from booting into safe mode), then it will be reasonably isolated to scan everything using multiple virus, rootkit, and malware scanners.  The only vulnerabilities you will be exposing your system to at that point, it has already experienced.

You can just format the D drive at that time as well.  If you want to be extra cautious you can use a format parameter (such as /P:1 or /P:3) that will overwrite most of the sectors on drive D, but that will take a fair amount of time to run.