text:
|Network Working Group
|J. Franks
|Request for Comments: 2617
|Northwestern University, Department of Mathematics
|Obsoletes: 2069
|P. Hallam-Baker
|Category: Standards Track
|Verisign Inc.
|J. Hostetler
|AbiSource, Inc.
|S. Lawrence
|Agranat Systems, Inc.
|P. Leach
|Microsoft Corporation
|A. Luotonen
|Netscape Communications Corporation
|L. Stewart
|Open Market, Inc.
|June 1999
HTTP Authentication: Basic and Digest Access Authentication
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
Copyright © The Internet Society (1999). All Rights Reserved.
"HTTP/1.0", includes the specification for a Basic Access Authentication scheme. This scheme is not considered to be a secure method of user authentication (unless used in conjunction with some external secure system such as SSL [5]), as the user name and password are passed over the network as cleartext.
This document also provides the specification for HTTP's authentication framework, the original Basic authentication scheme and a scheme based on cryptographic hashes, referred to as "Digest Access Authentication". It is therefore also intended to serve as a replacement for RFC 2069 [6]. Some optional elements specified by RFC 2069 have been removed from this specification due to problems found since its publication; other new elements have been added for compatibility, those new elements have been made optional, but are strongly recommended.
Like Basic, Digest access authentication verifies that both parties to a communication know a shared secret (a password); unlike Basic, this verification can be done without sending the password in the clear, which is Basic's biggest weakness. As with most other authentication protocols, the greatest sources of risks are usually found not in the core protocol itself but in policies and procedures surrounding its use.
This specification is a companion to the HTTP/1.1 specification [2]. It uses the augmented BNF section 2.1 of that document, and relies on both the non-terminals defined in that document and other aspects of the HTTP/1.1 specification.
HTTP provides a simple challenge-response authentication mechanism that MAY be used by a server to challenge a client request and by a client to provide authentication information. It uses an extensible, case-insensitive token to identify the authentication scheme, followed by a comma-separated list of attribute-value pairs which carry the parameters necessary for achieving authentication via that scheme.
auth-scheme = token auth-param = token "=" ( token | quoted-string )
The 401 (Unauthorized) response message is used by an origin server to challenge the authorization of a user agent. This response MUST include a WWW-Authenticate header field containing at least one challenge applicable to the requested resource. The 407 (Proxy Authentication Required) response message is used by a proxy to challenge the authorization of a client and MUST include a Proxy-Authenticate header field containing at least one challenge applicable to the proxy for the requested resource.
challenge = auth-scheme 1*SP 1#auth-param
Note: User agents will need to take special care in parsing the WWW-Authenticate or Proxy-Authenticate header field value if it contains more than one challenge, or if more than one WWW-Authenticate header field is provided, since the contents of a challenge may itself contain a comma-separated list of authentication parameters.
The authentication parameter realm is defined for all authentication schemes:
realm = "realm" "=" realm-value realm-value = quoted-string
The realm directive (case-insensitive) is required for all authentication schemes that issue a challenge. The realm value (case-sensitive), in combination with the canonical root URL (the absoluteURI for the server whose abs_path is empty; see section 5.1.2 of [2]) of the server being accessed, defines the protection space. These realms allow the protected resources on a server to be partitioned into a set of protection spaces, each with its own authentication scheme and/or authorization database. The realm value is a string, generally assigned by the origin server, which may have additional semantics specific to the authentication scheme. Note that there may be multiple challenges with the same auth-scheme but different realms.
A user agent that wishes to authenticate itself with an origin server--usually, but not necessarily, after receiving a 401 (Unauthorized)--MAY do so by including an Authorization header field with the request. A client that wishes to authenticate itself with a proxy--usually, but not necessarily, after receiving a 407 (Proxy Authentication Required)--MAY do so by including a Proxy-Authorization header field with the request. Both the Authorization field value and the Proxy-Authorization field value consist of credentials containing the authentication information of the client for the realm of the resource being requested. The user agent MUST choose to use one of the challenges with the strongest auth-scheme it understands and request credentials from the user based upon that challenge.
credentials = auth-scheme #auth-param
The protection space determines the domain over which credentials can be automatically applied. If a prior request has been authorized, the same credentials MAY be reused for all other requests within that protection space for a period of time determined by the authentication scheme, parameters, and/or user preference. Unless otherwise defined by the authentication scheme, a single protection space cannot extend outside the scope of its server.
If the origin server does not wish to accept the credentials sent with a request, it SHOULD return a 401 (Unauthorized) response. The response MUST include a WWW-Authenticate header field containing at least one (possibly new) challenge applicable to the requested resource. If a proxy does not accept the credentials sent with a request, it SHOULD return a 407 (Proxy Authentication Required). The response MUST include a Proxy-Authenticate header field containing a (possibly new) challenge applicable to the proxy for the requested resource.
The HTTP protocol does not restrict applications to this simple challenge-response mechanism for access authentication. Additional mechanisms MAY be used, such as encryption at the transport level or via message encapsulation, and with additional header fields specifying authentication information. However, these additional mechanisms are not defined by this specification.
Proxies MUST be completely transparent regarding user agent authentication by origin servers. That is, they must forward the WWW-Authenticate and Authorization headers untouched, and follow the rules found in section 14.8 of [2]. Both the Proxy-Authenticate and the Proxy-Authorization header fields are hop-by-hop headers (see section 13.5.1 of [2]).
The "basic" authentication scheme is based on the model that the client must authenticate itself with a user-ID and a password for each realm. The realm value should be considered an opaque string which can only be compared for equality with other realms on that server. The server will service the request only if it can validate the user-ID and password for the protection space of the Request-URI. There are no optional authentication parameters.
For Basic, the framework above is utilized as follows:
challenge = "Basic" realm credentials = "Basic" basic-credentials
Upon receipt of an unauthorized request for a URI within the protection space, the origin server MAY respond with a challenge like the following:
WWW-Authenticate: Basic realm="WallyWorld"
where "WallyWorld" is the string assigned by the server to identify the protection space of the Request-URI. A proxy may respond with the same challenge using the Proxy-Authenticate header field.
To receive authorization, the client sends the userid and password, separated by a single colon (":") character, within a base64 [7] encoded string in the credentials.
basic-credentials = base64-user-pass base64-user-pass = <base64 [4] encoding of user-pass, except not limited to 76 char/line> user-pass = userid ":" password userid = *<TEXT excluding ":"> password = *TEXT
Userids might be case sensitive.
If the user agent wishes to send the userid "Aladdin" and password "open sesame", it would use the following header field:
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
A client SHOULD assume that all paths at or deeper than the depth of the last symbolic element in the path field of the Request-URI also are within the protection space specified by the Basic realm value of the current challenge. A client MAY preemptively send the corresponding Authorization header with requests for resources in that space without receipt of another challenge from the server. Similarly, when a client sends a request to a proxy, it may reuse a userid and password in the Proxy-Authorization header field without receiving another challenge from the proxy server. See Section 4 for security considerations associated with Basic authentication.
The protocol referred to as "HTTP/1.0" includes the specification for a Basic Access Authentication scheme[1]. That scheme is not considered to be a secure method of user authentication, as the user name and password are passed over the network in an unencrypted form. This section provides the specification for a scheme that does not send the password in cleartext, referred to as "Digest Access Authentication".
The Digest Access Authentication scheme is not intended to be a complete answer to the need for security in the World Wide Web. This scheme provides no encryption of message content. The intent is simply to create an access authentication method that avoids the most serious flaws of Basic authentication.
Like Basic Access Authentication, the Digest scheme is based on a simple challenge-response paradigm. The Digest scheme challenges using a nonce value. A valid response contains a checksum (by default, the MD5 checksum) of the username, the password, the given nonce value, the HTTP method, and the requested URI. In this way, the password is never sent in the clear. Just as with the Basic scheme, the username and password must be prearranged in some fashion not addressed by this document.
An optional header allows the server to specify the algorithm used to create the checksum or digest. By default the MD5 algorithm is used and that is the only algorithm described in this document.
For the purposes of this document, an MD5 digest of 128 bits is represented as 32 ASCII printable characters. The bits in the 128 bit digest are converted from most significant to least significant bit, four bits at a time to their ASCII presentation as follows. Each four bits is represented by its familiar hexadecimal notation from the characters 0123456789abcdef. That is, binary 0000 gets represented by the character '0', 0001, by '1', and so on up to the representation of 1111 as 'f'.
The Digest authentication scheme described in this document suffers from many known limitations. It is intended as a replacement for Basic authentication and nothing more. It is a password-based system and (on the server side) suffers from all the same problems of any password system. In particular, no provision is made in this protocol for the initial secure arrangement between user and server to establish the user's password.
Users and implementors should be aware that this protocol is not as secure as Kerberos, and not as secure as any client-side private-key scheme. Nevertheless it is better than nothing, better than what is commonly used with telnet and ftp, and better than Basic authentication.
The Digest Access Authentication scheme is conceptually similar to the Basic scheme. The formats of the modified WWW-Authenticate header line and the Authorization header line are specified below. In addition, a new header, Authentication-Info, is specified.
If a server receives a request for an access-protected object, and an acceptable Authorization header is not sent, the server responds with a "401 Unauthorized" status code, and a WWW-Authenticate header as per the framework defined above, which for the digest scheme is utilized as follows:
challenge = "Digest" digest-challenge digest-challenge = 1#( realm | [ domain ] | nonce | [ opaque ] |[ stale ] | [ algorithm ] | [ qop-options ] | [auth-param] ) domain = "domain" "=" <"> URI ( 1*SP URI ) <"> URI = absoluteURI | abs_path nonce = "nonce" "=" nonce-value nonce-value = quoted-string opaque = "opaque" "=" quoted-string stale = "stale" "=" ( "true" | "false" ) algorithm = "algorithm" "=" ( "MD5" | "MD5-sess" | token ) qop-options = "qop" "=" <"> 1#qop-value <"> qop-value = "auth" | "auth-int" | token
The meanings of the values of the directives used above are as follows:
time-stamp H(time-stamp ":" ETag ":" private-key)
H(data) = MD5(data)
KD(secret, data) = H(concat(secret, ":", data))
The client is expected to retry the request, passing an Authorization header line, which is defined according to the framework above, utilized as follows.
credentials = "Digest" digest-response digest-response = 1#( username | realm | nonce | digest-uri | response | [ algorithm ] | [cnonce] | [opaque] | [message-qop] | [nonce-count] | [auth-param] ) username = "username" "=" username-value username-value = quoted-string digest-uri = "uri" "=" digest-uri-value digest-uri-value = request-uri ; As specified by HTTP/1.1 message-qop = "qop" "=" qop-value cnonce = "cnonce" "=" cnonce-value cnonce-value = nonce-value nonce-count = "nc" "=" nc-value nc-value = 8LHEX response = "response" "=" request-digest request-digest = <"> 32LHEX <"> LHEX = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" | "a" | "b" | "c" | "d" | "e" | "f"
The values of the opaque and algorithm fields must be those supplied in the WWW-Authenticate response header for the entity being requested.
If a directive or its value is improper, or required directives are missing, the proper response is 400 Bad Request. If the request-digest is invalid, then a login failure should be logged, since repeated login failures from a single client may indicate an attacker attempting to guess passwords.
The definition of request-digest above indicates the encoding for its value. The following definitions show how the value is computed.
If the "qop" value is "auth" or "auth-int":
request-digest = <"> < KD ( H(A1), unq(nonce-value) ":" nc-value ":" unq(cnonce-value) ":" unq(qop-value) ":" H(A2) ) <">
If the "qop" directive is not present (this construction is for compatibility with RFC 2069):
request-digest = <"> < KD ( H(A1), unq(nonce-value) ":" H(A2) ) > <">
See below for the definitions for A1 and A2.
If the "algorithm" directive's value is "MD5" or is unspecified, then A1 is:
A1 = unq(username-value) ":" unq(realm-value) ":" passwd
passwd = < user's password >
If the "algorithm" directive's value is "MD5-sess", then A1 is calculated only once - on the first request by the client following receipt of a WWW-Authenticate challenge from the server. It uses the server nonce from that challenge, and the first client nonce value to construct A1 as follows:
A1 = H( unq(username-value) ":" unq(realm-value) ":" passwd ) ":" unq(nonce-value) ":" unq(cnonce-value)
This creates a 'session key' for the authentication of subsequent requests and responses which is different for each "authentication session", thus limiting the amount of material hashed with any one key. (Note: see further discussion of the authentication session in Section 3.3) Because the server need only use the hash of the user credentials in order to create the A1 value, this construction could be used in conjunction with a third party authentication service so that the web server would not need the actual password value. The specification of such a protocol is beyond the scope of this specification.
If the "qop" directive's value is "auth" or is unspecified, then A2 is:
A2 = Method ":" digest-uri-value
If the "qop" value is "auth-int", then A2 is:
A2 = Method ":" digest-uri-value ":" H(entity-body)
Note that the value of many of the directives, such as "username-value", are defined as a "quoted-string". However, the "unq" notation indicates that surrounding quotation marks are removed in forming the string A1. Thus if the Authorization header includes the fields
username="Mufasa", firstname.lastname@example.com
and the user Mufasa has password "Circle Of Life" then H(A1) would be H(Mufasa:email@example.com:Circle Of Life) with no quotation marks in the digested string.
No white space is allowed in any of the strings to which the digest function H() is applied unless that white space exists in the quoted strings or entity body whose contents make up the string to be digested. For example, the string A1 illustrated above must be
Mufasa:email@example.com:Circle Of Life
with no white space on either side of the colons, but with the white space between the words used in the password value. Likewise, the other strings digested by H() must not have white space on either side of the colons which delimit their fields unless that white space was in the quoted strings or entity body being digested.
Also note that if integrity protection is applied (qop=auth-int), the H(entity-body) is the hash of the entity body, not the message body - it is computed before any transfer encoding is applied by the sender and after it has been removed by the recipient. Note that this includes multipart boundaries and embedded headers in each part of any multipart content-type.
The "Method" value is the HTTP request method as specified in section 5.1.1 of [2]. The "request-uri" value is the Request-URI from the request line as specified in section 5.1.2 of [2]. This may be "*", an "absoluteURL" or an "abs_path" as specified in section 5.1.2 of [2], but it MUST agree with the Request-URI. In particular, it MUST be an "absoluteURL" if the Request-URI is an "absoluteURL". The "cnonce-value" is an optional client-chosen value whose purpose is to foil chosen plaintext attacks.
The authenticating server must assure that the resource designated by the "uri" directive is the same as the resource specified in the Request-Line; if they are not, the server SHOULD return a 400 Bad Request error. (Since this may be a symptom of an attack, server implementers may want to consider logging such errors.) The purpose of duplicating information from the request URL in this field is to deal with the possibility that an intermediate proxy may alter the client's Request-Line. This altered (but presumably semantically equivalent) request would not result in the same digest as that calculated by the client.
Implementers should be aware of how authenticated transactions interact with shared caches. The HTTP/1.1 protocol specifies that when a shared cache (see section 13.7 of [2]) has received a request containing an Authorization header and a response from relaying that request, it MUST NOT return that response as a reply to any other request, unless one of two Cache-Control (see section 14.9 of [2]) directives was present in the response. If the original response included the "must-revalidate" Cache-Control directive, the cache MAY use the entity of that response in replying to a subsequent request, but MUST first revalidate it with the origin server, using the request headers from the new request to allow the origin server to authenticate the new request. Alternatively, if the original response included the "public" Cache-Control directive, the response entity MAY be returned in reply to any subsequent request.
The Authentication-Info header is used by the server to communicate some information regarding the successful authentication in the response.
AuthenticationInfo = "Authentication-Info" ":" auth-info auth-info = 1#(nextnonce | [ message-qop ] | [ response-auth ] | [ cnonce ] | [nonce-count] ) nextnonce = "nextnonce" "=" nonce-value response-auth = "rspauth" "=" response-digest response-digest = <"> *LHEX <">
The value of the nextnonce directive is the nonce the server wishes the client to use for a future authentication response. The server may send the Authentication-Info header with a nextnonce field as a means of implementing one-time or otherwise changing nonces. If the nextnonce field is present the client SHOULD use it when constructing the Authorization header for its next request. Failure of the client to do so may result in a request to re-authenticate from the server with the "stale=TRUE".
The optional response digest in the "response-auth" directive supports mutual authentication -- the server proves that it knows the user's secret, and with qop=auth-int also provides limited integrity protection of the response. The "response-digest" value is calculated as for the "request-digest" in the Authorization header, except that if "qop=auth" or is not specified in the Authorization header for the request, A2 is
A2 = ":" digest-uri-value
and if "qop=auth-int", then A2 is
A2 = ":" digest-uri-value ":" H(entity-body)
where "digest-uri-value" is the value of the "uri" directive on the Authorization header in the request. The "cnonce-value" and "nc-value" MUST be the ones for the client request to which this message is the response. The "response-auth", "cnonce", and "nonce-count" directives MUST BE present if "qop=auth" or "qop=auth-int" is specified.
The Authentication-Info header is allowed in the trailer of an HTTP message transferred via chunked transfer-coding.
Upon receiving the Authorization header, the server may check its validity by looking up the password that corresponds to the submitted username. Then, the server must perform the same digest operation (e.g., MD5) performed by the client, and compare the result to the given request-digest value.
Note that the HTTP server does not actually need to know the user's cleartext password. As long as H(A1) is available to the server, the validity of an Authorization header may be verified.
The client response to a WWW-Authenticate challenge for a protection space starts an authentication session with that protection space. The authentication session lasts until the client receives another WWW-Authenticate challenge from any server in the protection space. A client should remember the username, password, nonce, nonce count and opaque values associated with an authentication session to use to construct the Authorization header in future requests within that protection space. The Authorization header may be included preemptively; doing so improves server efficiency and avoids extra round trips for authentication challenges. The server may choose to accept the old Authorization header information, even though the nonce value included might not be fresh. Alternatively, the server may return a 401 response with a new nonce value, causing the client to retry the request; by specifying stale=TRUE with this response, the server tells the client to retry with the new nonce, but without prompting for a new username and password.
Because the client is required to return the value of the opaque directive given to it by the server for the duration of a session, the opaque data may be used to transport authentication session state information. (Note that any such use can also be accomplished more easily and safely by including the state in the nonce.) For example, a server could be responsible for authenticating content that actually sits on another server. It would achieve this by having the first 401 response include a domain directive whose value includes a URI on the second server, and an opaque directive whose value contains the state information. The client will retry the request, at which time the server might respond with a 301/302 redirection, pointing to the URI on the second server. The client will follow the redirection, and pass an Authorization header , including the <opaque> data.
As with the basic scheme, proxies must be completely transparent in the Digest access authentication scheme. That is, they must forward the WWW-Authenticate, Authentication-Info and Authorization headers untouched. If a proxy wants to authenticate a client before a request is forwarded to the server, it can be done using the Proxy-Authenticate and Proxy-Authorization headers described in Section 3.6 below.
It is useful for a server to be able to know which security schemes a client is capable of handling.
It is possible that a server may want to require Digest as its authentication method, even if the server does not know that the client supports it. A client is encouraged to fail gracefully if the server specifies only authentication schemes it cannot handle.
The following example assumes that an access-protected document is being requested from the server via a GET request. The URI of the document is "http://www.nowhere.org/dir/index.html". Both client and server know that the username for this document is "Mufasa", and the password is "Circle Of Life" (with one space between each of the three words).
The first time the client requests the document, no Authorization header is sent, so the server responds with:
HTTP/1.1 401 Unauthorized WWW-Authenticate: Digest realm="email@example.com", qop="auth,auth-int", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="5ccc069c403ebaf9f0171e9517f40e41"
The client may prompt the user for the username and password, after which it will respond with a new request, including the following Authorization header:
Authorization: Digest username="Mufasa", realm="email@example.com", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", uri="/dir/index.html", qop=auth, nc=00000001, cnonce="0a4f113b", response="6629fae49393a05397450978507c4ef1", opaque="5ccc069c403ebaf9f0171e9517f40e41"
The digest authentication scheme may also be used for authenticating users to proxies, proxies to proxies, or proxies to origin servers by use of the Proxy-Authenticate and Proxy-Authorization headers. These headers are instances of the Proxy-Authenticate and Proxy-Authorization headers specified in sections 10.33 and 10.34 of the HTTP/1.1 specification [2] and their behavior is subject to restrictions described there. The transactions for proxy authentication are very similar to those already described. Upon receiving a request which requires authentication, the proxy/server must issue the "407 Proxy Authentication Required" response with a "Proxy-Authenticate" header. The digest-challenge used in the Proxy-Authenticate header is the same as that for the WWW-Authenticate header as defined above in Section 3.2.1.
The client/proxy must then re-issue the request with a Proxy-Authorization header, with directives as specified for the Authorization header in Section 3.2.2 above.
On subsequent responses, the server sends Proxy-Authentication-Info with directives the same as those for the Authentication-Info header field.
Note that in principle a client could be asked to authenticate itself to both a proxy and an end-server, but never in the same response.
The Basic authentication scheme is not a secure method of user authentication, nor does it in any way protect the entity, which is transmitted in cleartext across the physical network used as the carrier. HTTP does not prevent additional authentication schemes and encryption mechanisms from being employed to increase security or the addition of enhancements (such as schemes to use one-time passwords) to Basic authentication.
The most serious flaw in Basic authentication is that it results in the essentially cleartext transmission of the user's password over the physical network. It is this problem which Digest Authentication attempts to address.
Because Basic authentication involves the cleartext transmission of passwords it SHOULD NOT be used (without enhancements) to protect sensitive or valuable information.
A common use of Basic authentication is for identification purposes -- requiring the user to provide a user name and password as a means of identification, for example, for purposes of gathering accurate usage statistics on a server. When used in this way it is tempting to think that there is no danger in its use if illicit access to the protected documents is not a major concern. This is only correct if the server issues both user name and password to the users and in particular does not allow the user to choose his or her own password. The danger arises because naive users frequently reuse a single password to avoid the task of maintaining multiple passwords.
If a server permits users to select their own passwords, then the threat is not only unauthorized access to documents on the server but also unauthorized access to any other resources on other systems that the user protects with the same password. Furthermore, in the server's password database, many of the passwords may also be users' passwords for other sites. The owner or administrator of such a system could therefore expose all users of the system to the risk of unauthorized access to all those sites if this information is not maintained in a secure fashion.
Basic Authentication is also vulnerable to spoofing by counterfeit servers. If a user can be led to believe that he is connecting to a host containing information protected by Basic authentication when, in fact, he is connecting to a hostile server or gateway, then the attacker can request a password, store it for later use, and feign an error. This type of attack is not possible with Digest Authentication. Server implementers SHOULD guard against the possibility of this sort of counterfeiting by gateways or CGI scripts. In particular it is very dangerous for a server to simply turn over a connection to a gateway. That gateway can then use the persistent connection mechanism to engage in multiple transactions with the client while impersonating the original server in a way that is not detectable by the client.
Digest Authentication does not provide a strong authentication mechanism, when compared to public key based mechanisms, for example. However, it is significantly stronger than (e.g.) CRAM-MD5, which has been proposed for use with LDAP [10], POP and IMAP (see RFC 2195 [9]). It is intended to replace the much weaker and even more dangerous Basic mechanism.
Digest Authentication offers no confidentiality protection beyond protecting the actual password. All of the rest of the request and response are available to an eavesdropper.
Digest Authentication offers only limited integrity protection for the messages in either direction. If qop=auth-int mechanism is used, those parts of the message used in the calculation of the WWW-Authenticate and Authorization header field response directive values (see Section 3.2 above) are protected. Most header fields and their values could be modified as a part of a man-in-the-middle attack.
Many needs for secure HTTP transactions cannot be met by Digest Authentication. For those needs TLS or SHTTP are more appropriate protocols. In particular Digest authentication cannot be used for any transaction requiring confidentiality protection. Nevertheless many functions remain for which Digest authentication is both useful and appropriate. Any service in present use that uses Basic should be switched to Digest as soon as practical.
The Digest scheme uses a server-specified nonce to seed the generation of the request-digest value (as specified in Section 126.96.36.199 above). As shown in the example nonce in Section 3.2.1, the server is free to construct the nonce such that it may only be used from a particular client, for a particular resource, for a limited period of time or number of uses, or any other restrictions. Doing so strengthens the protection provided against, for example, replay attacks (see 4.5). However, it should be noted that the method chosen for generating and checking the nonce also has performance and resource implications. For example, a server may choose to allow each nonce value to be used only once by maintaining a record of whether or not each recently issued nonce has been returned and sending a next-nonce directive in the Authentication-Info header field of every response. This protects against even an immediate replay attack, but has a high cost checking nonce values, and perhaps more important will cause authentication failures for any pipelined requests (presumably returning a stale nonce indication). Similarly, incorporating a request-specific element such as the Etag value for a resource limits the use of the nonce to that version of the resource and also defeats pipelining. Thus it may be useful to do so for methods with side effects but have unacceptable performance for those that do not.
Both Digest and Basic Authentication are very much on the weak end of the security strength spectrum. But a comparison between the two points out the utility, even necessity, of replacing Basic by Digest.
The greatest threat to the type of transactions for which these protocols are used is network snooping. This kind of transaction might involve, for example, online access to a database whose use is restricted to paying subscribers. With Basic authentication an eavesdropper can obtain the password of the user. This not only permits him to access anything in the database, but, often worse, will permit access to anything else the user protects with the same password.
By contrast, with Digest Authentication the eavesdropper only gets access to the transaction in question and not to the user's password. The information gained by the eavesdropper would permit a replay attack, but only with a request for the same document, and even that may be limited by the server's choice of nonce.
A replay attack against Digest authentication would usually be pointless for a simple GET request since an eavesdropper would already have seen the only document he could obtain with a replay. This is because the URI of the requested document is digested in the client request and the server will only deliver that document. By contrast under Basic Authentication once the eavesdropper has the user's password, any document protected by that password is open to him.
Thus, for some purposes, it is necessary to protect against replay attacks. A good Digest implementation can do this in various ways. The server created "nonce" value is implementation dependent, but if it contains a digest of the client IP, a time-stamp, the resource ETag, and a private server key (as recommended above) then a replay attack is not simple. An attacker must convince the server that the request is coming from a false IP address and must cause the server to deliver the document to an IP address different from the address to which it believes it is sending the document. An attack can only succeed in the period before the time-stamp expires. Digesting the client IP and time-stamp in the nonce permits an implementation which does not maintain state between transactions.
For applications where no possibility of replay attack can be tolerated the server can use one-time nonce values which will not be honored for a second use. This requires the overhead of the server remembering which nonce values have been used until the nonce time-stamp (and hence the digest built with it) has expired, but it effectively protects against replay attacks.
An implementation must give special attention to the possibility of replay attacks with POST and PUT requests. Unless the server employs one-time or otherwise limited-use nonces and/or insists on the use of the integrity protection of qop=auth-int, an attacker could replay valid credentials from a successful request with counterfeit form data or other message body. Even with the use of integrity protection most metadata in header fields is not protected. Proper nonce generation and checking provides some protection against replay of previously used valid credentials, but see 4.8.
An HTTP/1.1 server may return multiple challenges with a 401 (Authenticate) response, and each challenge may use a different auth-scheme. A user agent MUST choose to use the strongest auth-scheme it understands and request credentials from the user based upon that challenge.
When the server offers choices of authentication schemes using the WWW-Authenticate header, the strength of the resulting authentication is only as good as that of the of the weakest of the authentication schemes. See Section 4.8 below for discussion of particular attack scenarios that exploit multiple authentication schemes.
If the attacker can eavesdrop, then it can test any overheard nonce/response pairs against a list of common words. Such a list is usually much smaller than the total number of possible passwords. The cost of computing the response for each password on the list is paid once for each challenge.
The server can mitigate this attack by not allowing users to select passwords that are in a dictionary.
Both Basic and Digest authentication are vulnerable to "man in the middle" (MITM) attacks, for example, from a hostile or compromised proxy. Clearly, this would present all the problems of eavesdropping. But it also offers some additional opportunities to the attacker.
A possible man-in-the-middle attack would be to add a weak authentication scheme to the set of choices, hoping that the client will use one that exposes the user's credentials (e.g. password). For this reason, the client should always use the strongest scheme that it understands from the choices offered.
An even better MITM attack would be to remove all offered choices, replacing them with a challenge that requests only Basic authentication, then uses the cleartext credentials from the Basic authentication to authenticate to the origin server using the stronger scheme it requested. A particularly insidious way to mount such a MITM attack would be to offer a "free" proxy caching service to gullible users.
User agents should consider measures such as presenting a visual indication at the time of the credentials request of what authentication scheme is to be used, or remembering the strongest authentication scheme ever requested by a server and produce a warning message before using a weaker one. It might also be a good idea for the user agent to be configured to demand Digest authentication in general, or from specific sites.
Or, a hostile proxy might spoof the client into making a request the attacker wanted rather than one the client wanted. Of course, this is still much harder than a comparable attack against Basic Authentication.
With Digest authentication, a MITM or a malicious server can arbitrarily choose the nonce that the client will use to compute the response. This is called a "chosen plaintext" attack. The ability to choose the nonce is known to make cryptanalysis much easier [8].
However, no way to analyze the MD5 one-way function used by Digest using chosen plaintext is currently known.
The countermeasure against this attack is for clients to be configured to require the use of the optional "cnonce" directive; this allows the client to vary the input to the hash in a way not chosen by the attacker.
With Digest authentication, if the attacker can execute a chosen plaintext attack, the attacker can precompute the response for many common words to a nonce of its choice, and store a dictionary of (response, password) pairs. Such precomputation can often be done in parallel on many machines. It can then use the chosen plaintext attack to acquire a response corresponding to that challenge, and just look up the password in the dictionary. Even if most passwords are not in the dictionary, some might be. Since the attacker gets to pick the challenge, the cost of computing the response for each password on the list can be amortized over finding many passwords. A dictionary with 100 million password/response pairs would take about 3.2 gigabytes of disk storage.
The countermeasure against this attack is to for clients to be configured to require the use of the optional "cnonce" directive.
With Digest authentication, a MITM can execute a chosen plaintext attack, and can gather responses from many users to the same nonce. It can then find all the passwords within any subset of password space that would generate one of the nonce/response pairs in a single pass over that space. It also reduces the time to find the first password by a factor equal to the number of nonce/response pairs gathered. This search of the password space can often be done in parallel on many machines, and even a single machine can search large subsets of the password space very quickly -- reports exist of searching all passwords with six or fewer letters in a few hours.
The countermeasure against this attack is to for clients to be configured to require the use of the optional "cnonce" directive.
Basic Authentication is vulnerable to spoofing by counterfeit servers. If a user can be led to believe that she is connecting to a host containing information protected by a password she knows, when in fact she is connecting to a hostile server, then the hostile server can request a password, store it away for later use, and feign an error. This type of attack is more difficult with Digest Authentication -- but the client must know to demand that Digest authentication be used, perhaps using some of the techniques described above to counter "man-in-the-middle" attacks. Again, the user can be helped in detecting this attack by a visual indication of the authentication mechanism in use with appropriate guidance in interpreting the implications of each scheme.
Digest authentication requires that the authenticating agent (usually the server) store some data derived from the user's name and password in a "password file" associated with a given realm. Normally this might contain pairs consisting of username and H(A1), where H(A1) is the digested value of the username, realm, and password as described above.
The security implications of this are that if this password file is compromised, then an attacker gains immediate access to documents on the server using this realm. Unlike, say a standard UNIX password file, this information need not be decrypted in order to access documents in the server realm associated with this file. On the other hand, decryption, or more likely a brute force attack, would be necessary to obtain the user's password. This is the reason that the realm is part of the digested data stored in the password file. It means that if one Digest authentication password file is compromised, it does not automatically compromise others with the same username and password (though it does expose them to brute force attack).
There are two important security consequences of this. First the password file must be protected as if it contained unencrypted passwords, because for the purpose of accessing documents in its realm, it effectively does.
A second consequence of this is that the realm string should be unique among all realms which any single user is likely to use. In particular a realm string should include the name of the host doing the authentication. The inability of the client to authenticate the server is a weakness of Digest Authentication.
By modern cryptographic standards Digest Authentication is weak. But for a large range of purposes it is valuable as a replacement for Basic Authentication. It remedies some, but not all, weaknesses of Basic Authentication. Its strength may vary depending on the implementation. In particular the structure of the nonce (which is dependent on the server implementation) may affect the ease of mounting a replay attack. A range of server options is appropriate since, for example, some implementations may be willing to accept the server overhead of one-time nonces or digests to eliminate the possibility of replay. Others may satisfied with a nonce like the one recommended above restricted to a single IP address and a single ETag or with a limited lifetime.
The bottom line is that *any* compliant implementation will be relatively weak by cryptographic standards, but *any* compliant implementation will be far superior to Basic Authentication.
The following code implements the calculations of H(A1), H(A2), request-digest and response-digest, and a test program which computes the values used in the example of Section 3.5. It uses the MD5 implementation from RFC 1321.
File "digcalc.h":
#define HASHLEN 16 typedef char HASH[HASHLEN]; #define HASHHEXLEN 32 typedef char HASHHEX[HASHHEXLEN+1]; #define IN #define OUT /* calculate H(A1) as per HTTP Digest spec */ void DigestCalcHA1( IN char * pszAlg, IN char * pszUserName, IN char * pszRealm, IN char * pszPassword, IN char * pszNonce, IN char * pszCNonce, OUT HASHHEX SessionKey ); /* calculate request-digest/response-digest as per HTTP Digest spec */ void DigestCalcResponse( IN HASHHEX HA1, /* H(A1) */ IN char * pszNonce, /* nonce from server */ IN char * pszNonceCount, /* 8 hex digits */ IN char * pszCNonce, /* client nonce */ IN char * pszQop, /* qop-value: "", "auth", "auth-int" */ IN char * pszMethod, /* method from the request */ IN char * pszDigestUri, /* requested URL */ IN HASHHEX HEntity, /* H(entity body) if qop="auth-int" */ OUT HASHHEX Response /* request-digest or response-digest */ );
File "digcalc.c":
#include <global.h> #include <md5.h> #include <string.h> #include "digcalc.h" void CvtHex( IN HASH Bin, OUT HASHHEX Hex ) { unsigned short i; unsigned char j; for (i = 0; i < HASHLEN; i++) { j = (Bin[i] >> 4) & 0xf; if (j <= 9) Hex[i*2] = (j + '0'); else Hex[i*2] = (j + 'a' - 10); j = Bin[i] & 0xf; if (j <= 9) Hex[i*2+1] = (j + '0'); else Hex[i*2+1] = (j + 'a' - 10); }; Hex[HASHHEXLEN] = '\0'; }; /* calculate H(A1) as per spec */ void DigestCalcHA1( IN char * pszAlg, IN char * pszUserName, IN char * pszRealm, IN char * pszPassword, IN char * pszNonce, IN char * pszCNonce, OUT HASHHEX SessionKey ) { MD5_CTX Md5Ctx; HASH HA1; MD5Init(&Md5Ctx); MD5Update(&Md5Ctx, pszUserName, strlen(pszUserName)); MD5Update(&Md5Ctx, ":", 1); MD5Update(&Md5Ctx, pszRealm, strlen(pszRealm)); MD5Update(&Md5Ctx, ":", 1); MD5Update(&Md5Ctx, pszPassword, strlen(pszPassword)); MD5Final(HA1, &Md5Ctx); if (stricmp(pszAlg, "md5-sess") == 0) { MD5Init(&Md5Ctx); MD5Update(&Md5Ctx, HA1, HASHLEN); MD5Update(&Md5Ctx, ":", 1); MD5Update(&Md5Ctx, pszNonce, strlen(pszNonce)); MD5Update(&Md5Ctx, ":", 1); MD5Update(&Md5Ctx, pszCNonce, strlen(pszCNonce)); MD5Final(HA1, &Md5Ctx); }; CvtHex(HA1, SessionKey); }; /* calculate request-digest/response-digest as per HTTP Digest spec */ void DigestCalcResponse( IN HASHHEX HA1, /* H(A1) */ IN char * pszNonce, /* nonce from server */ IN char * pszNonceCount, /* 8 hex digits */ IN char * pszCNonce, /* client nonce */ IN char * pszQop, /* qop-value: "", "auth", "auth-int" */ IN char * pszMethod, /* method from the request */ IN char * pszDigestUri, /* requested URL */ IN HASHHEX HEntity, /* H(entity body) if qop="auth-int" */ OUT HASHHEX Response /* request-digest or response-digest */ ) { MD5_CTX Md5Ctx; HASH HA2; HASH RespHash; HASHHEX HA2Hex; // calculate H(A2) MD5Init(&Md5Ctx); MD5Update(&Md5Ctx, pszMethod, strlen(pszMethod)); MD5Update(&Md5Ctx, ":", 1); MD5Update(&Md5Ctx, pszDigestUri, strlen(pszDigestUri)); if (stricmp(pszQop, "auth-int") == 0) { MD5Update(&Md5Ctx, ":", 1); MD5Update(&Md5Ctx, HEntity, HASHHEXLEN); }; MD5Final(HA2, &Md5Ctx); CvtHex(HA2, HA2Hex); // calculate response MD5Init(&Md5Ctx); MD5Update(&Md5Ctx, HA1, HASHHEXLEN); MD5Update(&Md5Ctx, ":", 1); MD5Update(&Md5Ctx, pszNonce, strlen(pszNonce)); MD5Update(&Md5Ctx, ":", 1); if (*pszQop) { MD5Update(&Md5Ctx, pszNonceCount, strlen(pszNonceCount)); MD5Update(&Md5Ctx, ":", 1); MD5Update(&Md5Ctx, pszCNonce, strlen(pszCNonce)); MD5Update(&Md5Ctx, ":", 1); MD5Update(&Md5Ctx, pszQop, strlen(pszQop)); MD5Update(&Md5Ctx, ":", 1); }; MD5Update(&Md5Ctx, HA2Hex, HASHHEXLEN); MD5Final(RespHash, &Md5Ctx); CvtHex(RespHash, Response); };
File "digtest.c":
#include <stdio.h> #include "digcalc.h" void main(int argc, char ** argv) { char * pszNonce = "dcd98b7102dd2f0e8b11d0f600bfb0c093"; char * pszCNonce = "0a4f113b"; char * pszUser = "Mufasa"; char * pszRealm = "email@example.com"; char * pszPass = "Circle Of Life"; char * pszAlg = "md5"; char szNonceCount[9] = "00000001"; char * pszMethod = "GET"; char * pszQop = "auth"; char * pszURI = "/dir/index.html"; HASHHEX HA1; HASHHEX HA2 = ""; HASHHEX Response; DigestCalcHA1(pszAlg, pszUser, pszRealm, pszPass, pszNonce, pszCNonce, HA1); DigestCalcResponse(HA1, pszNonce, szNonceCount, pszCNonce, pszQop, pszMethod, pszURI, HA2, Response); printf("Response = %s\n", Response); };
Eric W. Sink, of AbiSource, Inc., was one of the original authors before the specification underwent substantial revision.
In addition to the authors, valuable discussion instrumental in creating this document has come from Peter J. Churchyard, Ned Freed, and David M. Kristol.
Jim Gettys and Larry Masinter edited this document for update.
|Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
|Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
|Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
|Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
|Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
|Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., Luotonen, A., Sink, E., and L. Stewart, "An Extension to HTTP : Digest Access Authentication", RFC 2069, January 1997.
|Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
|Kaliski, B. and M. Robshaw, "Message Authentication with MD5", 1995, <http://www.rsa.com/rsalabs/pubs/cryptobytes/spring95/md5.htm>.
CryptoBytes, Spring 1995
|Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP AUTHorize Extension for Simple Challenge/Response", RFC 2195, September 1997.
|Morgan, B., Alvestrand, H., Hodges, J., and M. Wahl, "Authentication Methods for LDAP".
Work in progress.
Copyright © The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
Funding for the RFC Editor function is currently provided by the Internet Society.


text:
allegory, in literature, symbolic story that serves as a disguised representation for meanings other than those indicated on the surface. The characters in an allegory often have no individual personality, but are embodiments of moral qualities and other abstractions. The allegory is closely related to the parable, fable, and metaphor, differing from them largely in intricacy and length. A great variety of literary forms have been used for allegories. The medieval morality play Everyman, personifying such abstractions as Fellowship and Good Deeds, recounts the death journey of Everyman. John Bunyan's Pilgrim's Progress, a prose narrative, is an allegory of man's spiritual salvation. Spenser's poem The Faerie Queene, besides being a chivalric romance, is a commentary on morals and manners in 16th-century England as well as a national epic. Although allegory is still used by some authors, its popularity as a literary form has declined in favor of a more personal form of symbolic expression (see symbolists).
See C. S. Lewis, The Allegory of Love (1936); P. de Man, Allegories of Reading (1979); M. Quilligan, The Language of Allegory (1979)
The Columbia Electronic Encyclopedia, 6th ed. Copyright © 2023, Columbia University Press. All rights reserved.
See more Encyclopedia articles on: Literature: General

subset: commoncrawl


text:
SHERIDAN, Wyo.—Authorities say five snowmobilers who went missing in northern Wyoming's Bighorn Mountains have been found safe.
Lt. Mark Conrad with the Sheridan County Sheriff's Office says the group was found near Horse Creek Mesa just after 1 p.m. Saturday. The Sheridan Press reports (http://bit.ly/1nUDyS5 ) that they ran out of gas.
They would not require medical attention, the newspaper reported.
More than 50 people had been taking shifts in wintry conditions searching for the group, which was reported missing early Friday by the owner of the Bear Lodge Resort. The snowmobilers were last seen at about 3:30 p.m. Thursday.
Conrad has said all five are from North Dakota and are considered experienced. They also are familiar with the Bighorns.
Information from: The Sheridan (Wyo.) Press, http://www.thesheridanpress.com/


text:
redsagebear wrote::thumbup: I hope to have another flying experience. It doesn't have to be off the ground. I can feel and see with my flying imagination. Being the fantasy it is, I have never felt so close to an element in this world. The wind is SUPER POWERFUL. I think in order to prepare oneself for flying, we must learn-to understand, the wind. I am originaly from the Oregon Coast. Gold Beach, Curry County. I graduated 1999 in Brookings, Oregon. Where there is a lot of wind. The kind that moves and inspires you. The kind that remindes you of courage.
Return to Lakeview Hawks Forum
Users browsing this forum: No registered users and 1 guest


text:
Chances are you've seen this symbol before, because it's one of the most well-known Egyptian symbols. It's called the Eye of Horus. It's been in the background of plenty of mummy movies, and been turned into a lot of necklace charms.
Some people think it's writing. Actually, it's math.
Top image: Jose Ignacio Soto/Shutterstock.com
The Eye of Horus is, from a design standpoint, both beautiful and iconic. And whoever created it might have been thinking of exactly that while dreaming it up. But it's not just a stylish symbol. It has a deeper meaning: The Egyptians used it to express fractions of volume. Each stroke counts for a subdivided piece of the whole.
The inner corner of the eye indicates one half, the iris is one fourth, the eyebrow is one eighth, the outer corner of the eye is one sixteenth, and the decorations below the eye are one thirty-second and one sixty-fourth respectively. They were combined, in various ways, to measure the unit capacity for grains.
This eye may seem like a straightforward notation system, but it's not just that. It's also a pictogram. A good analog for this is a simple tally system kept by a child. Four slashes indicate units, and one diagonal slash across the four indicates a group of five. Look over a list, and it's easier to get a sense of the different amounts that have been tallied than to read the numerals for all of them. (Similarly, some people in East Asia still use the character for "correct" as a kind of tally system.)
By using different marks to make a complete Eye of Horus, people in charge of many different quantities of something can skim a list quickly. And they can get a sense of how many storage units are at what capacity, just by looking for how many completed eyes there are, and whether the incomplete eyes are built from the inside out or the outside in.
And other tallying systems use basic pictograms as well. We have an easy-to-see tallying unit for five, the four lines with a slash, but we have a base ten numbering system. Other societies had an simple way to represent ten objects; a simple box with two diagonal lines crossed inside it. Each element in its construction represented a stage of counting to ten. First there are four dots representing the four corners of the box. Then there are four lines, each one side of the box. That adds up to eight, with the two diagonal slashes through the center bringing it up to ten. To tally and count by tens, all anyone had to do was look at the number of completed boxes.
We might do well to bring a working pictogram system back into common usage, here in the West. Although it would only be helpful in certain situations, like when most of the things being tallied fall between one and a hundred, or when all of the objects being tallied are fractions, it's very useful in practice. Anyone who has had to scan down a list of numbers knows that they're nearly impossible to remember as a whole.
A system that allowed people to look down a list and see the entire list as a whole, zeroing in immediately on differing amounts without having to read the whole thing, would be useful anywhere people have to keep handwritten and quickly-changing records. All we'd need to do is come up with simple symbols that can be broken down into tens, hundreds, or parts of a whole, and we can create a new-old system of notation.
Via Wolfram Math World.


text:
Call Us: 1 (866) 777-2241 FREE Shipping on Orders Over $400
Sign In to view even more Cell Phone Parts!
Cell Phone Parts for Wholesale
Please note, the Cell Phone Parts sold on this website are for wholesale customers only (i.e. cell phone shops, retailers and variety stores).
Phones tend to break. These accessories offer replacement parts for cellular handsets.
Search results for "Samsung Galaxy Tab 3 7.0":
Charging Port - Samsung Galaxy Tab 3 7.0 T210
Get it for only $1.98 when you buy more.Add to Cart
Phone repairs is a huge market offering high profit margin to the retailers. Large cell phones tend to fall and break often - often times, the damaged LCD screens require repair parts such as Digitizers. We are continuously expanding our selection of wholesale cell phone parts. We offer many high quality and low cost wholesale phone parts.
Newsletter Subcription
Subscribe to receive the latest products and important cell phone industry news.
Top SellersView Top Selling Cell Phone Accessories
Warehouse ClearanceExceptionally Good Deals on Overstocked Accessories.
Special PromotionsSpecial Promotions for Limited Time Only


text:
All the fighters from this past weekend's UFC 158 event avoided lengthy medical suspensions following the show.
The event took place this past Saturday, March 16, at Montreal's Bell Centre, and UFC welterweight champion Georges St-Pierre scored a decision victory over Nick Diaz in the pay-per-view headliner.
MMAjunkie.com (www.mmajunkie.com) today obtained the list of medical suspensions from Régie des alcools des courses et des jeux (Quebec's athletic commission). Disclosed paydays/salaries for the event won't be released.
Only Nate Marquardt, who suffered a knockout loss to fellow welterweight Jake Ellenberger on the main card, received a suspension of more than 45 days. He's been issued a mandatory rest period of 60 days.
The commission also issued 45-day layoffs to preliminary-card fighters Daron Cruickshank, Issei Tamura and Reuben Duran. All of the fighters suffered losses.
The full list of medical suspensions included:
- Georges St-Pierre: 28-day suspension
- Nick Diaz: 28-day suspension
- Johny Hendricks: 14-day suspension
- Carlos Condit: 14-day suspension
- Jake Ellenberger: seven-day suspension
- Nate Marquardt: 60-day medical suspension
- Chris Camozzi: 14-day suspension
- Nick Ring: 14-day suspension
- Mike Ricci: 14-day suspension
- Colin Fletcher: 14-day suspension
- Patrick Cote: 14-day suspension
- Bobby Voelker: 14-day suspension
- Darren Elkins: seven-day suspension
- Antonio Carvalho: 30-day medical suspension
- Jordan Mein: seven-day suspension
- Dan Miller: 30-day medical suspension
- John Makdessi: 14-day suspension
- Daron Cruickshank: 45-day medical suspension
- Rick Story: seven-day suspension
- Quinn Mulhern: 30-day medical suspension
- T.J. Dillashaw: seven-day suspension
- Issei Tamura: 45-day medical suspension
- George Roop: 14-day suspension
- Reuben Duran: 45-day medical suspension
For complete coverage of UFC 158, stay tuned to the UFC Events section of the site.
(Pictured: Nate Marquardt)


text:
Juried Plein Air artists paint from downtown Canandaigua to the Pier for 2 hours, followed by judging and awards
To download any individual image, select the arrow button at the bottom of the image. OR you can download an entire gallery by selecting the 'download all' arrow (my website will create a 'zip' file of the images and send you an email when this is ready for download). PLEASE download for free and print at home. Or order prints thru this website at cost, which are printed and mailed by EZlabs. You can also download and send files to printing services such as shutterfly or mpix.com, and post freely in social media. Or you can just enjoy them here on my website! The pictures are yours and will remain here indefinitely. Feedback WELCOME at firstname.lastname@example.com


text:
Apply at www.RossStores.com
To assist in the protection of assets of the Ross Stores, Inc. logistics network by manning post positions, patrols, and CCTV monitoring. This individual must use extreme confidentiality in respecting employees' privacy within the company guidelines and procedures. This individual will provide communication of all activity to peers and superiors as well as express all questions and concerns relating to the job to the LP Supervisors.
- Conduct safety and security tours of the distribution center identifying unsafe acts, weaknesses in the protection program, etc.
- Discover and document facts by conducting basic investigations into associate dishonesty, power equipment accidents, personnel injury accidents, etc.
- Respond to emergency situations, such as medical, fire, weather, haz mat and security related incidents and take appropriate actions, as stated by corporate policy.
- Conduct on-going loss prevention and safety awareness programs for associates, to include presenting new hire orientation programs.
- Conduct audits that are designed to uncover associate dishonesty, paperwork errors (i.e., miss-picks, etc.) and compliance to governmental regulations (OSHA, EPA, USDA, BATF, DEA, etc.). As well as security audits to ensure physical security standards.
- All associates must know the contents of the security procedures manual and support the printed regulations therein.
- Quality * Interpersonal Effectiveness
- Communication * Collaboration
- Adaptability * Technical/Functional Competence
- High school degree or equivalent required.
- Security Guard Card required. (California Only)
- Basic knowledge of loss prevention and safety practices, to include knowledge of fire/burglar alarm and CCTV.
- Good verbal and written communication skills.
- Must maintain current certification in the following: 1) Basic First Aid, 2) CPR, 3) Oxygen Administration (if applicable) and 4) Blood borne Pathogen.
- Successfully complete a detailed security background investigation that may include the following; credit history, criminal history and motor vehicle driving history.
- Must be a person of integrity and possess highest ethical standards.
Job Type: Part-time
- High school or equivalent (Preferred)
To Apply to this job Please go to website address given in Source below
Source: https://www.indeed.com/viewjob?t=Store+Protection+Specialist&c=Ross+Dress+For+Less&l=Saugus,+CA&jk=9c930013a3645b80&rtk=1cus4rkgdac1a800&from=rss


text:
Founded in 1945, Cantor Fitzgerald is an innovative global financial services firm.
Howard W. Lutnick, Chairman and CEO of Cantor Fitzgerald, L.P.
Howard W. Lutnick is Chairman and CEO of Cantor Fitzgerald L.P., one of the world's leading financial services firms, and Chairman and CEO of BGC Partners Inc., a leading global brokerage company primarily servicing the wholesale financial and real estate markets. More details about his role at BGC Partners can be read here.
Equity Capital Markets
Cantor Fitzgerald is recognized around the world for its strength in the equity and fixed income capital markets, its global institutional distribution model, as well as its expanding presence in investment banking and real estate financing.
Cantor Fitzgerald is always on the lookout for outstanding individuals to join our growing team.
Howard W. Lutnick Joins 'The Claman Countdown' to Discuss Secretary Mnuchin's $150 Investment in Satellogic and CFV
Howard W. Lutnick Joins CNBC's "Fast Money" for its 15th Anniversary Special
Howard W. Lutnick Discusses Secretary Mnuchin's $150 Million Investment in Satellogic and CF Acquisition Corp. V on Bloomberg TV
Chairman & CEO Howard W. Lutnick Joins Richard Quest on CNN International
Chairman & CEO Howard W. Lutnick Joined Liz Claman on Fox Business Network to Discuss CFVI and Rumble
Howard W. Lutnick Discusses CFVI's Rumble Merger on Newsmax
Howard W. Lutnick appeared on Bloomberg TV this afternoon to discuss Rumble Inc., the neutral video platform, going public through Cantor Fitzgerald's CF Acquisition Corp. VI (Nasdaq: CFVI)
Cantor Fitzgerald Chairman & CEO Howard Lutnick joined 'Bloomberg Markets' to discuss investment in Satellogic and the use of blank-check companies to connect private businesses to public capital markets.
Howard Lutnick, CEO & Chairman of Cantor Fitzgerald, joins 'Squawk on the Street' to discuss Satellite imagery startup Satellogic's plans to go public via a SPAC merger and the space race to conquer the new frontier.
Howard Lutnick, Chairman & CEO of Cantor Fitzgerald, L.P., joined the NYSE's "Inside the ICE House" podcast to share his thoughts on SPACs, monetary policy, and leading the "biggest little guy" on Wall Street.
Howard Lutnick, Cantor Fitzgerald Chairman & CEO joins Richard Quest of 'Quest Means Business' on CNN International to discuss markets, the SPAC boom and why "retail investors are here to stay."
Howard Lutnick, Chairman & CEO of Cantor Fitzgerald, appeared on "Bloomberg Markets" today and discusses Cantor Fitzgerald's SPAC franchise, the surge of retail investing and the market outlook.
Cantor Fitzgerald Chairman & CEO Howard Lutnick says special purpose acquisition companies are filling a "gap" for investors between the initial public offering and private equity markets. "SPACs are here to stay, they fill that void," Lutnick says on Bloomberg TV.
Howard Lutnick appeared on CNBC's "Squawk Box" following the announcement of the business combination transaction between View, Inc. and CF Finance Acquisition Corp. II, the SPAC sponsored by Cantor Fitzgerald
The Cantor Fitzgerald Relief Fund's COVID-19 Family Relief Program
In these difficult times we are staying true to our mission. 100% of monies raised will go to elementary schools in disadvantaged communities to provide direct financial aid to families with young children in need.
The Cantor Fitzgerald Global Healthcare Group is compiling a daily COVID-19 Medical News Update, which highlights current medical and healthcare news pertaining to the pandemic. Please share the newsletter with your clients, family & friends, and consider making a donation to the Cantor Fitzgerald Relief Fund's COVID-19 Family Relief Program by clicking the DONATE NOW button below.
Howard Lutnick, Chairman & CEO of Cantor Fitzgerald, speaks to Fox Business live from the World Economic Forum in Davos, Switzerland.
Cantor Fitzgerald remembers 9/11 with Charity Day
Howard Lutnick, Chairman & CEO of Cantor Fitzgerald, speaks to CNBC about remembering 9/11 and the firm's Charity Day.
The Cantor Fitzgerald Relief Fund's Puerto Rico Family Relief Program
On January 13, 2019, The Cantor Fitzgerald Relief Fund held the Puerto Rico Family Relief Program in San Juan, Puerto Rico. The Relief Fund distributed direct financial aid to approximately 4,000 families who are still recovering after Hurricanes Maria and Irma devastated the island.
Howard Lutnick interviewed live by Fox Business at the World Economic Forum in Davos, Switzerland
Howard Lutnick was interviewed by Maria Bartiromo on Fox Business' "Mornings with Maria" at the World Economic Forum in Davos, Switzerland and discussed concerns over the global economic outlook, the firm's strategy for growth, and the outlook for real estate.
Howard Lutnick, Chairman & CEO of Cantor Fitzgerald and BGC Partners, spoke to CNN's Richard Quest on "The Express" at the World Economic Forum in Davos, Switzerland about global market outlook and the biggest worries of 2019.
Cantor Fitzgerald Relief Fund
At the Cantor Fitzgerald Relief Fund, our mission is to support families impacted by emergencies and natural disasters.
Cantor Fitzgerald's Charity Day
Howard Lutnick spoke to NBC News New York's Julio Gaby Acevedo about the Cantor Fitzgerald Relief Fund's recent direct financial aid distribution in San Juan to help families impacted by Hurricanes Irma & Maria.
Cantor Fitzgerald has offices and trading desks in all major financial centers throughout the world. We specialize in the following areas:
Cantor Fitzgerald is one of the largest and best known participants in the global equity capital arena.
Fixed Income & Currencies
From its roots in bond brokerage, Cantor has risen to become a world-renowned dealer in fixed income products.
Investment Banking
Cantor Fitzgerald's Investment Banking division offers capital raising and advisory services to both growth-oriented and mature companies.
Prime Services
Cantor Prime Services (CPS) is a global, multi-asset prime brokerage platform with a focus on the quality middle market.
Real Estate
Discover exceptional opportunities with Cantor's growing Real Estate platform.
Cantor Fitzgerald's affiliate businesses include: BGC Partners, Inc. (BGC), Newmark Group, Inc. (Newmark), and GFI Group (GFI).
Charity Day
On one day each year, Cantor Fitzgerald donates 100% of its global revenue to charity.
Middle East
New York
110 East 59th Street
New York, NY 10022
100 Fillmore Street
Suite 500
Denver, CO 80206
6 Thorndal Circle
2nd Floor
Darien, CT 06820
3060 Peachtree Road
NW Suite 950
Atlanta, Georgia 30305
Puerto Rico
530 Avenue de la Constitucion
Suite 244
San Juan, PR 00901
400 East Pratt Street
Suite 710
Baltimore, MD 21202
1700 Post Oak Blvd
2 Blvd Place, Suite 250
Houston, TX 77056
San Francisco
345 California Street
Suite 1260
San Francisco, CA 94104
2000 Southbridge Parkway
Suite 603
Birmingham, AL 35209
800 Fifth Avenue
Suite 4100
Seattle, WA 98104
New York - Headquarters
499 Park Avenue
New York, NY 10022
14185 Dallas Parkway
Suite 870
Dallas, TX 75254
20 Ash Street
Suite 350
Conshohocken, PA 19428
692 Montauk Highway
Watermill, NY 11976
1111 Brickell Ave
Suite 2000
Miami, FL 33129
Los Angeles
1925 Century Park East
Suite 700
Los Angeles, CA 90067
39 Avenue of Commons
Suite 205
Shrewsbury, NJ 07702
Chapel Hill
1340 Environ Way
Office 312
Chapel Hill, NC 27517
900 West Trade
Suite 725
Charlotte, NC 28202
6410 Poplar Avenue
Suite 700
Memphis, TN 38119
181 University Avenue
Suite 1500
Toronto, Canada M5H 3M7
47 Maple Street
2nd Floor
Summit, NJ 07901
10000 Lincoln Drive East
Suite 201
Marlton, NJ 08199
222 West Adams Street
Suite 1900
Chicago, IL 60606
101 Federal Street Floor 17
Boston, MA 02110
900 E. Main Street Suite 1000
Richmond, VA 23219
Cottonwood Heights
Regus Park Center
6975 Union Park Avenue #600
Cottonwood Heights, UT 84047
Palm Beach Gardens
300 Avenue Of The Champions Suite 110
Palm Beach Gardens, FL 33418
300 Spectrum Center Drive Suite 660
Irvine, CA 92618
660 Steamboat Road Floor 2
Greenwich, CT 06830
NKF New York - Headquarters
125 Park Avenue
New York, NY 10017
BGC Partners - New York
499 Park Avenue
New York, NY 10022
GFI New York
55 Water Street
New York, NY 10041
BGC Partners - London
BGC Brokers L.P.
5 Churchill Place
Canary Wharf
London, E14 5HU
45 South Mall
Cork, T12 XY24
Cantor Fitzgerald
Cantor Fitzgerald House
23 St Stephen's Green
Dublin D02 AR55
Hobart House
80 Hanover Street
Edinburgh, EH2 1EL Scotland
Crescent House
Hartstonge Street
Limerick, V94 K35Y
London - Canary Wharf
5 Churchill Place
Canary Wharf
London, E14 5HU
London - Mayfair
6 Chesterfield Gardens
London, W1J 5BQ
Hong Kong
6710-6712 The Center,
99 Queen's Road Central, Central, Hong Kong
Cantor Fitzgerald Singapore
16 Collyer Quay,
#31-00 Income at Raffles,
Akasaka Biz Tower 38F
5-3-1 Akasaka, Minato-ku
Tokyo 107-6338 JAPAN
Tel Aviv
Discount Tower
Yehuda Halevi 23
28th Fl
Tel Aviv, Israel 65136
Our History
From our beginnings in 1945, Cantor Fitzgerald has grown to become a global investment bank and brokerage.
- 2021
- 1945
- 1965
- 1972
- 1983
- 1991
- 1996
- 1996
- 1999
- 2001
- 2002
- 2003
- 2004
- 2005
- 2006
- 2007
- 2008
- 2010
- 2010
- 2011
- 2011
- 2011
- 2012
- 2013
- 2013
- 2014
- 2014
- 2015
- 2017
- 2017
- 2018
- 2019
- 2020
20th Anniversary of 9/11 remembered.
Bernie Cantor and John Fitzgerald create bond brokerage firm Cantor Fitzgerald.
Cantor Fitzgerald begins 'large block' sales/trading of equities for institutional customers.
Cantor Fitzgerald builds the world's first computer-assisted screen for trading US Government Securities.
Cantor Fitzgerald becomes the first firm to offer worldwide screen brokerage services in US Government Securities.
Howard Lutnick is named CEO & President of Cantor Fitzgerald.
eSpeed, Cantor Fitzgerald's fully electronic trading platform, is launched.
Howard Lutnick named Chairman of Cantor Fitzgerald.
eSpeed becomes publicly traded.
Cantor Fitzgerald loses 658 of its 960 New York employees in the 9/11 World Trade Center attacks.
Cantor Fitzgerald and its affiliates raise over $5 million on its 1st annual Charity Day.
Cantor Fitzgerald launches its Fixed Income Sales/Trading group.
Cantor Fitzgerald creates BGC Partners, Inc.
Cantor Fitzgerald launches G3 Vision, the first 3-D desktop application of US Treasury Cash and Futures Markets.
Cantor Fitzgerald becomes primary dealer to US Federal Reserve.
eSpeed launches Aqua, a venture that brings new liquidity to the global equities markets.
BGC and eSpeed merge, creating BGC Partners, Inc., one of the world's leading inter-dealer brokers.
CCRE (Cantor Commercial Real Estate), a leading commercial finance business established.
Cantor Fitzgerald Investment Advisors is launched.
BGC enters real estate brokerage market and acquires Newmark Knight Frank, a leading commercial real estate services firm.
Cantor Prime Brokerage Services established.
Cantor Fitzgerald and BGC Partners raise $12 million on Charity Day, joined by President Bill Clinton and President George Bush.
BGC continues real estate services consolidation by acquiring the assets of Grubb & Ellis, a national commercial real estate services firm.
BGC sells eSpeed to Nasdaq for $1.234 billion ($750 million of cash and 10% of NASDAQ).
Cantor Fitzgerald becomes primary dealer in Ireland.
CCRE is Named #1 Fastest Growing Company in Crain's New York Business.
BGC makes unsolicited proposal to acquire GFI.
BGC successfully acquires control of GFI Group Inc. for $750 million and subsequently sells its Trayport business to Intercontinental Exchange, Inc. for $650 million.
Anshu Jain joins Cantor Fitzgerald, L.P. as President
Newmark Group announces IPO
BGC Partners Announces Completion of Spin-Off of Newmark Group
Cantor Fitzgerald SPAC business ranked number one for the third year in a row
Cantor Fitzgerald 75-Year Anniversary


text:
Its been a while :)..great post!
By Theadora Brack
Chim chim-in-ey! Chim, chim, chérie! Get your glad rags and wiggle on, jazz babies and pêcheurs de lune! With the discerning eyeball of a dandy and the goddess Fortuna statue neatly tucked in our pocket, let's swing by the Clignancourt Flea Market (Marché aux puces de Saint-Ouen) for some old-fashioned, toe-tapping, bodice-ripping window-shopping, shall we? Get to picking!
Flashback: In the 19th century, the infamous "rag and bone men" (forerunners of today's "dumpster divers") kicked-off the big flea frenzy. Trekking to Paris? Get thee there. Clignancourt's eclectic palace-worthy collection continues to charm. In fact, the bustling centuries-old market had a cameo in Woody Allen's "Midnight in Paris." Confession: Yes, the movie was a tad hokey pokey in places, but I fell gladly for it. Fantasizing about time travel always makes my heart swell. Larger than life, Yves Heck as Cole Porter was simply divine. Paris, you DO do something to me.
Getting There
Meet me at the Square Django Reinhardt at rue René Binet and Porte de Clignancourt (Métro Porte de Clignancourt). Recently the mayor of Paris honored the late, great musician by renaming the square for him. Reinhardt lived there with his family when they moved to Paris from Belgium shortly after the "Grande Guerre" (a.k.a. World War I). Each weekend, the site is home to a gathering of stalls and booths that form an "offsite" market along the approach to Clingnancourt itself.
To reach the main flea market: Walk beyond Square Django Reinhardt and head underneath the big underpass just down the street. At 122 rue de Rossiers a block or two into the real market, you'll find La Chope des Puces, with live music, a spirited bar, and an impressive Django Reinhardt shrine surrounding the big performance space in the rear. Guitar aficionados will find many a wonderful instrument to drool over!
WWJCD? (What would Julia Child do?)
Back in the day, here at Clignancourt is where Julia Child purchased her first antique mortar and pestle after she moved to Paris. "The mortar was made of dark-gray marble, and was about the size and weight of a baptismal font," she wrote. "One look at it, and I knew there was no question: I just had to have that set." That very mortar and pestle, along with other kitchenware she brought back from France are now on display at the Smithsonian National Museum of American History. "Everything has a history," as Julia would say. I agree!
Star Struck
Who else found inspiration at Clingnancourt? Elsa Schiaparelli, André Breton, Pablo Picasso, Christian Dior, Christain Bérard, Yves Saint Laurent, Andy Warhol, and Gabrielle Bonheur Chanel—just to name a few. According to writer Laure Verchère, Coco coolly quipped, "When I go to the flea market, everyone says hello to me. They come and kiss me. I let them. It doesn't cost a thing."
Keeping it Real: I'm not going to lie to you. Finding bargain deals at Clignancourt is not easy-breezy. It takes the curiosity and patience of a cat, and more than a few shots of soda pop for courage. That said, once every blue moon, I do manage to pounce on a few affordable treasures. Grab a ballpoint pen. Here are a few of my favorite hunting grounds.
1. Daniel et Lili (Marché Vernaison)
Clipping from my grandmother, "Diamonds are for the birds!" I agree. Rhinestones and Bakelite have always been this girl's best friend. Here at the Daniel et Lili shop, you'll find brooches, buttons, bangles, beads, barrettes, bags, flowers, hankies, illustrations, and key chains. Oh, we're plastic but we still have fun!
Tip: Throughout the Marché Vernaison, you'll find more vintage finery, fragrance bottles, and magazines, along with the cozy Chez Louisette. Flaunting a retro-vibe, the café serves food and live music on Sunday afternoons. Pass the hat! Edith Piaf is often on the playlist. Non, Je Ne Regrette Rien!
2. Caveyron Devey (Le Passage)
Whenever I misplace my Superpower, I make a beeline to my favorite vintage postcard shop, the Caveyron Devey. It kicks the blues to the curb every time. Looking for a specific category? Don't play coy. If it's a rainy or chilly day, wear warm attire, because the stall is open to the breezes and sometimes damp. Also, if offered a seat at the house table to flip through a box, take them up on it. You'll look like a serious aficionado and your toes will thank you. Tip: Chez Sarah's antique garb is located just a nip, tuck, and pose away.
3. La librairie de l'Avenue (31 Rue Lécuyer)
I've said it once and I'll say it again. Here the angels sing on high from a little CD player located just below the cashier's desk. The sweet smell of coffee and frankincense tickles the nose. This large, but still intimate bookshop is well stocked with new and used art books, catalogues, vintage prints and antique magazines, organized by category, author or genre. My recent steals include a short stack of "Elle" magazines from the 1950s, along with a 1920 "Bon Marché" catalogs for just a few euros. Pleased as punch, I'm still aglow.
Embracing André Breton, "The marvelous is always beautiful, anything marvelous is beautiful, in fact only the marvelous is beautiful." Now, let's shop 'til we drop!
Great post – and I want that 50s dress and hat!
Well, T., you've done it again: taken me back to a special world and a particular time of life I miss, but, like you once quoted from Rick at the end of Casablanca, "We'll always have Paris." I sure hope you're right! Where would we all be without it–and without your groovy column? I do hope you'll write a book some time–I'd be the first buy it and I'd tell all my friends to buy it too!
Oh me oh my would I ever have fun at flea market in Paris!! Your rooftop pic is so dreamy.
Oh Teddy, Was touched that you noticed Daniel and Lili's stand. I was close friends with them in the 1970's in Paris. I even lived next door to them in the 19th arrondissement. They lived in a perfectly Art-Deco home. I have a few great stories to tell you next time I see you!
Bizoux, Caroline
Enjoyed the photos and continue to marvel at your ability to tell a story that is interesting and keeps me wanting to visit Paris.
Pingback: And speaking of Paris …. | Whatever takes my fancy
Pingback: Free Designer Pattern: Patrick Kelly One-Seam Coat | PatternVault
Pingback: French reflections – #1 Paris | Whatever takes my fancy
Pingback: Liebster Award | The Best 5 Years


text: Back Smoking: Truth and Consequences Thinking about giving up cigarettes? If you've tried before without success, you may feel unsure about whether you can quit for good. You may also wonder how to prepare for such a big change. Start by learning everything you can about the health risks of smoking. Then consider how kicking the habit will affect your health and life. Finally, arm yourself with the latest techniques that can help smokers quit. There are now more aids to help smokers become ex-smokers than ever before. Up in smoke When you smoke, toxins are carried by your blood to every organ in your body. At the same time, the carbon monoxide in cigarette smoke keeps red blood cells from carrying as much oxygen as normal. As a result, the cells throughout your body are deprived of the oxygen that they need to work properly, the American Lung Association (ALA) says. Smoking increases the risk for these health problems: Weakened bones and hip fractures in older women Cancers of the blood, cervix, pancreas, stomach, kidneys, and bladder Cataracts Gum disease and tooth loss Damage to the immune system and increased risk for infection Fertility problems in women Peptic ulcers Pregnancy complications and premature birth In the long run, cigarettes rob many smokers of life itself. People who smoke lose an average of 13 to 14 years from their life. Half of all lifetime smokers die early from smoking-related causes. Positive effects Despite these grim statistics, there's good news, too. For one thing, it's never too late to stub out that last cigarette. "Even if you're a 70-year-old who has smoked for decades, you can reap benefits by quitting," says Norman Edelman, M.D., spokesperson for the ALA. These benefits start as soon as you quit. Within 20 minutes of quitting, your heart rate drops. Within 12 hours, the carbon monoxide level in your blood returns to normal. The longer you stay quit, the more benefits you'll see. Within one year, your added risk for coronary heart disease will fall to half that of a smoker's. Within 15 years, your risk is that of a nonsmoker. If these health benefits don't motivate you to quit, "then do it for those around you," Dr. Edelman says. A 2006 Surgeon General's report shows just how risky secondhand smoke can be. When adult nonsmokers are around cigarette smoke at home or work, their risk for lung cancer and heart disease rises by up to 30 percent. In babies and children, secondhand smoke can cause SIDS, respiratory problems, ear infections, and asthma attacks. Most smokers want to quit With all the evidence piling up, it's little wonder why nearly 75 percent of all smokers say they want to quit. If you're in that group, don't be discouraged if you've tried to quit in the past and been unsuccessful. Most of today's ex-smokers needed more than one try, too. Look at your past attempts as learning experiences. "Think about what made you go back to smoking last time and think about what you will do this time instead of smoking," says Cathy Melvin, Ph.D., M.P.H. She's director of Smoke-Free Families, a national program that studies ways to help women quit smoking before, during and after pregnancy. "You learn something from each quit attempt that helps you do better on the next one." To quit for keeps this time, know your enemy. The nicotine in tobacco is very addictive. When you try to quit, the lack of nicotine can cause withdrawal symptoms: Dizziness Headache Fatigue Depression Increased appetite Trouble sleeping Irritability, restlessness, and difficulty concentrating Strong urges to smoke Physically, your body is reacting to the lack of nicotine. Psychologically, your mind is struggling to give up the habit of smoking. Quit-smoking programs that work best combine medication with counseling and support. This combination can double your chances of quitting for good. Prescription for change Nicotine-replacement therapy (NRT) helps many people quit smoking. NRT gives you nicotine without the other harmful parts of tobacco smoke. NRT allows you to focus on changing your behavior. You can then wean your body off the nicotine. Five types of NRT products are available. Nicotine gums, patches, and lozenges can be bought over the counter. Nicotine sprays and inhalers are available by prescription. If you're pregnant, or if you have heart disease, be sure to talk with your doctor before using one of these products. Two non-nicotine medications have also been shown to help smokers quit. Bupropion (Zyban) affects brain chemicals involved in the craving for nicotine. Varenicline (Chantix) acts on parts of the brain that are affected by nicotine. This cuts the pleasurable effects of smoking and reduces withdrawal symptoms. Talk with your doctor about the best option for you. Also ask about counseling and support programs. These programs can advise you about the best quit method to fit your needs and can provide encouragement to stay quit. Aside from your doctor, other sources for referrals include your local hospital, health department, or the American Cancer Society.


text:
More than 400 wineries dot the fertile soils of Napa Valley, one of the world's premier viticultural regions. But wine, as visitors quickly discover, is only the beginning. Lavish resorts and top-rated chefs, at scores of restaurants, work alongside the farmers who tend this land: the result is something understated and exceptional. Welcome to Napa Valley.
Kellie Larson
Phone: (707) 217-9000
Email: email@example.com


text:
(Ph.D., University of Wisconsin, Madison) is Professor of Geology at Brigham Young University.
Local: 801.422.9229
Toll-Free: 800.327.6715
Email: firstname.lastname@example.com
The views expressed here and in Maxwell Institute publications are those of the individual authors and do not necessarily represent the views of the Maxwell Institute, Brigham Young University, or The Church of Jesus Christ of Latter-day Saints.
"Seek ye diligently and teach one another words of wisdom; yea, seek ye out of the best books words of wisdom; seek learning, even by study and also by faith." (D&C 88:118)


text:
LOS ANGELES >> After three years as the acting state director of a group dedicated to changing the conversation about education reform among Democrats, former state Sen. Gloria Romero is striking out on her own and announced her intention to start a new "parent empowerment" organization Thursday.
"I am thankful for the opportunity to have worked with (California Democrats for Education Reform), but believe that it is time to move past party politics and focus my skills and organizing with parents who form the true base of any education reform movement," Romero is quoted as saying in a news release issued Thursday.
Romero's new organization will be called the Foundation for Parent Empowerment, which will work to educate parents about the "myriad of federal and state laws" that give parents a say in their children's education, especially laws concerning school choice.
It's not her first time getting involved in parent choice: Romero is the author of California's 2010 parent-trigger law and has been the state director for DFER for three years.
"We are extremely grateful for all the great work Gloria has done for children and families in California as an elected official in the California Legislature as well as her leadership of DFER in California," DFER Executive Director Joe Williams is quoted as saying in the same press release.
"We are excited for the launch of FPE and grateful that Gloria will be continuing her leadership in the education reform space, not just in California but elsewhere in the country."
Romero plans to launch her new organization within six months.


text:
Voting in municipal elections in the Netherlands
Citizens of the Netherlands and citizens of other European Union (EU) Member States are allowed to vote in municipal elections (gemeenteraadsverkiezingen) in the Netherlands. Non-EU citizens are also allowed to vote, provided that they meet the requirements. These elections take place every 4 years.
There are a number of conditions for voting in municipal elections:
- You must be at least 18 years of age.
- You must not be excluded from voting (in Dutch).
- You must be a registered resident of a municipality in the Netherlands. You have the right to vote in the municipality where you are registered on the day of candidacy. That is 44 days before the election.
There is an additional condition for citizens from countries outside the European Union (EU). You must have lived lawfully in the Netherlands for at least 5 years before the day of candidacy.
The right to vote does not apply to employees of foreign embassies or consulates. This also applies to their families. There is an exception for employees or family members who hold Dutch citizenship, they are allowed to vote.
The Kiesraad (Electoral Council) provides more information about the eligibility requirements for voting in municipal elections.
Consider the following steps when voting in municipal elections:
- At least 14 days before the election a polling card (stempas) in Dutch will be sent to you at your home address. You must take the polling card, together with a valid form of identification (link in Dutch), to the polling station (stembureau).
- At least 4 days before the election you will receive the list of candidates, including the addresses of the polling stations.
Proxy voting:
If you are unable to vote in person, for example because you have to work or are on holiday, you can authorise another voter to cast your vote on your behalf (in Dutch).
This is how it works for you
Here is some information from your municipality.
Voting in municipal elections
Proxy voting
Do you want to ask someone to vote for you? If so, you can authorise someone. You can do this using:
- your stempas (polling card);
- a machtigingsformulier (proxy form).
Authorising someone using your polling card
To authorise someone to vote on your behalf using your polling card:
1. Fill in the back of your polling card. Do this together with the person you want to authorise to vote on your behalf, so that you can be sure that you are authorising the right person.
2. Give your proxy voter your polling card and a copy of your identity document. The identity document may not be more than 5 years old.
3. The proxy voter must show the copy of your identification at the polling station. The proxy voter must also show their own identification .
The proxy voter can only cast your vote at the same time as their own vote. A proxy voter can vote for a maximum of 2 other persons.
Authorise someone using a proxy form
You can also use a proxy form to authorise another voter to vote for you. This is referred to as a written proxy. You can obtain a form for this purpose from your municipality a few weeks before the elections.
To authorise someone to vote on your behalf using a proxy form:
1. The form must be filled in by you and the person who is going to vote for you (the proxy) – first the person you want to authorise, then yourself. This way you can be sure that you are authorising the right person.
2. You must hand in the form at your municipality.
3. The proxy voter will receive a volmachtbewijs (proxy certificate) enabling them to vote on your behalf. Once the municipality has approved the proxy certificate, it cannot be withdrawn.
4. The proxy voter must take the written proxy certificate with them to the polling station. You do not need to provide them with a copy of your identification . The proxy voter can only cast your vote at the same time as their own vote.
The municipality provides polling cards, candidate lists and voting locations. You will receive your polling card by post. The municipality delivers candidate lists door to door.
Voting is free of charge.
Questions about this topic?
Contact the Municipality of Olst-Wijhe