From the RFC:
(c) The MD5 authentication algorithm is run over the
concatenation of the OSPF packet, secret key, pad
and length fields, producing a 16 byte message
digest (see [Ref17]).
To answer your question directly, this is expected behavior by OSPF and not a bug in Quagga.
So first, let's take a look at the DR/BDR section of the RFC.
Designated Router
The Designated Router selected for the attached network. The
Designated Router is selected on all broadcast and NBMA networks
by the Hello Protocol. Two pieces of identification are kept
for the Designated Router: its Router ID and its IP interface
address on the network. The Designated Router advertises link
state for the network; this network-LSA is labelled with the
Designated Router's IP address. The Designated Router is
initialized to 0.0.0.0, which indicates the lack of a Designated
Router.
Backup Designated Router
The Backup Designated Router is also selected on all broadcast
and NBMA networks by the Hello Protocol. All routers on the
attached network become adjacent to both the Designated Router
and the Backup Designated Router. The Backup Designated Router
becomes Designated Router when the current Designated Router
fails. The Backup Designated Router is initialized to 0.0.0.0,
indicating the lack of a Backup Designated Router.
If the BDR field in the Hello packet header is set to 0.0.0.0, it means you do not have a BDR elected.
In your case this is because you have your other router set to a priority of 0, this makes the router ineligible to become a BDR (this is why you see "DROther" and not "BDR"). You just need to set the priority on your other router to something that isn't 0.
Here is the other piece from the RFC for some more context.
Router Priority
An 8-bit unsigned integer. When two routers attached to a
network both attempt to become Designated Router, the one with
the highest Router Priority takes precedence. A router whose
Router Priority is set to 0 is ineligible to become Designated
Router on the attached network. Advertised in Hello packets
sent out this interface.
https://www.ietf.org/rfc/rfc2328.txt
Best Answer
Short answer: No, not with OSPF alone
Long answer:
The only way for OSPF to dynamically calculate paths based on latency / congestion is to use MPLS Traffic Engineering with offline optimizations of MPLS TE costs based on your criteria; MPLS TE uses OSPF LSAs to carry information about the label switched paths. However, MPLS Traffic Engineering is a heavy hammer and many network operations can't deal with the additional workflow introduced into provisioning or troubleshooting MPLS TE.
Another answer suggests that you should not adjust link costs based on bandwidth, and to use the role of a node for costs. I can't speak for his network, but this guidance is unnecessary in many cases since the lowest cost path in a well-designed topology automatically follows through the core of the network. I wouldn't try to adjust an inefficient topology with link costs... just make traffic flow through the core naturally and ensure that OSPF sees a 1GE as a better path than a FastEthernet link. This will naturally happen if you lay out the topology well, and use auto-cost reference-bandwidth under the OSPF process. Be sure you use this on all OSPF routers so they understand the link costs in the same way.