I dug into this a bit. I don't plan on working on it, I just figured I'd report my findings.

vnc password="" lets the user auth with an empty password. spice password="" will give a password prompt but not accept _any_ password, effectively blocking usage of the viewer. The spice behavior is the semantics documented in qemu.conf, so the vnc_password docs are presently wrong

VNC password support added to libvirt, presumably with the qemu.conf semantics intact:

commit 38017949080674d65d580905dbe88ca3685a93cd
Author: Daniel P. Berrange <berrange>
Date:   Thu Jan 29 17:50:00 2009 +0000

    Support VNC password setting in QEMU driver


Not long after, the vnc password="" behavior is broken in qemu 0.12.0. password="" fully turns off password auth, so not even a prompt:

commit 52c18be9e99dabe295321153fda7fce9f76647ac
Author: Zachary Amsden <zamsden>
Date:   Thu Jul 30 00:15:01 2009 -1000

    When using stdio monitor and VNC display, one can set or clear a VNC password; this should set or turn off VNC authentication as well.


Eventually people notice, https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/697197 is filed that libvirt's documented behavior is wrong. This turns into the qemu 0.14.0 commit:

    commit 1cd20f8bf0ecb9d1d1bd5e2ffab3b88835380c9b
    Author: Anthony Liguori <aliguori.com>
    Date:   Mon Jan 31 14:27:36 2011 -0600

        vnc: Fix password expiration through 'change vnc ""' (v2)

So that revived the old behavior of the monitor command: change vnc password "" . However also in 0.14.0 the set_password command was added (which has more options and works for spice too).

The set_password command deliberately does _not_ have the documented semantics for VNC: password="" is treated as an empty string password. The commit suggests adding a new command to handle blocking password access entirely rather than overloading things.

Confusingly enough, set_password for spice with password="" _does_ keep the libvirt documented semantics :) Spice may just not allow empty string passwords though, I didn't investigate

Eventually libvirt grows qmp support, and the only command converted to qmp is set_password, whose semantics haven't changed to this day. So any qemu that libvirt uses qmp with will show this bug.

I think all the bits are inplace to fix it though using the expire_time monitor command which libvirt already supports. 'expire_time now' looks like it gives the expected semantics of showing a password dialog but no passwords are considered valid. I haven't actually tested it though.

*** Bug 969542 has been marked as a duplicate of this bug. ***

This issue is now fixed upstream by v2.0.0-rc2-3-gbb848fe:

commit bb848feec0f3f10e92dd8e5231ae7aa89b5598f3
Author:     Jiri Denemark <jdenemar>
AuthorDate: Tue Jun 28 14:39:58 2016 +0200
Commit:     Jiri Denemark <jdenemar>
CommitDate: Thu Jun 30 10:20:44 2016 +0200

    qemu: Let empty default VNC password work as documented
    
    CVE-2016-5008
    
    Setting an empty graphics password is documented as a way to disable
    VNC/SPICE access, but QEMU does not always behaves like that. VNC would
    happily accept the empty password. Let's enforce the behavior by setting
    password expiration to "now".
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1180092
    
    Signed-off-by: Jiri Denemark <jdenemar>

Reproduce this bug with libvirt-1.2.17-13.el7_2.5.x86_64. 
steps and results are as comment 0.

Verify this bug with libvirt-2.0.0-1.el7.x86_64.
Steps to Verify:

 1. Define a guest with vnc graphics device like:
    .........................................
      <graphics type='vnc' port='-1' autoport='yes' listen='0.0.0.0' passwd=''>
      <listen type='address' address='0.0.0.0'/>
    </graphics>
    .........................................

 2. Start guest, and connect with virt-viewer .
#virsh start testvm
Domain testvm started
#virsh dumpxml testvm --security-info  |grep graphics -A2
     <graphics type='vnc' port='5901' autoport='yes' listen='0.0.0.0' passwd=''>
      <listen type='address' address='0.0.0.0'/>
    </graphics>

#virt-viewer testvm
open the window without input any password, just click "OK" button, guest can not be login, with following error occurred"
"Unable to authenticate with remote desktop server at localhost:5901: Authentication failed
Retry connection again?"

 3. The problem can also be tested when change the graphics passwd from a non-empty to an empty.
    # virsh dumpxml testvm --security-info |grep graphics -A 2
    <graphics type='vnc' port='5900' autoport='yes' listen='0.0.0.0' passwd='123'>
      <listen type='address' address='0.0.0.0'/>
    </graphics>
(can login guest with passwd 123 now.)

    # cat change-passwd.xml
    <graphics type='vnc' port='-1' autoport='yes'  listen='0.0.0.0' passwd=''/>

    # virsh update-device testvm change-passwd.xml
   Device updated successfully

    # virsh dumpxml testvm --security-info  |grep graphics -A 2
    <graphics type='vnc' port='5900' autoport='yes' listen='0.0.0.0' passwd=''>
      <listen type='address' address='0.0.0.0'/>
    </graphics>

    # virt-viewer testvm
    can not connect the guest with empty password either.

4.retest step 1-3 when configure guest with
# virsh dumpxml testvm --security-info  |grep graphics -A 2
    <graphics type='spice' port='5900' autoport='yes' listen='0.0.0.0' passwd=''>
      <listen type='address' address='0.0.0.0'/>
    </graphics>

5.start guest and connect with virt-viewer failed
# virt-viewer testvm
open the window without input any password, just click "OK" button, guest can not be login successfully, an error pop-up with "Unable to authenticate with remote desktop server: Invalid password".

try with different password value, such as "NULL, null, none, blank, 'space' key " all failed.

6. when update spice graphics password from non-empty to empty, guest can not be login either.

Since the result is as expected, mark this bug verified.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2016-2577.html